> > they [the TCG] made a very simple but powerful scheme that doesn't in fact infringe on users rights
> This is straight up false in the standard model where protocols are what mediates between otherwise-independent parties.
I've answered this elsewhere. TPMs are neutral technology enabling technology that you might approve of and technology you might disapprove of.
> If a remote party can verify the software I am running on my machine against my wishes, that creates a security vulnerability that prevents me from running software of my choice.
TPMs do not prevent you from having opt-out.
The matter of whether someone can give you only a binary choice of opting into or out of walled gardens is a market/political problem. I don't see how to prevent walled gardens using technology, especially when walled gardens vendors can make it so you can only access the walled gardens on devices that they manufacture (or bless) -- it's their tech, so what can you do to make it not possible for them to implement lock-in? It's just not possible.
> I've answered this elsewhere. TPMs are neutral technology enabling technology that you might approve of and technology you might disapprove of.
And I strongly disagree! A TPM with an attestation key that is known to the previous owner (eg manufacturer or distributor) allows the previous owner (and everyone who trusts them) to compel the current owner to verify what software they are running on their own machine. The presence of the neutral hardware capability, plus the non-neutral treat-owner-as-an-attacker security property that the owner cannot read the private attestation key, creates a non-neutral security vulnerability for the owner. Hence my point (3) to mitigate this vulnerability by making it so that the owner can always choose to emulate an attestation. This property would make the hardware feature actually neutral.
> it's their tech, so what can you do to make it not possible for them to implement lock-in?
The problem is not set top boxes and other narrow-purpose devices created by vertically integrated companies - code signing is enough to lock those down and guarantee the creation of e-waste. Rather the issue is general purpose computers including hardware that allow remote parties to dictate what code you're running when you interact with them. For example, a bank that says "for [our] security, you must run a known copy of MS Windows with a known copy of InterChrome Explorer to access our website" (or analogous proprietary environment). The market basically moves in lock step, so you won't be able to choose a different bank (just as with the now-common "SMS 2FA" hassle). So given the basic non-neutral capability, corporations can gradually shove the general purpose computing genie back in the bottle, rather than having to make due with trusting device owners.
With binary/proprietary software, a similar dynamic exists right now. But for important cases it's possible to reverse engineer protocols and make third party clients. Owner-hostile remote attestation closes off the escape. This further pushes us into computational disenfranchisement, where the computer you purportedly own, that's sitting right in front of you, is enforcing the rules of the corporate-government power structure rather than functioning as your agent.
We do need to win the battle in the market, but to do that we at least need an option for people to buy that respects their freedom. Saying "buy this corporate phone and then run this procedure to change the TPM key [destroying your ability to use corporate-based attestation]" isn't a compelling story, but saying "buy this freedom-respecting computer based on a freedom-respecting TPM" is. We need enough of the people doing the latter that it is market-infeasible for banks et al to require remote attestation.
> A TPM with an attestation key that is known to the previous owner (eg manufacturer or distributor) allows the previous owner (and everyone who trusts them) to compel the current owner to verify what software they are running on their own machine.
The user can change the seeds and this stops being the case. Also, this feature is very useful in enterprise settings. Useful here, harmful there -- that's what makes the technology neutral. Even if TPMs didn't have endorsement key certificates, the platform vendor could add its own -- TPMs would be pretty useless without being able to derive keys from seeds or wrap keys, but having that feature is enough to make possible what you dislike.
> Saying "buy this corporate phone and then run this procedure to change the TPM key [destroying your ability to use corporate-based attestation]" isn't a compelling story [...]
You wouldn't say that. You'd say "buy this [device] and install [certain OS] on it". Why would vendors pre-ship the thing that they don't want? The user has to do something, but it can be made easy.
It's like you didn't read this subthread. You can't keep them from making sure that customer devices have this sort of hardware, not without resorting to legislation that you'll never get, so getting to at least have an opt-out is a lot better than not.
> This is straight up false in the standard model where protocols are what mediates between otherwise-independent parties.
I've answered this elsewhere. TPMs are neutral technology enabling technology that you might approve of and technology you might disapprove of.
> If a remote party can verify the software I am running on my machine against my wishes, that creates a security vulnerability that prevents me from running software of my choice.
TPMs do not prevent you from having opt-out.
The matter of whether someone can give you only a binary choice of opting into or out of walled gardens is a market/political problem. I don't see how to prevent walled gardens using technology, especially when walled gardens vendors can make it so you can only access the walled gardens on devices that they manufacture (or bless) -- it's their tech, so what can you do to make it not possible for them to implement lock-in? It's just not possible.