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

Coming soon to a car near you.


Honestly a car is one of the items where I could see a safety aspect outweighing... y'know... compared to a game console.

Not saying cars should be locked down like this, I really don't know and my first 'hacker' instinct is to say it should be free-as-in-freedom, but the argument has an extra dimension to it when compared to the Nintendo Switch.


Related to Mercedes saying they take responsibility if their self driving car crashes. It's certainly arguable if you don't take the upgrade they can stop taking responsibility at some point.


Remote attestation is the enemy of our freedom.


Remote attestation isn't inherently evil. Remote attestation can protect your privacy too. You can run code on a public cloud, with remote attestation proving that the cloud provider cannot read the memory of your VM, even if they use a malicious hypervisor.

(That's of course assuming in your threat model you trust the hardware maker but not the cloud provider. The sentiment in this thread is clearly don't trust the hardware maker.)


Or you can just run security-critical code on your own hardware on your own premises, as has been and will always be the answer for strong security. If a legal contract with a datacenter is not enough of a security guarantee, then neither is a wink from a hardware manufacturer. The societal downsides from abuse of remote attestation - eg computational disenfranchisement of end users - far outweigh any claimed benefits.


With secure attestation you only need to trust eg Intel and only when they manufactured your device, and not random cloud providers forever.

Of course, running on your 'own' hardware is a fiction, too: companies themselves are made up of contractual relationships, fiduciary duties and other legal devices.

Even if you are running your software on your own in-house datacentres, remote attestation is still useful.

(Just like git's commit hashes are still useful, not only when your code lives externally on github, but even when some other department of the same company is hosting your source code.)


I didn't say it wasn't useful. As technologists we can easily see how any given feature is useful for good, honest purposes. My point is that these purposes pale in comparison to the abuse that remote attestation directly enables - "big tech" demanding that you only run approved software to interact with them - aka computational disenfranchisement and destruction of the idea of the "user agent".

The societal situation is analogous to "Web 2.0". Everybody thought "this is neat, it lets me make interactive applications that I can share easily with my friends". Few dwelled much on how the intrinsic centralized control was a terrible dynamic. Over time, economic optimization increasingly focused on and exploited that centralized control. Now we've ended up with most people's idea of "the Internet" being choosing between least-bad corporate bundles, and just suffering all the ways they're being controlled. Remote attestation further increases that control, making it infeasible to employ software to represents your own interests.


> The societal downsides from abuse of remote attestation - eg computational disenfranchisement of end users - far outweigh any claimed benefits.

Your new comment is basically re-iterating this sentence I quoted from the old one.

I'm not sure, if I outright agree; but I do see the point and was not arguing against it.

It is indeed worrying!

> Or you can just run security-critical code on your own hardware on your own premises, as has been and will always be the answer for strong security.

My comment was arguing against this part of your original comment. On-premises doesn't have to be more secure; and it misses out on some gains from division of labour and specialisation.


> With secure attestation you only need to trust eg Intel

Exactly.


Having to trust Intel at one point in time, is less exposure than having to trust Amazon (or even your in-house employees) all the time.


Already here. Teslas cannot be downgraded, even by a service center.


What part, the Linux OS ? if so, I'd like you to cite your resources as I had assisted this in an older Telsa.


Maybe it's possible in older models. I have a 2021 Model X and asked a service center if I could downgrade the software after the new UI came out, and they told me it was impossible and that not even they could to it.

It's possible they were lying, I suppose, it would not be the first time, but it seems an odd thing to lie about.


Having XOO,OOO to XX,000,000 cars globally on N different firmware packages when your approach involves fast iteration and OTA updates, in an industry where you catch partial flak for any incident regardless of the party at fault ....

Seems reasonable to not allow random downgrading because you didn't like the UI layout.

2 cents opinion.


Well, I can understand the decision, even if I don't agree with it. The new UI has some quite serious (and now, well publicized) design flaws that could lead to a safety issue.

The correct solution would be for Tesla to fix the design flaws, of course. Or maybe to actually test their own products to find such obvious problems before they are released.


No, it's really not.

If doing thing be requires doing thing a that is unreasonable, then just don't do thing b


i believe the 3 and y have eFuses as well




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

Search: