
Why Google won't fix a security bug in almost a billion Android phones - moe
http://www.engadget.com/2015/01/14/google-security-bug-billion-android-phones/
======
krschultz
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.

~~~
drewg123
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?

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

~~~
wtallis
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.

~~~
deelowe
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.

~~~
wtallis
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.

~~~
deelowe
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.

------
PhasmaFelis
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.

~~~
nhayden
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).

~~~
PhasmaFelis
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.

------
on_and_off
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.

~~~
fidotron
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.

~~~
Oletros
> 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?

~~~
fidotron
[http://www.cnet.com/news/google-alibabas-os-is-an-
incompatib...](http://www.cnet.com/news/google-alibabas-os-is-an-incompatible-
version-of-android/)

For example. Try looking and you will find.

~~~
Oletros
> 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.

~~~
fidotron
[http://www.theverge.com/2011/05/12/google-android-skyhook-
la...](http://www.theverge.com/2011/05/12/google-android-skyhook-lawsuit-
motorola-samsung)

Here's another example of their shit.

I know, it will never be enough.

~~~
Oletros
[http://bostinno.streetwise.co/2014/11/06/google-lawsuits-
sky...](http://bostinno.streetwise.co/2014/11/06/google-lawsuits-skyhooks-
geolocation-tech-was-just-inferior-court-rules/)

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

~~~
fidotron
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.

------
zues
A more detailed response is here:
[https://plus.google.com/117193854832907724231/posts/1md7ruEw...](https://plus.google.com/117193854832907724231/posts/1md7ruEwBLF)

~~~
ryanhuff
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?

~~~
divegeek
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.)

~~~
anon1385
>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…

~~~
divegeek
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.

------
Yver
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.

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

------
chisleu
"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.

------
Zigurd
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.

~~~
ryanhuff
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.

~~~
irremediable
> 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.

~~~
Zigurd
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.

~~~
anon1385
>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...](https://developer.android.com/reference/android/webkit/WebView.html)

~~~
Zigurd
> _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.

