Why Google won't fix a security bug in almost a billion Android phones | Hacker News Reader

Why Google won't fix a security bug in almost a billion Android phones

engadget.com

51 pointsmoe47 comments

The fact is that Google has fixed the bug. The fix is in Android 4.4. From Google's perspective, the onus is on manufacturers to then ship Android 4.4 to the end users.

In retrospect it was a poor assumption on Google's part to think that these manufacturers were actually going to support their customers. That is why they have spend the last 2+ years re-architecting the system to shove a bunch of functionality into things that Google can update or libraries that developers can incorporate into their apps. I imagine when they started out, they did not intend to have a huge amount of the system in a support library that is packaged inside every single app. I bet they also didn't intend to have the bulk of new features be in the Google Play Services package. Yet here we are, largely because the manufacturers are much like PC makers in that they put their own interests far ahead of the ecosystem interests.

My immediate question is whether requiring an upgrade to 4.4 is substantially more difficult for the manufacturers and carriers to make it work with the affected hardware. That seems like a much messier job than just patching WebKit.

Was it poor assumption on my part that what was once opensource in the baseline OS would stay open even after being extracted into "library" apks ?

What I mean here is that Google's move here is far from being only a support matter.

The problem is that even GOOGLE does not support their customers on the Nexus line. I have, in my drawer, an otherwise perfectly good Galaxy Nexus that is stuck running 4.3 because Google cannot be bothered to update it to 4.4. If Google will not update its own Nexus hardware to 4.4, how can anybody reasonably blame other hardware vendors for behaving the same way?

I'm not sure it's reasonable to expect Google to update a device to the latest version when the hardware manufacturer has exited the market -- http://www.cnet.com/news/google-to-samsung-galaxy-nexus-owne.... While Google does control Android, that's not the only software that is present on the phone. Short of the Nexus series starting to have open source baseband and radio firmware, we'll be at the mercy of hardware manufacturers.

This myth needs to die.

Google Glass uses a TI OMAP SoC from the same generation (4430). The brand-new Moto 360 uses a TI OMAP SoC from the preceding (!) generation (3630).

Google Glass runs KitKat, the Moto 360 even runs Android Wear 5.

It's not that much of a myth. When Google first announced that the Galaxy Nexus was not getting KitKat, I was pretty disappointed, as I had one too. I looked into why there was no official support, and when I found out it had to do with the firmware, my gut reaction was "WTF, that makes no sense." Digging some more, I found out that it actually has to do with kernel driver-firmware compatibility. Google wanted to ship an update, but they needed changes that TI was no longer willing/capable of making. In order to release KitKat on the Galaxy Nexus would either require Google to reverse engineer the hardware and make their own radio firmware (not likely) or holding back the kernel to the same one on 4.3 (subpar experience if it even works).

Neither the Glass nor Moto 360 suffer from this problem since neither has a cellular radio.

Ah, this is interesting. I had always though that it was something about the graphics system. Forgoing an update due to radio firmware is even more embarrassing. They probably could have done a shim layer, to translate between the old & new APIs.

Even shipping 4.4 with a 4.3 kernel would be far superior to having what is essentially a brick.

First, as others point out, there are several devices with either the same (or very similar) versions of the ti omap chipset running 4.4.

Secondly, I purchased a Galaxy Nexus from Google in late April, 2012 with the understanding that it would receive updates for at least 2 years. That is why I was very disappointed when it was not eligible for an update that arrived less than 18 months after I purchased it.

It is truely sad that a perfectly good phone is essentially e-waste, and cannot be used due to this bug.

Wasn't that because Texas Instruments pulled out of the mobile market?

That may be the excuse, but it isn't much of a reason. Google's got the clout to get rid of problems like that. They just didn't deem it worth the expense.

Do you have like 0 experience in hardware or just trolling people? If TI refuses to support the hardware, there isn't much you can do. Besides the enormous technical challenge of reverse engineering all of the software, there's likely legal issues as well.

If a hardware vendor pulls support for your product, it's almost always better to end of life the device.

A better argument is that vendors of consumer hardware should require that their partners sign up for long term support agreements where warranted. Let's not pretend that, just because a software company is big, they can force one of the largest chip vendors in the world to bow to their demands.

If you're an end user or a small shop, you SOL when the hardware gets dropped. But a company like Google always has options. It's not like TI went out of business or stopped answering Google's phone calls out of spite. Google can totally afford to buy a source code license for the drivers and firmware, and they would realistically only be taking on a small added QA burden since they know everything works as-is with the old OS version and they know what they changed with their new OS version. If they were really serious about maintaining their product leadership, they could even hire some of the original team that wrote the drivers and firmware.

They answer your phone calls, they just say "it's not a priority for us to fix this right now" and then the negotiations start. Some times, that's where things end, because you just can't meet the demands of the vendor. Happens all the time in hardware for big and small businesses alike.

I don't get your point. Since TI pulled out, Google can't fix a software bugs (in webview for instance) which have nothing to do with hardware ?

[edit] Just saw this comment that make sense : https://news.ycombinator.com/item?id=8943924

