Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



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.


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


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: