The fine lines of iPhone app rules

"It's not whether there is anything wrong. It's whether or not there appears to be."

It appears that app developer Daniel Amitay has been finding out recently about the finely shaded grey areas of Apple's rules on what you can and can't do from an iPhone app.

One of Daniel's apps, Big Brother Camera Security, is designed to mimic the iPhone passcode screen and then photograph any user making an incorrect attempt to enter the passcode. He also decided to collect statistics on the most common passcodes chosen by users by having the app anonymously send those passcodes. Apple have since removed the app from the App Store.

Daniel argues on his blog that this data collection was legitimate, as the purpose was to warn users against choosing frequently chosen passcodes in a future update to the app, and the the App Store EULA informs users that apps may collect diagnostic data. Apple, on the other hand, appear to be arguing that application was "surreptitiously harvesting user paasswords".

It seems that whether that is strictly the case depends at least on one's interpretation of what "harvesting" constitutes, and how one defines the nature of the separation between the app's lock code and the actual iPhone passcode, given that the app is designed to simulate the iPhone lockup screen. A potentially complicating factor is that the data has also been used as the basis for a (somewhat interesting) article that Daniel has published giving an overview of the statistics obtained for the most common passcodes and most common digits in different positions. Publishing this article, though of interest to the security community, may be deemed to make the data something other than for diagnostic purposes of "facilitat[ing] the provision of software updates, product support and other services [...] related to the Licensed Application" as set out in the App Store EULA.

Some interesting questions to consider:

• if secure hashes of the passcodes, rather than the actual passcodes, had been sent, would that have constituted "harvesting"? (Even though with only 1000 possibilities, the actual codes could of course be resolved from the hashes.)
  
• which precise conditions would need to be changed to allow Apple to approve the app? (Is it ultimately the data itself or the surreptitiousness that is the problem? or the publishing of the data in an article not strictly necessary to updating and supporting the app?)

It will be ineteresting to see how this case evolves over the coming days/weeks and whether Daniel is ultimately successful in getting the app reinstated, and what changes are necessary for this to happen.