Glass runs the same TI hardware - and also 4.4.

For another anecdote, Galaxy Nexus also supported BT 4.0 BLE with its Broadcom chip, but Google decided it wont enable it for 4.3 release. When I've found that out, it pissed me off immensely, so I found a solution how to enable the support and posted it as a flashable .zip on xda [1]. Same was also for N7 2012 and N10. After flashing BLE worked just fine.

Google doesn't care for its old devices, nor did it cared when it shipped, Nexus line was always awesome hardware, but not fully utilized by software, which is sad from an engineers point.

[1] http://forum.xda-developers.com/galaxy-nexus/development/mod...

Given that the bug in Android 4.3 was fixed in Android 4.4, which AFAIK is available to all manufacturers, how much blame should accrue to the manufacturers for being chronically months or years late in pushing out version updates?

I can see arguments both ways.

I don't think they're late, I think they choose to stop sending updates to devices. The obvious reason is they want people to buy new devices (i.e. renew 2 year contracts).

It's both, really. They stop producing updates entirely after a year or two to deliberately cripple old machines, and when they do send updates they are often many months late.

I am not sure whether Google should develop a fix or not for these devices. Version 4.4 does not have this issue, so the obvious solution would be to update the system. In the real world, android updates are not .. ubiquitous though, not to mention that after some time, all OEMs stop updating their terminals (that also includes security patches though ...).

Google has solved webview/browser bugs in 5.0 by having auto-updates during the activation and a chromium based webview which is update through the webstore but there are surely bugs that can't be solved that way or through Play Services.

The absence of 'forced' upgrades was probably a very good idea in order to popularize Android among OEMs but it seems to me that Google should start thinking about a way to make Android easy to update.

In that context, I would not be against reduced customization possibilities. Especially since the need for OEMs to differentiate themselves often lead to UIs with very discutable choices compared to stock Android (cough Samsung cough). Most skins brought large improvements over stock in the 1.x 2.x era, nowadays it is far more debatable.

The problem is Google are abusing their position once the customization capability is removed.

For example, they were done for using Google Street View cars to slurp WiFi information, so now they just use Android devices to do it for them. Manufacturers have to have this enabled by default if they want Gmail and the Play Store on the device. (EDIT: and even worse, if you agree to that for one device you have to agree to not release any Android devices which do not have those things, thus removing the ability for the market to decide).

When people, rightly, complain about the Facebook app having permission to do way more than it should they seem to be oblivious to the fact Google are doing things which are far worse.

> For example, they were done for using Google Street View cars to slurp WiFi information, so now they just use Android devices to do it for them.

What? Street View problems were not about slurping SSID, MAC and geolocaction from wifi's, but because of capturing snippets of broadcasted data.

They still use Google Street cars to geolocate wifi's.

> Manufacturers have to have this enabled by default if they want Gmail and the Play Store on the device.

Source for that?

> and even worse, if you agree to that for one device you have to agree to not release any Android devices which do not have those things, thus removing the ability for the market to decide

Source for that?

http://www.cnet.com/news/google-alibabas-os-is-an-incompatib...

For example. Try looking and you will find.

> For example. Try looking and you will find.

I'm still trying to grasp what has to do the Aliyun case where a member of the OHA was developing an incompatible Android version with pirated Google apps in its store with your claim that Google forces OEM's to have geolocation enabled by default.

http://www.theverge.com/2011/05/12/google-android-skyhook-la...

Here's another example of their shit.

I know, it will never be enough.

http://bostinno.streetwise.co/2014/11/06/google-lawsuits-sky...

Ups, there was not bullying. And, by the way, your claim was that Google forces OEM's to have enabled slurping of wifi data. So, I don't know why you bring the Skyhook case. Perhaps you will bring the Oracle case next. Still waiting

> I know, it will never be enough. Yes, it will never will be enough if you only bring unrelated thing, and wrong things, by the way

You need to take your blinkers off.

The 750 pages of court submissions in that link on the Verge actually answer all your supposed confusions. Seriously. The whole "technical inferiority" angle is discussed as having been invented as a way for Motorola to break off the Skyhook deal. Skyhook pass the CTS in 2009 when Google aren't paying attention but then fail when it's strategically difficult.

Basically "compatibility" is not technical at all, and entirely down to compatibility with Google strategic objectives. As Motorola quite rightly observe.

"And indeed, Skyhook ran headlong into Motorola's dependence on Google: Motorola flat-out told Skyhook that Android devices are "approved essentially at Google's discretion," and that Moto couldn't afford to risk its relationship with Google."

The key point behind the Skyhook case was that it impacted their ability to do the WiFi slurping, again, as discussed at length on that link.

Yes, you use a proof of something a The Verge article but a court ruling and a posterior appeal ruling form 2014 doesn't

And I'm the one that has to out off the blinkers.

Really?

And still waiting anything about your claim that Google forces Wifi SLURPING enabled in the smartphones

But as I know that you won't provide anything because you're wrong since the beginning and you're just bringing random links unrelated to your claim, I will leave here.

