Android RNG vulnerability: distorted incentives and platform ownership (part II)

[continued from part I]

The Android bargain: ceding control, gaining market share

The reason individual developers are enlisted to fix platform bugs is simple: Google does not have the ability to push security updates to users. In what may be the worst-kept secret of the mobile industry repeatedly pointed out by pundits,  the update channel for most devices is controlled by handset manufacturer and/or carrier. (The exception being “pure” Google-experience devices offered under the Nexus umbrella. But even these are not immune from carrier interference: for example Google caved-in to demands for blocking Google Wallet on Galaxy Nexus phones subsidized by Verizon.)

This is no accident or oversight. In trying to compete with iPhone for market share, Google made a Faustian bargain with OEMs and carriers. Providing them an open-source OS that could be endlessly customized and tweaked. This was not mere rhetoric or paying tribute to the open source model. It was a deliberate concession, partially ceding control of the handset software to provide a more appealing platform that OEMs/carriers would. An iPhone has only one “handset manufacturer” (Apple) and looks the same from Verizon or AT&T. Android follows the PC model of hardware competition in allowing OEMs to differentiate not only on features and pricing but also with “value-add” customizations to the OS: HTC Sense skin, Samsung eye-tracking etc. Carriers also jumped into the fray trying to distinguish their devices with customizations, for example controlling wireless-tethering to squeeze more revenue out of data plans.

By all indications, the plan worked. Reaching market a full year after the iPhone, Android nevertheless managed to overcome Apple’s first-mover advantage. Judged by unit shipments, Android dwarfs the iPhone in the US and globally.

Distorted incentives

There are two downsides to this hard-won battle for market share:

  • Once the OEM/carrier goes off the reservation and starts changing the operating system, incorporating updates is no longer a straightforward proposition. A security patch issued by Google for “vanilla” Android builds may not work against a heavily customized image from some OEM. (Imagine if Google pushed out an update that rendered some fraction of AT&T devices unusable?) At a minimum OEMs/carriers must be involved in testing the security update against their customizations to guarantee nothing will break. In some cases they may have to do additional work to modify the update to work for their particular scenario.
  • At the same time as the difficulty of delivering updates goes up, the economic incentive for doing so vanishes. Because the OEM/carrier views the operating system as an asset they can compete on (eg it is not a “freebie” magically gifted from Cupertino in identical shape to everyone) it is no longer something to be given away freely. Why invest in upgrading legacy devices when you can sell that customer a brand new phone with the latest and greatest OS? The same distortion applies to the carrier thanks to device subsidies: over time a subscriber pays more than the hardware retail cost. It is more profitable for the carrier to “upgrade” the user to new phone– even for nominal fee– locking them into another extended contract.

The ultimate contradiction: Google has less ability to deliver security updates to Android phones– devices  always powered on and connected to the Internet–than Microsoft had for Windows PCs in 2004.

CP