Monday 28 April 2014

Android Needs A Better Security Update System

Recent security issues such as Heartbleed, which reportedly affects Android 4.1.1 (http://googleonlinesecurity.blogspot.co.uk/2014/04/google-services-updated-to-address.html), and permissions being a bit too permissive (http://www.fireeye.com/blog/uncategorized/2014/04/occupy_your_icons_silently_on_android.html) have both apparently resulted in Google releasing fixes to their partners. We all know that their partners, the device manufacturers, have a poor history at updating devices, especially those devices which are more than a year or so old. In some countries, mobile network operators add a significant delay to the update process, sometimes many weeks or months.

It must therefore be time for Google to implement a direct system for applying security updates to devices, which does not rely on device manufacturers or mobile network operators. Sure it's not the ideal scenario; both device manufacturers and mobile network operators would much prefer to test the updates before releasing them into the wild. However, the direct system is surely better than having many hundreds of thousands of devices stuck on vulnerable versions of an operating system? Depending on which set of statistics that you look at, there could be anywhere from 10% to 34% of Android devices in use today on the 4.1.1 version that is vulnerable to Heartbleed.


Somewhat ironically, Microsoft's Windows operating system, which is not usually held up as a shining light for security best practice, has had a direct system for updates for many years. It's not perfect or 100% interoperable in every scenario, due to the massive array of both operating system customisations and end user software on the market for Windows. However, it does give Microsoft a direct route to deliver security patches, a route which isn't dependant on anybody else (outside of the corporate environment anyway, where rolling out updates is typically managed by the organisation centrally in a controlled manner).

Apple has the klout to do system updates direct for its iOS devices, but having control of the hardware and operating system stack end-to-end means there are less integration risks than the plethora of Android-based devices in the wild. Maybe that appeases the concerns of the mobile network operators. Apple also control app releases in their App Store much more than Google do in the Play Store, and the apps themselves have far less access to the operating system, with much fewer and wider ranging APIs available to app developers. Maybe that too reduces the risk of interoperability failures when updates are rolled out without mobile network operators having their testing time.


Google Play Services, a set of core modules responsible for providing the majority of APIs to non-system apps (amongst other things), are already updated directly from Google without any middlemen and without a user having to visit the Play Store, tick any boxes, or even "accept" the update. This system works already, and is responsible for bringing some new features to devices without them needing an operating version upgrade or a firmware upgrade from the device manufacturer. It would therefore not sound inconceivable that the next major version of Android, be it numbered 4.5 or 5.0, should include some form of device update system, similar to that used for Google Play Services, to bring security updates to users in a timely manner, for the good of everyone.

No comments: