Transmissions

by Dragorn

Starting this article is a bit of an exercise in desperation, as I attempt to write real content using only the on-screen keyboard of a phone, since an inconvenient lightning strike ate most of my home network.

This is on some level fitting.  Recently, the resurfacing of a bug I found in Android a year ago has gotten me annoyed at the utterly broken Android update cycle all over again.

I'm a fan of Android in general.  It tends to fall into the bucket of "all phones suck, this one sucks less for what I need to do with it."  Unfortunately, in some regards, Android falls down completely, especially when it comes to security updates being pushed to older handsets in a timely fashion.

Many factors are at play controlling when updates are pushed to phones, and few of them represent the best interests of the consumer.  The side effects of this are probably being felt by many of you right now: How many of you are still waiting for Android 4 to be announced for your device, let alone delivered?

When Google releases a new Android update, it typically first appears as a firmware for Google-sponsored and developed phones (the Nexus series), and sometimes released as non-open-source firmwares for specific vendors (Honeycomb or Android 3.x for example saw binary releases while never seeing an open-source release until Android 4 was complete).

Unfortunately, most consumer phones are not directly based on the Google reference design.  Attempting to differentiate themselves from each other and provide consumer lock-in on a specific brand, vendors modify the base Android system.  Modifications run the gamut from the innocuous (custom widgets and home screen launchers), to the annoying (custom UI layers which can lead to applications looking weird and slow down the system), to the infuriating (enhanced logging daemons with vulnerabilities which subvert the permissions system of Android and allow applications to greatly exceed their declared permissions).

Finally, the carriers get involved, requiring specific features in stock Android to be disabled to allow billing users extra to unlock them (such as hotspot mode), requiring applications be installed (bloatware and crapware apps for which the carrier gets a cut), and often they require that the bootloaders remain locked to prevent users from installing custom firmware which lack these restrictions.

Each layer adds a delay: modifying a system as complex as Android definitely takes time, and validating all those modifications take even more.  Validating that the firmware behaves as expected and won't negatively impact the carrier's network also takes time and money.

Unfortunately, it's not in the vendors' best interest to expend extra effort building new firmware images, testing them in-house, and paying for their testing out-of-house on phones they aren't getting money from.  In some cases, the phone simply lacks the RAM or storage space to run a newer version of Android (feature creep, like any OS, usually means every revision is a little hungrier than the last for whatever resources the phone can give it).  But often, a manufacturer (or a carrier) decides that a phone is end-of-life and will no longer get updates, even when the device is fully capable.  The only recourse for the user?  Buy a new phone, truly a horrible outcome for phone manufacturers.

This has serious implications beyond not getting the latest shiny version of Android.  Security updates also fall by the wayside when phones no longer get timely updates, and even phones which are slated to get updates may get them months after a security problem is made public, leaving the users exposed.

For example, say a new vulnerability is discovered in the now much older Android 2.2.  While any device capable of running 2.2 should have a reasonable expectation of being able to run 2.3 with no problem, Google's own numbers show Android 2.2 at 19 percent of the Android ecosystem, and Android 2.1 (current around 2010) still holds five percent of the installed devices.  Looking through anger-tinted glasses, a moderately reasonable interpretation is that 25 percent of the Android devices currently deployed are completely abandoned by their manufacturers and carriers, and any exploit found in them has a very good chance of never being fixed.

A familiar tune to everyone should be the oft-repeated (and oft-ignored) reminder that a smartphone is just another PC, with a permanent Internet connection and links directly to your credit card.  It's an extremely tempting target for malware, despite none being terribly advanced so far.  Like the Java worm which just hit OS X, Android can remain unscathed from a serious widespread attack for only so long; when vulnerabilities exist, and money can be made, eventually someone will step up to take it on.

For hackers, of course, solutions abound: root your phone, run AOSP or a custom ROM, and you're good to go... mostly.

By running an un-vetted ROM image, you are open to attacks against credentials, logins, call snooping, and so on: It's an untrusted operating system, often assembled by unknown (or semi-known) individuals.  So far, no custom ROM has gone black-hat (or at least been detected as doing so) and I in no way cast aspersions against any ROM developers, but, the risk remains: by trusting a relatively unknown source, you trust that they never become malicious, and that they are never compromised themselves, exposing the build system used to create the ROMs.

For normal consumers, installing a custom ROM usually isn't an option... and we should care about this.  If you're an Android user, the entire ecosystem of the Android platform is relevant: if the platform degenerates into dead-ended devices which will never see an update, developers will leave, and the developers who remain will be shackled to deprecated versions and unable to take full advantage of newer Android features without sacrificing 25 percent of the market.

It's difficult to influence the course of large corporations who make the phones and carriers who control releases, end-of-life, and bloatware installs, but it behooves all of us to demand reasonable update guarantees whenever the option presents itself.