Remote attestation is the true enemy of your freedom. The power of the authoritarian corporatocracy to force you to use only the (entire) systems they control. It's worth reading https://www.gnu.org/philosophy/right-to-read.en.html again just to see how prescient Stallman was.
RA is a technology that has its fair use, and can be desired for other systems, like in Linux. With a pure RA system your services can decide to trust or not those devices on your network that can be compromised, and report to other devices that there is something suspicious.
As anything, this can be used properly to increase the security of your edge architecture, or wrongly to limit the users actions.
Let me put another example. With RA I should be able to authorize validated systems in my R&D VPN. If you are using your own laptop with the company certificate, and the verifier tag the systems as "unknown" or "unhealthy", it will not allow the access to the internal network, but sure you can still use your laptop for anything else. This, IMHO, is a fair use of this technology.
Because god forbid you have control of your own PC?
The software you boot sets up some state and then toggles a bit, and after that something can't be changed. The state is secure against much modification after that time, but not before that time.
The "you" that boots the device are in control, and the "you" that uses the device after that have exactly what "you" set up at boot time, neither more nor less. If both "you" are the same person, then there's no loss of control.
But of course they're often not really the same person. If you want to boot a Microsoft-signed image, the party that boots is more or less Microsoft, not you personally. But in that case, you also want to use that Microsoft-signed OS, right? So the shift towards boot-time control is then a shift from mostly-Microsoft use-time control to mostly-Microsoft boot-time control. Mostly Microsoft here, mostly Microsoft there, even if the two mostlies aren't quite the same percentage it's difficult to regard this as a significant loss of control.
Perhaps you mean that if you, as owner and legitimate user of a device, are able to perform a particular change only during a brief window of time rather than at any time of your choosing, then that limits your control over the device? If so, then my answer is yes, certainly it does. But it also limits the access of anyone who impersonates you (such as the evil exploity javascript I make your browser execute).
In theory, yes, you could implement it like you said, but that's not what happens in practice nor the direction we've been tending towards in recent times.
> The "you" that boots the device are in control, and the "you" that uses the device after that have exactly what "you" set up at boot time, neither more nor less. If both "you" are the same person, then there's no loss of control.
How is it orthogonal? Okay, we're not strictly speaking of only bootloader locking, but of boot-time-control locking.
The kernel could do the same with an in-kernel process. It wouldn't have quite the same depth of defense against userspace sandbox escapes, but could be done. That's roughly how /dev/random was implemented for many years.
Look at the APIs provided — it's nothing new. It's nothing OSes haven't provided before, it's just further removed from a Chrome/FF/Safari sandbox escape, because overcoming the write-once hardware toggles is harder than getting kernel read/write primitives for a sandbox privilege escalation.