[9NRtKyP4]

Remote attestation is another technology that is not inherently restrictive of software freedom. But here are some examples of technologies that have already restricted freedom due to oligopoly combined with network effects:

* smartphone device integrity checks (SafetyNet / Play Integrity / Apple DeviceCheck)

* HDMI/HDCP

* streaming DRM (Widevine / FairPlay)

* Secure Boot (vendor-keyed deployments)

* printers w/ signed/chipped cartridges (consumables auth)

* proprietary file formats + network effects (office docs, messaging)

[cwillu]

It very clearly is restrictive of software freedom. I've never suffered from an evil maid breaking into my house to access my computer, but I've _very_ frequently suffered from corporations trying to prevent me from doing what I wish with my own things. We need to push back on this notion that this sort of thing was _ever_ for the end-user's benefit, because it's not.

[Gigachad]

Remote attestation seems more useful for server hosts to let VPS users verify the server hasn’t been tampered with.

[UltraSane]

YOU can use remote attestation to verify a remote server you are paying for hasn't been tampered with.

[avadodin]

To play devil's advocate, I don't think most people would be fine with their car ramming into a military base after an unfriendly firmware update.

However, I agree that the risks to individuals and their freedoms stemming from these technologies outweigh the benefits in most cases.

[myaccountonhn]

It's interesting there's no remote attestation the other way around, making sure the server is not doing something to your data that you didn't approve of.

[minitech]

There is. Signal uses it, for example. https://signal.org/blog/building-faster-oram/

For another example, IntegriCloud: https://secure.integricloud.com/

[tryauuum]

confidential computing?

[9NRtKyP4]

The authors clearly don’t intend this to happen but that doesn’t matter. Someone else will do it. Maybe this can be stopped with licensing as we tried to stop the SaaS loophole with GPLv3?

[digiown]

I am quite conflicted here. On one hand I understand the need for it (offsite colo servers is the best example). Basic level of evil maid resistance is also a nice to have on personal machines. On the other hand we have all the things you listed.

I personally don't think this product matters all that much for now. These types of tech is not oppressive by itself, only when it is being demanded by an adversary. The ability of the adversary to demand it is a function of how widespread the capability is, and there aren't going to be enough Linux clients for this to start infringing on the rights of the general public just yet.

A bigger concern is all the efforts aimed at imposing integrity checks on platforms like the Web. That will eventually force users to make a choice between being denied essential services and accepting these demands.

I also think AI would substantially curtail the effect of many of these anti-user efforts. For example a bot can be programmed to automate using a secure phone and controlled from a user-controlled device, cheat in games, etc.

[yencabulator]

> On one hand I understand the need for it (offsite colo servers is the best example).

Great example of proving something to your own organization. Mullvad is probably the most trusted VPN provider and they do this! But this is not a power that should be exposed to regular applications, or we end up with a dystopian future of you are not allowed to use your own computer.

[trelane]

On the other side, Mulvad is looking at remote attestation so that the users can verify their servers: https://news.ycombinator.com/item?id=29903695

[Foxboron]

> * Secure Boot (vendor-keyed deployments)

I wish this myth would die at this point.

Secure Boot allows you to enroll your own keys. This is part of the spec, and there are no shipped firmwares that prevents you from going through this process.

[LooseMarmoset]

Android lets you put your own signed keys in on certain phones. For now.

The banking apps still won't trust them, though.

To add a quote from Lennart himself:

"The OS configuration and state (i.e. /etc/ and /var/) must be encrypted, and authenticated before they are used. The encryption key should be bound to the TPM device; i.e system data should be locked to a security concept belonging to the system, not the user."

Your system will not belong to you anymore. Just as it is with Android.

[yjftsjthsd-h]

> This is part of the spec, and there are no shipped firmwares that prevents you from going through this process.

Microsoft required that users be able to enroll their own keys on x86. On ARM, they used to mandate that users could not enroll their own keys. That they later changed this does not erase the past. Also, I've anecdotally heard claims of buggy implementations that do in fact prevent users from changing secure boot settings.

[digiown]

> Secure Boot allows you to enroll your own keys

UEFI secure boot on PCs, yes for the most part. A lot of mobile platforms just never supported this. It's not a myth.

[201984]

What about all those Windows on ARM laptops?

[Brian_K_White]

I wish the myth of the spec would die at this point.

Many motherboards secure boot implimentation violates the supposed standard and does not allow you to invalidate the pre-loaded keys you don't approve of.