Hacker News Reader

You still haven't made a case for that being wrong.

This isn't that hard:

Bug in iOS:

1. Apple releases a patch

2. All users of supported devices can install it

Left hanging: people with old devices (minimum age approaching half a decade)

Bug in Android:

1. Google releases a patch

2. Many Nexus users can install it immediately

3. Everyone else has to beg dozens of manufacturers to ship an update for a device which brings no further revenue to the hardware manufacturer

4. At least in the U.S. everyone then has to beg carriers to ship an update to existing devices rather than using this as a chance to push you to upgrade to a $$$ new device and extended contract lock-in

Left hanging: everyone who doesn't own a recent Nexus device. Minimum age: negative – devices without the current OS will be sold to users months after release.

Note that absolutely none of this is Android's fault technically. It's only Google's fault to the extent that they naively believed everyone else would be responsible and neglected to have this license require updates, unlocking after dropping support, etc.

Both of you are right.

infinity0's point seems to be that a more fair reporting would be: (1) here's the problem with Android's ecosystem [was included] (2) here's the solution with Apple's ecosystem [was included] (3) here's the solution with OSS distros' ecosystems [was NOT included]

I think it's fair to take umbrage that an intelligent but uninformed reader could very easily walk away from that article with the conclusion that "If Google ran Android more like Apple runs iOS, then Android would be more secure."

Which itself is probably true, but far from the only solution. And indeed, probably the least free (speech) solution.

I understand the argument but it's very weak because open source projects have the same fundamental problem and we have something approaching two decades of security problems caused by it. The underlying challenge is that anyone can ship a copy of something without making a binding commitment to ship updates.

Point 3 is only true if you cherry-pick “OSS” to mean “People who installed Red Hat, Ubuntu, Debian, etc. themselves and religiously install updates”. OSS also includes things like the various forks and boutique distributions which started drifting behind, all of those insecure libraries where someone installed a copy of OpenSSL, libtiff/libpng/etc., or almost any PHP app, and never came back to update it.

This problem is only going to get worse as the IoT gold rush continues and all of these “Two EEs and a web developer” companies ship a device shortly before folding, being bought out, etc. and there's no indication to the customer when it's no longer safe to have that device on a network.

Note that this isn't saying that open-source is insecure – the same problems routinely happen with commercial software, too – but rather that it's not a magic wand for solving the problem. Apple ships updates promptly because their reputation depends on it, which is the exact same mechanism which keeps Debian, Red Hat, Ubuntu, etc. going, too, but that approach doesn't work in the case where the real customer isn't the person using the device. As long as Samsung keeps Verizon happy, they only care about the user experience to the extent that many people would choose to buy another not-Apple device instead of theirs.

Ultimately, I think we really need legal changes to ban corporate attempts to shirk liability for flaws in their products and sharp restrictions on the ability to prevent users from securing their own devices – something like a vendor being required to publish the full source, build toolchain, hardware unlocks, etc. if they go more than a couple months without releasing a patch for a known problem in a particular device.

> Ultimately, I think we really need legal changes to ban corporate attempts to shirk liability for flaws in their products and sharp restrictions on the ability to prevent users from securing their own devices – something like a vendor being required to publish the full source, build toolchain, hardware unlocks, etc. if they go more than a couple months without releasing a patch for a known problem in a particular device.

Agreed, and imho this is in practice where Android differs from OSS as I referred to it.

Worst case, if you're running a non-Redbuntianwarint distribution, then you still have much better access and separation between components. Admittedly in practice almost no one avails themselves of the ability to build from source. But that's not the point.

The point is that someone can do so, and distribute that to others if they want it.

With Android, that prospect on {random device X} gets a lot more tenuous. Either because there are hardware security locks to prevent you from doing so or because there are missing or unavailable pieces that are included in the official manufacturer/carrier's build.

This is my big irk: Shirking liability. Google, and it's fans, spend a lot of time blaming everyone else for the problem. It's the OEM's fault, or it's the carrier's fault. It's dozens of other companies fault that Android is insecure. But nobody wants to hold Google liable for developing a platform that they distribute in a manner that is completely insecure.

Google sets the terms by which it does business with OEMs. And yet, they've never been held to blame for the bad experience that users get due to this model. Google uses these terms to protect it's monopoly dominance, by mandating OEMs install 20 or so proprietary Google apps, but not to do anything really valuable to the customer, like mandating a security patching methodology.

Great comment. Who now is liable for the damage caused by hacking Android phones with this vulnerability — Google, manufacturer, carrier, or the user?

Perhaps as we get more physical hacking events that are easy for the media to cover, companies will start taking this seriously. If so, I'll guess that Google will assume that responsibility in exchange for more Apple-like control over the update process. There's no other sane way.

My instinct is that liability should go to whoever you paid: if you bought a phone from Verizon, they should be responsible for the device and do whatever they need to with the vendor without involving you in the process. If you buy the phone directly from Samsung, Motorola, etc. they're responsible and should negotiate appropriately with Google for the support they don't want to do in house.

Most of the problem is that the general cycle for Android is a decent base OS which has two levels of middlemen adding cruft to it mostly for marketing reasons and that's as bad as it is because they're only looking potential income. Not letting them dodge liability changes that calculation in favor of either not obstructing the update process for branding reasons or, if they really think their custom UI is such a great selling point, actually hiring enough people to support it reponsibly.

They don't mention (4) here's how Microsoft solves this in Windows, or how Tesla solves the problem, either, and I don't think they need to. This text is about the problem of updating a billion phones, not of updating all other kinds of stuff.

