Hacker News Reader

Comment by mikegerwitz | Hacker News Reader

This was a story today:

  http://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway/

Let's say I'm a user of that vehicle. I read this article. I want my Jeep audited and fixed, and I want the code modified to indicate any time the vehicle is accepting remote commands.

You cannot separate developers and users, because users can hire developers to perform actions on their behalf. I can't fix my own car, but I have problems with it, and I want to be able to hire someone of my choosing to fix it.

View on HN

Consider an alternative scenario: malware.

In that situation, as a consumer, I'm actually pretty jazzed about living inside Apple's walled garden on my iPhone. The phone refusing to run unsigned code gives me a little bit more security.

It also largely defeats the scenario where I can hire someone to modify my phone's software. But I'm OK with that tradeoff, because I think it puts me on the side of greatest benefit to myself. I suspect most non-programmer users would fall in the same camp.

Bugs are by definition unintentional. Surely Jeep did not intentionally introduce those flaws. Code signing does not help there.

You should think what malware is. Maybe apple software is malware as well. Anyways if you could review the source code of the "malware" you (or people who can read it)could know what it does in advance and avoid it. And code could be signed and verified and still be free software. Linux distros verify software signatures and have almost no malware problems and at the same time use a lot of free software. So free software makes users more secure if anything.

If you think about it, package repositories are just like app stores. They're curated, centralized places to obtain software where you can have high confidence it's free of malware.

...And it's free software with no arbitrary usage restrictions. Meaning you can actually audit it if you so desire, and in fact you'll be doing a great service to users and developers in the process.

Exactly linux distributions have had app stores for ages which have a lot of freedom. And then there are things like the arch user repository which is even less controlled and also great.

It also allows Apple to attack its users at will.

What you're describing is security by obscurity, and it has been shown countless times that it never, ever works.

It does not prevent flaws from being discovered. It slows down the discovery of some flaws, but this also means that the people who discover them can exploit them for years if they're malicious, because flaws are equally hard to discover as part of a well-intentioned an audit as they are as part of an evil plan.

It also allows flaws that have been intentionally introduced to be hidden from sight for a long time -- and allows companies who do so to escape untarnished; since the commit logs are not available (and the source code is often only available in disassembled form), they can always claim it's a bug, not a feature.

It does not provide additional safety, it provides only an illusion of safety -- while making actual safety a lot harder to implement, for everyone.

Locking a computer into running signed code is just like programming Firefox to refuse to access https sites without properly signed certificates. There's nothing about it that's incompatible with a fully free, GPL software stack. In the case of Firefox, you're trusting the Certificate Authorities. In the case of the iPhone, you're trusting Apple.

You could argue that Firefox leaves open vulnerabilities to things like Superfish (that Windows root CA didn't actually affect Firefox in most cases since Firefox keeps its own list), but you can take the signing concept as low-level as you like, including requiring a signed OS with a hard-coded, single software delivery mechanism which could still be fully GPL.

This is what Schneier calls "security feudalism": https://www.schneier.com/blog/archives/2012/12/feudal_sec.ht...

It's a rational choice given the complexity, but makes you totally vulnerable to your feu lord. And their feu lord.

By the way, there is no necessary conflict between signing and software freedom if the system allows you to replace the master keys. Matthew Garrett is doing a collection of work to enable Linux users to use UEFI and TPM hardware to secure themselves against malware.

You get a little bit of security by trusting Apple. But Apple does not give you the option to also trust someone else.

You trade your freedom against short-term convenience. On the long-term it means that you have to accept all decisions Apple takes, even if you dislike them.

Your last paragraph seems to be a complete copy of my last paragraph. I'm not sure what point you're trying to make here?

You seen to be implying that the user is empowered only if he is also a developer, or has access to a developer. The respondent is trying to show how this is still empowerment.

Would you rather be in a position where you can't hire a developer to improve your software, or more likely download the patch that was donated to the community?

But his point was also that access to a developer is empowerment, which is exactly what I said.

I say he's trying to tell you that like I know; I should have said I presume that's what he was getting at. On a first reading, that was my interpretation. A very common argument criticising free software is that, since most users can't code, they cannot benefit from the 4 freedoms. This probably prejudiced my interpretation of your comment. Reading it back now I can see what you meant.

Sorry about that: I misread "can not" as "can".

Your intentions were unclear. When I read your post it sounded like you were arguing that the GPL was to protect developers, not users. The edge case where user = developer isn't an immediately obvious one so it bears clarification.

Reply on news.ycombinator.com