In last week’s issue, I gave several links to photo albums that I’d created with iPhoto on my iTools HomePage site while on our cruise to Alaska. They had worked fine for our friends and families while we were on the cruise, so I was surprised when email complaints started arriving almost immediately, saying that the photos weren’t accessible due to excessive bandwidth consumption. Before I get to the larger issue of what’s going on here, for anyone who wants to see the photos, they’re now on my server, exported again from iPhoto, but via the BetterHTMLExport plug-in.
Some research and discussion on TidBITS Talk revealed that Apple had put these bandwidth limitations into effect – without warning – only in the middle of May, which was why previous uses hadn’t run afoul of the limitations. MacInTouch’s compilation of reader letters gave a good overview of the situation.
Cold Hard Numbers — For a while, the actual limits were completely unknown, but then a post appeared in Apple’s discussion forums that explained at least some of the details. If a HomePage Web site receives more than 500 hits in a 6-hour period, Apple caps the amount of data that can be transferred from that site to roughly twice your iDisk capacity for the rest of that 6-hour period. Let’s look at my situation for how that might work out. I published roughly 50 pictures, and they took up about 5 MB of space on my iDisk. Only 10 people need to view all my pictures to bump me over the 500 hit limit. Giving Apple the benefit of the doubt and assuming that the bandwidth counting starts at that point, I could then serve 40 MB of data (twice my default 20 MB iDisk size) going forward. At 5 MB for my picture collection, though, that’s only another 8 people, for a grand total of 18 visitors before Apple would start turning people away. Thinking back, none of our friends or family ran into the bandwidth limits initially because I published the photos in four sets. Had I published all 50 images at once, the fact that I sent the announcement to 56 people in our extended families along with 21 friends could easily have resulted in enough traffic to take the site down.
The limits are somewhat higher if you’ve paid Apple for additional iDisk space. If you’re receiving fewer than 500 hits in a 6-hour period, you’re limited to roughly 14 times your iDisk capacity in that time frame. If you receive more than 500 hits in a 6-hour period, you’re limited to 2.5 times your iDisk capacity. Let’s assume I had paid for another 20 MB of iDisk space and posted the same set of pictures. The first 10 people viewing the 50 pictures would bump me over the 500 hit limit, after which I could serve 100 MB of data (40 MB multiplied by 2.5) before running into the bandwidth limits. At 5 MB per person, that’s 25 people, or 35 total before new visitors start being turned away.
You Get What You Pay For, But… Apple is of course within their full rights to clamp down on iTools usage. iTools accounts are free, and Apple is absorbing real costs for all the disk space and bandwidth that iTools users consume. I haven’t seen anyone complaining that Apple is acting unfairly, and no one should.
However, there’s no question that Apple has bungled the user relations aspect of this decision completely. Apple never made an official statement about the decision (or even replied to our requests for clarification), there is no permanent Web page explaining the specific limitations, users are not warned in advance that their sites will be made unavailable, and the error message that appears in place of the desired page is less than helpful. For a company that prides itself on creating clear, easy-to-use interfaces, a lapse like this is particularly glaring. It’s not rocket science, it’s just common courtesy.
This policy also has further reaching implications. Apple has specifically touted iTools as a benefit of buying and using the Mac and encourages users to use it, to the point where you can mount your iDisk from the Mac OS X Finder and publish photos directly to a HomePage photo album from within iPhoto. Integration of Mac OS X and applications from Apple with iTools means that iTools is itself a feature of those products, and hobbling iTools with these bandwidth limits reflects poorly on the products. I used iPhoto to upload my photos to HomePage because it’s far easier than uploading to my own Web site, and that ease of uploading was important while I was travelling. But knowing that only a very small number of people can view my photos via HomePage means that I just won’t bother using that feature in the future, and I’ll have to recommend that other iPhoto users avoid it as well if there’s a chance they’ll hit the bandwidth limits.
Other heavy users of iTools are independent Macintosh developers, who like to distribute their Macintosh software via iTools not just because it was a free Web host, but also because it’s part of the full experience. Contributing Editor Matt Neuburg put it best when explaining why he chose to host his freeware utility MemoryStick on Apple’s servers:
"MemoryStick is free, it’s written with Apple’s free tools, it’s for Mac OS X users, it both improves and advertises the Mac OS X experience, and it lives at Apple’s free site that is integrated with Mac OS X – all completely in tune with a spirit of community and ‘all Apple, all the time.’ That’s why it’s so disappointing when Apple itself violates that spirit by preventing Mac OS X users from downloading."
The new bandwidth limits eliminate the utility of using iTools to host Macintosh software – whether or not a developer would run into the limits on any given day, the uncertainty of never knowing if the site would be up would be unacceptable. Of course, if you read the iTools membership terms carefully, you see that iTools is only for personal use, which would preclude posting shareware. That’s better sent to the Info-Mac Archive for posting on the many Info-Mac mirror sites, which can then be linked from a product page.
Where iTools used to be an excellent advertisement for Apple and for Macintosh technologies, the bandwidth limits turn it into a negative impression. In the past, showing a Windows user how easy it was to post a photo album on the Web via iPhoto and HomePage was great fun, and even having Windows users viewing the photos on the Web made it easy to tout the advantages of using the Mac. But with cryptic error messages about excessive bandwidth consumption appearing unpredictably, it’s downright embarrassing to use HomePage.
Finally, those people who choose to keep using HomePage should bear in mind that it’s trivially easy to engineer a denial of service attack. Just load a few photo album pages several times and you can overload any photo album. It wouldn’t even be difficult to set a robot to cause a very large number of HomePage sites to go over their bandwidth limits all at once.
Possible Solutions — I have a few ideas about how Apple might be able to avoid this problem, either by managing the bandwidth usage better or bringing in some money to pay for the load.
Use Packeteer’s PacketShaper (or a comparable product) to manage the bandwidth available to any given user’s HomePage site. Apple could even allow a user full bandwidth until a certain point, then throttle the bandwidth available back to reduce service without eliminating it entirely.
Track and manage average bandwidth use over a month, rather than over a six-hour period. That approach eliminates the problem of a site becoming unavailable due to an unanticipated spike, but still lets Apple deal with users who continually use excessive bandwidth.
Set specific bandwidth limits, and when an account is close to reaching them, offer to raise the limits temporarily for a fee. That would let a user pay a small amount to keep the site alive, without worrying about a potentially unnecessary monthly charge.
Let iTools users set photos as being available for sale; Apple could then charge a markup on the photos. That way iPhoto users wouldn’t have to order prints for friends or family members – everyone could do it for themselves.
Charge for the high-bandwidth aspects of an iTools account, but waive the charges for a year if the user purchases a certain amount of Apple hardware or software in that year.
Add a few dollars to the cost of a Mac to cover the overhead of providing iTools. Some portion of the cost of a Mac goes to paying for the bundled version of the Mac OS; the same could easily apply to paying for iTools.
Present internal ads about switching to the Mac on pages viewed only by people using Windows machines. Then encourage iTools users to show off their sites to Windows-using friends and family. This approach wouldn’t generate iTools-specific income, but would help the overall bottom line, just as all ad campaigns should.
Finally, though this would be the most controversial (and the most work), Apple could carry Macintosh-only advertising on HomePage-based pages provided for free. As long as the ads were Mac-specific and not horribly intrusive, most people probably wouldn’t complain, and although the Internet advertising market isn’t in great shape right now, it would still bring in some revenue. Of course, the advertising could be removed from sites created by paying iTools users.
I’m sure there are plenty of other approaches that would let Apple continue to serve HomePage sites without suffering from a site becoming too popular. Given the undeniable utility and cachet of having iTools integrated with the operating system and applications, Apple should work harder to make sure Macintosh users can continue to use iTools in real ways without the constant worry of having sites taken down for excessive bandwidth consumption.