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)
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.
This happens much less frequently than the manufacturer of "my" computing device verifies that I haven't tampered with it. On net, it's a wholesale destruction of user freedom.
"it's a wholesale destruction of user freedom." This is ridiculously hyperbolic language for what are basically fancy digital signatures. There is nothing stopping you from using two different systems, one that passes attestation and one that doesn't.
The better question then is why the actual f** can an OTA firmware update touch anything in the steering or powertrain of the car, or why do I even need a computer that's connected to anything, and one which does more than just make sure I get the right amount of fuel and spark, or why on earth do people tolerate this sort of insanity.
If a malicious update can be pushed because of some failure in the signature verification checks (which already exist), what makes you think the threat actor won’t have access to signing keys?
This is not what attestation is even seeking to solve.
Firmware upgrades don't need to use the same protocols. Without secure boot any applet can take a security hole escalate and persist until you take a trip to a zone of interest.
With secure-boot+attestation, the vendors can choose not to let you download the latest map data, report you to the authorities, etc.
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.
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?
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.
> 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.
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.
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.
Banks do this because they have made their own requirement that the mobile device is a trust root that can authenticate the user. There are better, limited-purpose devices that can do this, but they are not popular/ubiquitous like smartphones, so here we are.
The oppressive part of this scheme is that Google's integrity check only passes for _their_ keys, which form a chain of trust through the TEE/TPM, through the bootloader and finally through the system image. Crucially, the only part banks should care about should just be the TEE and some secure storage, but Google provides an easy attestation scheme only for the entire hardware/software environment and not just the secure hardware bit that already lives in your phone and can't be phished.
It would be freaking cool if someone could turn your TPM into a Yubikey and have it be useful for you and your bank without having to verify the entire system firmware, bootloader and operating system.
> 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.
Don't get me wrong, I'm happy to attribute a lot of malice to Microsoft, but in this case I really do believe that it was incompetence. Everything I've ever read about 90%+ of hardware vendors is that shipping hilariously broken firmware is an everyday occurrence for them.
This reminds me of when I enrolled only my own keys into a gigabyte AB350 and I just soft-bricked it because presumably some opt-rom required MS keys.
I exchanged it for an Asrock board and there I can enable secure boot without MS keys and still have it boot cuz they actually let you choose what level of signing the opt-rom needs when you enable secure boot.
What I want to say with this is that it requires the company to actually care to provide a good experience.
Note that the comment you replied to does not even mention phones. Locked down Secure Boot on UEFI is not uncommon on mobile platforms, such as x86-64 tablets.
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.
> I would suggest, as a more hopeful-looking idea for getting an improved quantum theory, that one take as basis the theory of functions of a complex variable.
Quantum physics is based on complex Hilbert spaces. This is quite different to the theory of functions of a complex variable. I think Dirac was just making s!!t up here.
But anyway, by now modern theoretical physics has hoovered up quite a lot of 19th century pure mathematics, including this theory mentioned by Dirac. Specifically I'm thinking of things like conformal field theory.
> There has never been any "study" showing that "women talk almost three times as much as men", although this non-existent "research" has been cited by dozens of science writers, relationship counselors, celebrity preachers, and other people in the habit of claiming non-existent authoritative support for their personal impressions;
Well shit my bad. That was the top result from Google with just those numbers quoted when I searched for average number of words spoken per day. I should've been more thorough. Let me see if I can find better numbers.
* 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)
reply