I don't see how they would have to cater for what their readers infer from this text about open source at all, as I can't find any way they even suggest that Android is open source.

The only reference to 'open' I can find in the text is "open an attachment or download a file that's corrupt.". The closest I can find to "Android is open source" is "Google gives its latest version of Android to manufacturers, and they then tweak it as they please.".

I think anybody who makes the jump from that to 'they can tweak it because Android is open source' also knows enough to not make the further jump to 'open source is dangerous'.

Not there aren't issues that get through (like this one, I believe), but you forgot:

1a) If the issue can be fixed and/or worked around in Play Services, Google does that and "everyone" gets the fix without even having to explicitly install it.

3b) For each OEM, if the problem can be fixed/worked around by updating the apps and/or frameworks they publish via the Play Store, they do that (if only for the sake of new and upcoming devices) and all of their customers get it once they install those update.

Those cover a large (and growing, because Google and the OEMs are both aligned on this) chunk of your "left hanging" users.

It's true that there are sometimes workarounds but they're only relevant to certain cases. This bug appears to be a good example of why you can't rely on being able to fix most or even the most severe ones with that approach.

#3b is particularly optimistic since that assumes an OEM will ship updates promptly and that's been the underlying problem here since day 1. It particularly wouldn't help if, say, a vendor ships an update for their flagship Android 5 devices which doesn't run on the 4.x devices which most all of their users have and will never receive an upgrade to Lollipop.

Bug in OS X:

1. goes unfixed for months

> It's only Google's fault to the extent that they naively believed everyone else would be responsible and neglected to have this license require updates, unlocking after dropping support, etc.

Otherwise known as "entirely their fault". It was very evident that this would be the case, as it was always the case before. Left to their own devices, OEMs and carriers will not approve updates because they simply don't care and have zero motivation to.

It happened with Treos, Nokias, and BlackBerries. It didn't happen with Apple because they used their clout to strongarm carriers into playing by their rules, and they are the OEM.

Google deliberately went buddy-buddy with the carriers to saturate the market as much as possible in response to the iPhone, and the concessions they made to do so are part of the reason Android devices still have this problem.

There was absolutely no reason to assume that anyone would "be responsible" if left to their own devices. It was not naivete, it was a calculated tradeoff to grant carrier control over user security, to give carriers a reason to promote Android over iOS. Google did a lot of things right with Android, this was not one of them.

> 3. Everyone else has to beg dozens of manufacturers to ship an update for a device which brings no further revenue to the hardware manufacturer

> 4. At least in the U.S. everyone then has to beg carriers to ship an update to existing devices rather than using this as a chance to push you to upgrade to a $$$ new device and extended contract lock-in

The solution is for Google to pay manufacturors (or share revenue, however you want to put it) to update all existing phones:

- Google is accountable for shipping the bug. They should pay the costs.

- Google is currently taking almost all the profits. Android phone makers, as we've all read, are running on thin margins, if they aren't losing money. The media stories that say Apple makes 95% of all mobile profits fails to include Google's profits.

Google not doing this is, IMHO, an ethical breach and putting profits before users greed. What shinratdr said.

> Everyone else has to beg dozens of manufacturers to ship an update for a device which brings no further revenue to the hardware manufacturer

I wonder why do the manufacturers even lock the phones if it brings no further revenue. They lose nothing if users where able to pull the updates directly from Google.

> I wonder why do the manufacturers even lock the phones if it brings no further revenue.

Because a Google update that conflicts with their own customization and borked the user experience would cost them future revenue, since it would reduce the chance that the user would by a phone from them in the future.

It is relevant: Apple's system is closed against meddling by lazy middlevendors as well as against the likes of us. If Apple decides that you should upgrade (or not) there's little Deutsche Telekom or Verizon or any other middlevendor can do about it.

That it's closed against us is not nice at all, but being closed against Deutsche Telekom and Verizon and such is a feature, not a bug.

How is that 'weasel wording'? That's an accurate statement of fact. The article never calls Android 'open' and doesn't blame the issue on the openness of the ecosystem.

The issue is described fairly accurately.

It would however be nice if the article brought up the point that the issue could be mitigated if users were allowed to actually control the software that runs on their phone (without hacking around restrictions). Instead most users are reliant on the device manufacturing seeing the financial incentive to provide updates.

> Instead most users are reliant on the device manufacturing seeing the financial incentive to provide updates.

Most users are reliant on this regardless. Few people possess the technical ability, much less time, to perform these tasks. Making the platform "open" and pointing to that as a solution would also be a way of weaseling out of that responsibility to users.

The number of people who could use a fairly simple third party to to update their operating system on their phone is much, much larger than the number who can figure out how to obtain root access or unlock their bootloader using a technique that varies depending on exact model number and firmware version.

Obviously there are users who will be left behind, but that is an issue for novice users of ANY free and open source software.

They are in fact, related. The Linux Distro's are OEMs. the larger ones happen to be more responsive OEM's than the OEM's on the android side.

But there are plenty of crappy, not-updated-that-often linux distros that strand users too!

Just like in android, on GNU/Linux you are dependent on how good your OEM is, and what they provide you in terms of a security update mechanism/times.

That's not "spin", that's just fact.

In practice, the situation is not directly comparable to Linux distros; Android vendors produce closed Android forks for each phone, and update these seldom and late. If someone was doing this with Linux distros, they'd be similarly nightmarish, security-wise.