That is likely to be the actual importance of Ara: Not configurable hardware, because hardly anyone re-configures their hardware, but rather software that can be configured to a much wider range of hardware.

A more detailed response is here: https://plus.google.com/117193854832907724231/posts/1md7ruEw...

That's no so much a response as a wall-of-text that attempts to deflect any responsibility from Google at all. Given that they are so keen on pointing out the weaknesses of others in exactly this area they really need to make sure their own shit is together much better.

Sheez. So when the broken code in question is over 2 years old, and is hard to fix, then Google just washed their hands of it? Google is a big company with substantial resources. How about they support their customers beyond the "new and shiny period" like many, many other companies do?

Google could invest the resources to create patches. What Google can't do is get those patches delivered to end-user devices. Given the fact that if Google provided patches they'd never reach users anyway, why should Google bother? And we know that OEMs won't provide updates because they are already refusing to provide the one that has existed for some time now: Android 4.4.

(Disclaimer: I'm a Google employee, and I work on Android security, but I'm not a spokesperson and these are only my own opinions.)

>What Google can't do is get those patches delivered to end-user devices.

Apple manage to do it. Google made a conscious decision to trade off allowing end users to keep up to date with achieving faster adoption of Android among OEMs and carriers. You can't now pretend that the results of those decisions are some kind of inevitability. It was Google's choice, and they are responsible for the result.

>And we know that OEMs won't provide updates because they are already refusing to provide the one that has existed for some time now: Android 4.4.

Yes, OEMs like Google themselves…

Apple makes all of its devices and therefore controls them. Google can't dictate to Samsung, HTC, LG, etc.

Google has updated the in-support Nexus devices. The Galaxy Nexus is something of a question mark, but the number of active Galaxy Nexus devices is tiny. It would make more sense for Google to offer GNex users a new device than to upgrade the few remaining GNex's to 4.4.

Here's an excerpt from the article. The very first words of the article:

> A day after Google publicized a flaw in Windows 8.1 before Microsoft could do anything about it, [...]

I stopped reading after this, for obvious reasons.

That's some biased journalism there, shameful for engadget.

"Google statues on Google's Mountain View campus. A day after Google publicized a flaw in Windows 8.1 before Microsoft could do anything about it"

Biased article from line 1.

I want to like Microsoft. I really do. This kind of "journalism" isn't doing them any favors in that regard.

Is it that PR people are pushing this story, or that the clickbait potential of the headline is irresistible?

The fact is that Android 4.0+ can use Chrome, which doesn't have this bug. That's 85%+ of the installed base. This is an uncontroversial as any of the other bugs recently closed as NTBF.

That doesn't help with apps that use WebView to render web content.

WebView is embedded in many apps so using Chrome, or Firefox, won't help.

Correct. At present the only solution for pre-4.4 devices is to avoid using WebView to display untrusted content. If you're an app developer using WebView you should make sure it's only displaying trusted content which means either local content or remote content from trusted sites with non-broken SSL. I recommend using Google's recently-released nogotofail toolkit to test for SSL breakage (https://github.com/google/nogotofail).

The ideal fix for this problem is for OEMs to update devices to 4.4.

I suspect that your average Android user has no idea about the browser on their phone. These are the users who are most at risk.

Also, correct me if I am wrong, but app-based webviews (or app actions that spawn a browser instance) would defer to the default browser, ignoring any installed 3rd party browser. So i believe that the "install chrome" solution does not actually resolve the problem.

> Also, correct me if I am wrong, but app-based webviews (or app actions that spawn a browser instance) would defer to the default browser [...]

I think that is wrong, based on my phone's behaviour. Still with you, though; neglecting to fix this leaves the most vulnerable users open to attack.

That's wrong for some versions of Android, but if you have, for example, a Web wrapper around a Web app in an older version of Android that uses WebView, it's only a risk if the app somehow displays a link to an exploit. A properly designed Web wrapper uses techniques to avoid this risk: filtering urls to stay in the app's domain and, for, e.g., ads that jump outside that domain, to launch a browser.

>A properly designed Web wrapper uses techniques to avoid this risk: filtering urls to stay in the app's domain

So you are saying the WebView on Android is unsafe to use for rendering untrusted content. That's a pretty serious limitation and certainly not made clear in the documentation[1]. Infact the first line of the docs suggest that a WebView is suitable to "roll your own web browser" with…

Something is seriously wrong with Google's attitude to security if they are happy to document a class that's totally unsafe for use with untrusted data as being safe. Knowing this is enough to put me off ever using Android again to be honest.

https://developer.android.com/reference/android/webkit/WebVi...

> That's a pretty serious limitation and certainly not made clear in the documentation

Having engineered Web wrappers for a few clients, I would not have let them out the door without url filtering, and not just for security. A wild url could mess up the UX way before it becomes a security issue. Any sane "kiosk" style software should behave that way.

As for the documentation, when it was written, those statements were true. Now, with Chrome implementing WebView, that documentation is once more true. And I would STILL include url filtering in a Web wrapper.

Reply on news.ycombinator.com