Is Google the Only One to Blame for Missing Security Fixes?

Is Google the Only One to Blame for Missing Security Fixes?

You’ve all heard the recent “breaking news” that caused a storm: Google refuses to release security updates for millions of devices. Wow. That sounds really bad. But is it really as shocking as it first seems to be? Continue reading for a more differentiated look at what is happening here.

First, let’s recap what exactly started this debate in the first place. On December 29 2014, Pakistani security consultant Rafay Baloch published an article about an unpatched vulnerability in older versions of Google’s Android Webview component. To be exact, the proof-of-concept exploit worked on Android versions older than 4.4 Kitkat. Two weeks later, on January 12 2015, Security researcher Tod Beardsley published an article unveiling that Google’s security department does not intend to develop a fix for the recently found vulnerability. Generally speaking, they claimed that the affected Webview version is simply too old to fix the issue on their own and instead they insisted on a having the reporter create a patch, so they can push it to the AOSP upstream sources.

Google’s Justification

So what is the official reasoning behind this rather incomprehensible move? According to Beardsley, Google no longer certifies new devices which include the Android Browser (you know, the old one, not Chrome for Android). In Android 4.4 Kitkat, Google switched to a newer, chromium based Webview and got rid of the old vulnerable code. This perfectly falls in line with a policy that leaked about a year ago that details approval windows for Google Mobile service certification for new devices.

In short, this policy requires OEMs to use the latest Android version or its direct predecessor (for a timeframe of about nine months after a new version is released), but won’t allow them to ship anything older on new devices. According to the leak, the approval window for any Jellybean based release ended on July 31, 2014, which means that you won’t see any new device with Google services on Jellybean and therefore no new devices with the old browser and Webview component.

Ok, but what about existing devices? The leaked policy obviously doesn’t restrict updates to devices already existing in the market and that’s exactly where the problems start to emerge. When security issues are found in AOSP code, Google routinely fixes them so the OEMs can incorporate the fix in their source and push an update to their devices sooner or later. Now what happens if the upstream fix from Google fails to appear? Are the devices necessarily left unprotected forever? Of course not. Google isn’t the only one capable of fixing these issues, but the OEMs can as well.

This obviously requires intervention from the manufacturer, but Google did also state that they are going to notify their partners (read the OEMs) about the security issue. So in fact, the people in charge are aware of the problem and can initiate a custom fix for the vulnerability. Now, for just a moment, let’s assume Google does provide a patch, what would this mean? What needs to happen after resolving the problem in the AOSP code?

The Update Process

First of all, Google needs to notify the OEMs that a new security patch is available and link them to the change set. After incorporating the fix into the device specific code base, the manufacturer also needs to create an update package which needs to undergo QA testing. If it’s a carrier branded device, the finished update needs carrier approval which includes more development and more testing.

Quite complicated, isn’t it? And that’s exactly the reason why you don’t see many system updates for old devices. So even if there are security related bug fixes, there’s no guarantee that the OEMs will actually push the fix in an update to your device, the entire process is just too complicated and time-consuming for them to be profitable.

Solving the Issue

Google is fully aware of the problem and their inability to push timely security updates to critical system components such as the Webview. That’s why one of the numerous important changes in Android 5.0 Lollipop is the unbundling of the Webview code into a separate package. Users won’t see a difference but for Google, this means that they can update this part independently from any other system component. In fact, they can push updates via the Play Store, completely bypassing any OEM or carrier certification. So yes, Google does care for the design flaw in older Android versions concerning quick security updates and tries to improve it with every major Android release.

Wrapping Things Up

So let’s summarize this: Is Google to blame here for not providing a patch? Yes, absolutely, after all they are responsible for the security of their users. Is Google the only one to blame? No, definitely not, as OEMs have an equal amount of responsibility to keep their devices up-to-date and secure. Even if there is no input from Google, the manufacturer can still develop a custom fix if the security of  the users is at risk. And let’s face it, with today’s update policies for older Android devices, how big is the chance that most of them will get a security update anyway?

About author


Freelance software developer and IT student, interested in technology and mobile developments ever since his first Siemens phone. In addition to technical deep dives for XDA-Developers, Fabian is also an enthusiast photographer and tries to combine his interests with unique and creative projects.