Even 'random junk' may need encryption

There appear to be some interesting legal cases springing up around the fact that software developers have been taking "raw" Unique Device IDs and using them to store data against a given user 'in the cloud'. UDIDs essentially resemble a long 'random number' rather than directly encoding any user-identifiable information, so you may be forgiven for wondering what the issue is. The problem comes when applications have then stored user-identifiable information (such as social network data) alongside the UDID and make this information available to other applications, thus leading to a 'leaking' of user-identifiable information on the basis of this shared UDID.

The solution is in principle simple: append the UDID to an application-specific code or 'salt' and then encode this combination using a secure hash scheme such as SHA-256. The application-specific salt doesn't need to be a secret. But doing this means that I cannot compare a hash for user X from one application with a hash for user X from another application and deduce that they are for the same user. Again, in principle.

However, this scheme does rely on UDIDs containing sufficient entropy. Since the number of devices of a particular model sold is maybe in the tens or at most hundreds of millions (iOS devices appear to have sold something in the order of 200 million so far), if it is possible to make a good prediction of which range of the theoretically possible UDIDs has actually been allocated, then I can simply pre-compute all the potential combinations of (allocated hashes, application ID) for two given applications and find all the matches.

I haven't yet looked into all the details, but it appears that iOS 5 will remove the ability to read device-wide UDIDs in favour of application-specific UDIDs, presumably generated using a scheme such as the above. Although this is arguably the scheme that should have been adopted from the outset, if true, it will interesting to see what incompatibilities this throws up.

So why didn't people think of this in the first place? I wonder if one of the issues is that to a human, UDIDs do just look like 'random junk': it's just a string of random numbers, right, so why would you bother encrypting it? It's a good example of how when deciding when and how to employ encryption, we have to think not only about the data itself but also about protocols and practices governing how that data is used and stored.

Dear universe: please make your default settings sensible

I'd occasionally noticed that alerts for my calendar events would sometimes go off at odd times on my iPad. For example, I'd wake up in the morning to find that the "5 minute" alert for a mid-morning meeting had already gone off. I suppose the first couple of times, I just assumed I must have entered something wrong when setting up the event. But, being the aspiring cross between Columbo and Paddington Bear that I am, gradually my suspicions were aroused.

Luckily, some other people more patient than I am with spuriously designed user interfaces were able to come to the rescue. In case you haven't found it, the offending setting is an option burried in the "Mail, Contacts, Calendars" section of your iPhone/iPad settings curiously entitled "Time Zone Support". With this set to a particular Time Zone (rathr than simply being switched off), then your device will not adjust calendar events to match your current time zone.

So you might be thinking "hey, what's your beef, this is a great feature to have, no?". Well, yes, it's a great optional feature. But the things that strike me are:

(a) to say that the iPhone/iPad are supposed to be the holy grail of PDAs (aren't they?), it doesn't seem like a terribly fine-grained feature, particular as there is a "Location" field in calendar events, and that thanks to the miracles of GPS, the device knows where you are at any given moment (or at least, knows where you are to within an approximation of a couple of skyscrapers/underground bunkers-- usually good enough to tell what time zone you're in);
(b) why give this option a silly, non-intuitive name and then turn it on by default? why by default would I tend to want events not to be in synch with where I am at the moment, given that the whole raison d'être of these devices is for travelling...?

Well, I'm sort of happy now I've discovered the option. But on the other hand, grrrrrr.

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.