A brief tempest of recent blog posts highlights a design compromise that Apple made with App Store and in-app purchases from iOS devices.

To summarize, designer Mike Rohde bought an app on his iPad and, while waiting for it to download, his 7-year-old son played a free aquarium app called Fishies that offers additional items for sale via in-app purchases. Without realizing what he was doing, Mike's son purchased a number of items within Fishies, including a chest of pearls priced at $149.99 - he racked up almost $200 for the day. Reasonably enough, Mike went ballistic when he saw the bill from iTunes. Luckily, despite the iTunes terms stating that all sales are final, he was able to call Apple Support and have the largest charge refunded.

So what happened? Developer Manton Reece explained it well in his own blog post. In essence, because Mike had purchased an app on his iPad and then let his son play with Fishies immediately afterward, iTunes cached Mike's password and used it when his son made purchases within Fishies, instead of requesting it again. Mike's son was prompted for each purchase, but since the iOS didn't require a password, it's easy to see how a 7-year-old could agree to the in-app purchase prompts without realizing what was happening.

This entire situation came about because of a design compromise. By requiring you to enter your iTunes account password for a purchase or free download, Apple ensures that an authorized user is in control of the device. That's a good thing. And by caching the password for 15 minutes, Apple reduces the significant annoyance of typing passwords (especially strong ones that include numbers and punctuation) on a virtual keyboard. In general, that's also a good design, although it can obviously have unintended side effects.

To eliminate those side effects, Apple could require a password for every purchase or free app download, but that would hurt the overall user experience. In most instances, there's no need to prompt multiple times for purchases made in quick succession because it is most likely that they're being made by the same authorized user.

Arguably, Apple could also cache the password separately for app purchases and in-app purchases, such that purchasing an app wouldn't enable in-app purchases without requiring a password. However, there's no telling if such a change would be easy to make or if it would make a significant difference, since any sort of caching will allow inadvertent purchasing.

Another solution would be to add an option in the Store settings panel that would enable users concerned about this possibility to require passwords more frequently, for transactions over a certain amount, or even for every transaction.

In the end, though, the best advice is merely to be aware of the possibility that a cached iTunes password could be used for purchases, which is most likely to happen when an iOS device is shared with young children who might purchase things inadvertently. Older children might become aware of the loophole and exploit it intentionally, but that's something to be solved via discipline, not technology. It's much like an automatically locking door - if you're concerned about security, you wait to see if the door has closed and locked behind you after you enter or exit the building, because if you don't pay attention, it would be possible for someone to grab the closing door and enter without having a key.

That said, the constant increase in the number of passwords - on multiple devices - that we need to deal with is becoming a significant user experience problem, and one that Apple would do well to think about.