> I would say that specifically with Secure Boot, Microsoft actually promoted user choice: A Windows Logo compliant PC needs to have Microsoft's root of trust installed by default. Microsoft could have stopped there, but they didn't.
This was not the case with the initial rollout of Secure Boot, it was combined with locked BIOS to lock PCs so that they could only boot Windows 8 on some devices. This was the case on Windows RT ARM machines from that era.
All that has to be done today for machines to be locked down again is to flip a bit or blow an e-fuse. It's already the case on phones and tablets.
There is also a real potential for abusing TPMs or cryptographic co-processors to enforce remote attestation.
I say this as someone who agrees with your first paragraph and uses Secure Boot + TPMs on all of my machines.
And it's already happening in the form of Google play integrity API. Many apps already require it. It's just a matter of time before they push similar tech to the desktop. And on mobile it hurts more because many banks now require a mobile app for 2FA.
Personally I think any form of attestation is evil.
There's a reason Microsoft is aggressively deprecating "older" CPU's that work perfectly fine. Heck, I have one laptop with Windows 11 that worked great, but won't update from 22h2 to 24h2 because CPU support was dropped between versions, leaving me with only the glib suggestion from the Windows Update UI to "Buy a new device".
Ironically, installing Windows 10 and activating ESU would lead to longer hardware life.
Of course, I didn't. Instead, I installed Linux on that laptop too. My partner had no issues switching.
TPM wasn't the only reason older CPUs were dropped. The biggest reasons where the line in the sand Microsoft chose would not be supported in Windows 11 was Spectre/Meltdown [0] mitigation. Windows 10 added a bunch of intentional slowdowns to mitigate that disaster and people incorrectly blamed Windows 10 for being slow and not the CPUs and their CVEs. Windows 11 seems to have wanted a clean slate without needing to have any of those slowdown mitigations in the codebase and eliminate some classes of "Windows 11 is slow on my machine" complaints.
I'm not sure Microsoft took the best approach. I might have opted into a "Windows 11 Slow CPU" SKU if it was marketed right. That might have been a little kinder than "all these CPUs with this awful series of bugs are trash, even though we have had a successful workaround".
Yes, Microsoft is blocking CPUs which lack the ability for Virtualization Based Security. Given OS security is important to Microsoft (surprise, I know), enforcing VBS is a priority.
I think "chooses to" is doing a lot of work there in your understanding. Spectre exploits were found in the wild even in JS code submitted to ad networks. I suppose a user could choose to uBlock all ad JS and never visit webpages they don't trust. Those are choices, sort of.
But also that's a bit victim blaming isn't it? Do you want to explain to your grandfather or partner or child "Oh sorry, you had a password stolen because you chose to visit Google.com on a day where Google let an ad buyer attach Spectre exploit malware"? (Google could also chose to not let ads attach JS at all, but that's a very different problem.)
Computers have millions of places they get code from to run. Is "your CPU has a data leaking bug in it" the user's problem or the OS's problem? When there's a mitigation the OS can manage? When security-in-depth is an option?
I installed Bazzite on my own old Desktop not supported by Windows 11. One of the first things the Linux kernel spits out on boot if I have the boot console up is about running with Spectre mitigations. The Linux kernel also thinks it is important to mitigate (as Windows 10 did, but Windows 11 doesn't include and so doesn't support this old Desktop).
Sure I am might have been a wee bit too bitter writing that.
The point I want to make is that allowing remote code execution is such a big attack surface that it makes all the other security measures look silly, which indicates that signed execution contexts in them self is an attack on privacy and control etc.
If there was any actual security concerns there could be a push for server side rendering or something.
> People here REALLY need to start understanding this issue.
The idea that understanding is the problem feels like a fallacy. People need to upgrade hardware, and when all chips contain such functionality, consumers won't have a choice of alternatives. What you want is legislation (or a dominant competitor lacking such features, which doesn't exist).
No, I think they bend over backwards not to do it overnight because of the outcry but try to make all required changes and enforcements gradually over the years so in the end you will have no choice but there will not be any sudden change that would spark protests.
> This was not the case with the initial rollout of Secure Boot, it was combined with locked BIOS to lock PCs so that they could only boot Windows 8 on some devices. This was the case on Windows RT ARM machines from that era.
Okay, but, that was like 15 years ago, on some shitty first-run computers that no one bought. A failed first attempt. I've never met a single person that owned, or has ever used, a Windows RT device.
The world has moved on. But oddly continues to buy bootloader-locked iPhones and Androids by the bucketful.
Dwelling on the past isn't going to move us forward. Anyone pushing the "Secure Boot and TPM are evil" trope in 2025 is objectively a fool and should be ignored. Most don't even realize what a TPM does, they think it's some secret chip inserted by glowies into their computers to prevent them from running free software. No.
Normally I would agree that security measures are needed in many, but not all cases, but only if they are in complete control of the user and cannot by altered by any one organization. For-profit companies cannot be in control of these mechanisms. We have seen how they can be abused with the latest decision by Google to limit side-loading to people who identify themselves. So your take is really a misdirection from how these tools are being used against our property.
> For-profit companies cannot be in control of these mechanisms.
But they are not in control of Secure Boot.
Microsoft runs a root CA that is pre-installed on most PCs. It could have been Verisign or someone else, but MS made sense at the time, likely because they had additional code signing expertise.
You are free to delete these keys and/or install your own. If there wasn't preexisting infrastructure, Secure Boot would be DOA for most people.
Microsoft can force manufacturers to can change the way that works at any time, its vendor specific and they are totally in control, via pressure on manufactures to toe that line if they want to continue sell computers with Windows.
Don’t confuse the real point with the caricature. There’s a very real risk of only giant corporations being able to control software, because the general public does not even draw a distinction between “having control over what software is running on your computer,” and “being able to run a curated collection of software blessed by the manufacturer and subject to their exclusive discretion.” The full acceptance of the Apple iOS platform proves this. Apple must bless all binaries, and except for cases that are getting less and less common where jailbreaks are possible, the user has no authority and you could argue they do not own the device.
Some combination of the advertising industry and those with a vested interest in anti-fraud such as banks will eventually try to sneak remote attestation in there, which has the potential to put a complete end to ownership of devices as we have always understood it.
I wouldn't mind that if in fact the parent poster didn't try to make it look like an argument that Microsoft is kind and playing nice. They did a bad thing there, there was an outrage, they fixed it, the end. If possible, they will do another bad thing again, should it benefit them.
> Okay, but, that was like 15 years ago, on some shitty first-run computers that no one bought.
I wouldn't call the first Microsoft Surface, Surface 2, Dell XPS 10, and Lenovo IdeaPad Yoga 11 products that no one bought.
> I've never met a single person that owned, or has ever used, a Windows RT device.
I have and I also regrettably bought one myself.
> Dwelling on the past isn't going to move us forward.
The past dictates the future, and history repeats itself. Microsoft made their intentions known, it would be foolish to pretend they haven't. They continue to make their intentions known today with the Pluton cryptographic co-processor, that paired with a TPM, can enforce remote attestation by design. That is literally the intent of the Pluton chip: ensuring platform integrity and securely attesting to 3rd parties that your system is Blessed/trusted.
> Anyone pushing the "Secure Boot and TPM are evil" trope in 2025 is objectively a fool and should be ignored
Anyone tearing down this strawman is tilting at windmills for some reason.
> Most don't even realize what a TPM does, they think it's some secret chip inserted by glowies into their computers to prevent them from running free software.
I wouldn't project ignorance on those you don't actually know. You can understand what a TPM does, understand how it can be abused today and acknowledge how it was abused in the past.
> There is also a real potential for abusing TPMs or cryptographic co-processors to enforce remote attestation.
Remote attestation can be misused, yes. But why writing it as TPM is the problem? In cases where remote attestation is used for good, TPM improves the setup, if anything.
I dont see the rationale for what you wrote, and am genuinely curious what it is.
You can't do remote attestation without something like a TPM.
Let's compare these scenarios:
A) TPMs are optional and 30% of users have them. A bank is thinking about requiring remote attestation to use their services. Since they'd lock out 70% of users they decide to not do it.
B) TPMs are mandatory and 90% of users have them. A bank is thinking about requiring remote attestation to use their services. Since they'd only lock out 10% of users they decide to do it.
And banking is the nice example here. Refusing to serve a site if the user is using an ablocker is very much in the interest of powerful players in the space, see WEI. Every platform that has wide spread TPM adoption, namely Android and iOS have shown that they will abuse them for anti-consumer purposes sooner or later. We are talking about Microsoft here, the current and past poster child for anti-consumer decisions.
I hope that explains why making TPMs blanket available introduces new risks to sovereign computing.
I see your point. Its the very unbalanced power balance between consumers and providers, and the dishonest tactics of the latter. It ought to be addressed politically (its idealistic, I know). Until then use free software and multiple devices, or something like that. The TPM chips in themselves are a powerful concept, that can, and should, be used to the consumers advantage.
Because that's what has been going on in the Android world for years and for the iPhone was the case from the start.
Root your phone, even if it is just for the ability to make full backups (because that is, to this day, not a thing on Android)? Say goodbye to banking, most games, even the proposed new EU "digital identity" government wallet was supposed to enforce attestation.
And everyone with a phone on the "bad vendor" list that either doesn't get Google certification from the start or gets it revoked due to sanctions? Same.
Then you really should be angry at Apple and Google, not the hardware.
The preparations for eIDAS 2.0 (the EU thing) has been heavily inspired by SSI. If they keep up the good work, and implement it properly, security and privacy will be top notch. And that is only possible by using TPM (or really SE when we talk about mobile phones).
Yes, I know that eIDAS might end up not meeting the early promises. We will have to see. But in that case it will be despite the possibilities that the hardware provides, not because of them.
TPMs form the root of trust needed for remote attestation. If not TPMs, cryptographic co-processors can do similar things, or work in tandem with TPMs to accomplish the same thing.
This was not the case with the initial rollout of Secure Boot, it was combined with locked BIOS to lock PCs so that they could only boot Windows 8 on some devices. This was the case on Windows RT ARM machines from that era.
All that has to be done today for machines to be locked down again is to flip a bit or blow an e-fuse. It's already the case on phones and tablets.
There is also a real potential for abusing TPMs or cryptographic co-processors to enforce remote attestation.
I say this as someone who agrees with your first paragraph and uses Secure Boot + TPMs on all of my machines.