Could you please stop posting flamebait and snark? Your account has unfortunately been doing this repeatedly. It's not what this site is for, and destroys what it is for.
I truly believe that we'll see a world where everything requires remote attestation and corporate approved devices within the next few years. It's a nightmare scenario for me and I consider it inevitable. I just don't have much more than sad cynicism left since it seems to become worse every day.
I hear you about this issue (corporate control over devices, let's call it) and of course a large segment of the community agrees with you. Howwever, the moderation point here isn't about that; it's about a style of commenting that we're trying to avoid here. Your account has been posting in that style on unrelated issues too, so I think this is independent of the specific content.
Yes it absolutely is and will be used as such, this is EXACTLY how google play remote attestation works and a necessary building block for doing it in the browser. It is the exact reason why microsoft and google are pushing for tpms in windows 11 and it's already a reality on android and every grapheneos user knows the pain[0] and is the absolutely logical next step.
I read that not as a claim that this is an attestation mechanism, but that this is another step towards that. Given that Google has previously discussed implementing the Web Integrity API, it's not so large a leap as to be dismissed as disconnected from reality.
I am glad I got to experience the internet before this. It seems sadly inevitable. What was once built by and for the people has been taken over by the interests of the rich and powerful.
The very next step they will take is that they will only give devices session credentials that pass remote attestation, preferably to the browser level. Than you won't be able to use alternative clients or extension google doesn't deem acceptable.
~~~~But your VM TPM won't be signed during manufacturing by a trusted root. No attestation.~~~~
OK I take it back, privacy is one of their specified goals:
> Note that the certificate chain for the TPM is never sent to the server. This would allow very precise device fingerprinting, contrary to our privacy goals. Servers will only be able to confirm that the browser still has access to the corresponding private key.
However I still wonder why they don't have TLS try and always create a client certificate per endpoint to proactively register on the server side? Seems like this would accomplish a similar goal?
> why they don't have TLS try and always create a client certificate per endpoint to proactively register on the server side
That is effectively what Token Binding does. That was unfortunately difficult to deploy because the auth stack can be far removed from TLS termination, providing consistency on the client side to avoid frequent sign outs was very difficult, and (benign) client side TLS proxies are a fairly common thing.
Dude; please stop spamming misinformation, this was already debunked in previous commentary you saw and responded to, showing that the website never sees the raw TPM data at any stage under this proposal.
Session cookies have zero correlation to fingerprinting.
Well, it's a good thing Device Bound Session Credentials (DBSC) as proposed here has no way to actually send said endorsement key anywhere; rending the objection irrelevant. The TPM is only for secure storage as verified by the browser itself, not the website being visited.
> You all don't understand how any of this tech works but you think you do.
We do; and it is specifically called out in the spec that the certificate chain is not submitted, due to the potential for overpowered fingerprinting. As such, this battle, should they make a move to change that, needs to be fought a different day. Fighting against hypotheticals is pointless.
Edit: For the pedantic, fighting against hypothetical things that they could do if they invented something that doesn't exist right now, is pointless.
Edit 2: You can't boil a frog without ecosystem cooperation. The internet isn't going to bow to inconsistent adoption. They already made it clear with WEI they have no interest.
No, fighting against things that have already happened is pointless. We only ever fight against hypotheticals. We fight to avoid something happening that has not happened.
> Edit: For the pedantic, fighting against hypothetical things that they could do if they invented something that doesn't exist right now, is pointless.
But it ALREADY EXISTS on Android[0] and has been proposed by google to be added to chrome before [1]. They are OBVIOUSLY using a boil the frog approach here like forcing android devs to register to sideload [2]. This is obviously designed to slowly roll out these checks small steps at a time. To not see that is to be willingly ignorant.
This inexplicable overreaction to genuinely valuable security improvements is getting ridiculous. Computer security is a complete dumpster fire right now and we need things like this.
To everyone who has ever had session creds stolen? Right now any malware which can read your disk has a gigantic backdoor around MFA, do you not find that a problem?
If you have malware that can read your disk, then you have bigger issues than MFA?
In other words - focus on solving the real issue (ability to give more fine-grained permissions to programs) rather than restricting the ability of users to do what they want with credentials they already have on hardware they control.
Next up: Only devices running a remotely attested browser running signed code and no extensions gets to connect to these services.
Cattle, meet your butcher.