Apple infuriates iOS 5 beta users by suddenly bricking their phones without warning

A huge number of iOS 5 beta users have apparently been infuriated after their phones were suddenly bricked yesterday evening US time.

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.

Some thoughts in response to Matthew Baxter-Reynolds

Matthew Baxter-Reynolds wrote an interesting piece for the Guardian yesterday giving some points of view essentially on what Windows 8 will mean for businesses and IT careers. In particular, he makes the point that writing for a Windows 8 device means a more natural progression from the "C# in Visual Studio" type development that is the bread and butter of most business applications. And he makes the point that this time around, Microsoft will be fostering a tighter coupling of software and hardware platforms to move closer to the model of the iPad, part of whose success relies on it being more of a "self-contained ecosystem".

From this point of view, I think Matthew is probably correct: if the thing you want to concentrate on is writing boring old "bread-and-butter" business applications, then a platform that builds on the existing "bread-and-butter" platform of C# in Visual Studio will be a more attractive proposition for businesses to get a footing on the tablet bandwagon. And even it if wasn't more attractive from a development perspective, "Microsoft Windows tablet" may just sound a bit more 'serious and businessy' on a tender bid.

But, I think Matthew could have included a few other important observations (which don't necessarily contradict his point of view and if anything support it-- but which are nonetheless worth mentioning):

• the iOS "ecosystem" may still present an attractive market to developers in the sense that Apple have done the job of (a) isolating the 100+ million people with sufficient income to splash out on fancy toy; (b) sold them that toy on the basis of it providing enjoyment: or in other words, persuaded them that it is to their benefit to spend money on this new gadget (and associated apps); and (c) built a system for developers to market fairly effortlessly to that income-to-spare-for-toys-and-apps sector;
• games (and, apparently, knocking out games that you can sell for a buck or two a download) remain the predominant iOS market; the iOS development framework allows you to write virtually all of your application in a bog-standard C/OpenGL paradigm which will allow the creation/porting of a huge number of games with a minimal learning curve;
• while slightly quirky, in a sense Objective-C is just "another C syntax-based language" and if you stick around in programming long enough, you generally end up learning a new C syntax-based language every 10 years or so; indeed, "Java" as it looks today, and certainly how it will look if currently discussed language features make it into Java 8, is almost a whole new language compared to how Java was when it first materialised back in 1735 (anyone remember when Java didn't have inner classes, let alone generics or closures?);
• given that many business applications can and indeed ought to be written as web apps (a point which Matthew himself makes), for as long as HTML5/Javascript remains a standard enough development paradigm, I wonder if the Microsoft tablet will "C# in Visual Studio" actually become the paradigm of choice for tablet business applications anyway?

So, while I think Matthew is probably right that we could end up with an 80:20 split in one market versus a 20:80 split in the other, I don't know that that means that the "not-the-boring-bread-and-butter-database-application" market isn't viable.