There's been some disturbing news about Android security recently. It appears that many shipped Android-based devices are simply not getting system updates. Apart from getting righteously frustrated as consumers, we should also understand the short- and long-term effects this has on security.
According to Michael DeGusta's research, which he explained on his blog, TheUnderstatement , Android product vendors have pretty much gone with a practice of releasing their devices with a fairly current version of Android, and then releasing just one or two system updates in subsequent years at best.
Thus, most Android handsets today are running Version 2.2.x or 2.3.x of Android, though Google just released 4.0 (a.k.a. "Ice Cream Sandwich"). To be fair, that sounds worse than it really is, since the 3.x branch was primarily for tablet -based systems, and much of the reason for 4.x is to unify the platform among smartphones and tablets better, which would be a very good thing.
Still, the majority of shipped Android devices that are still under warranty or two-year commitments with their service providers are running Android versions that are quite old and aren't likely to be updated anytime soon even while still under active contract.
There are various reasons for this. Chief among them is the "fragmentation" of the Android ecosystem. Google releases code that is in turn adapted by hardware manufacturers, and that in turn is adapted by various service providers. The software release latency from Google to device is long in the best of situations, and insurmountably long in many others.
That's in stark contrast to Apple 's more centralized approach. Indeed, iPhone devices from the 3Gs (as well as every iPad shipped) and newer can all run the latest iOS update, 5.0.1 and a staggering number of iOS users actually take Apple up on those free updates.
So what's the big deal? In the short term, consumers are forced to rely on products that lack security features that could well help to protect their data. Full disk encryption was introduced as a user option in the Android 3.x code base, for example. And then there's hardware data encryption, secure keychains and such that have been added over time.
Many of these security features are compelling, and we're all better off if our systems make use of them.
But there's the double whammy of these slow updating practices. Software developers are pragmatists in many ways. They write their software based on market share (among other things). So, despite the fact that Ice Cream Sandwich is sporting a bunch of really nice security features, the market share of users running it just doesn't validate building code for 4.x code base yet.
And brave developers who dive into 4.x early are likely to be "rewarded" by having to maintain multiple source trees, in order to provide support for users on older Android systems.
So, consumers end up getting shortchanged on both ends of the equation.
Meanwhile, Apple's iOS has also seen new security features rolled out over time, such as big improvements in hardware encryption and key management. These APIs are out there in the current platform, and developers are able to quickly make use of them.
We've also seen some security and privacy exposures getting reduced in iOS. For example, Apple has announced that the API for accessing a device's unique device identifier (UDID) is being deprecated, albeit slowly. Many app developers have used the UDID to identify end-user accounts, sessions and all sorts of things that they ought not to do with a UDID. In fact, using this sort of unique hardware identification within an app is largely believed to be a privacy violation, so in response Apple has warned its developers to stop using that API, and it will eventually be unavailable.
As a whole, these things spotlight some of the important and practical differences between a centralized and a decentralized software ecosystem. While there's no shortage of good and bad things in both camps, it sure seems clear that the iOS approach benefits consumers more in terms of having the latest software and security features in their currently deployed devices.
Is it too late for Android to catch up in this regard? That's tough to say, but to some degree, the whipped cream is out of the can, so to speak. Trying to change the dynamics of the system now that Android is quite mature is going to be an enormously difficult task, and it will involve the active participation of all of the key stakeholders.
Dealing with legacy equipment has long been an IT nightmare. Mobile devices certainly are not new here. But the pace of play in the mobile world has accelerated the speed at which a device can go from being cool and desirable to ancient. Let's hope the Android community can step things up a bit for their consumers' sake.