I think we should differentiate a TPM backed cookie from, say, a tracking cookie. It isn't like an arbitrary website can track you with the TPM. TPMs aren't exposed to the web by any browser, at least to my knowledge - except through intermediary protocols provided by something like webauthn or an extension (Extended Verification, for example).

Again, maybe someone more knowledgeable can explain more - I'm a consumer of TPMs, and I understand the concept, but I'm no expert.

For a web exposed use case: TPMs are used as part of Windows's FIDO2 implementation, to make sure that the secret actually cannot be exfiltrated to other hardware.

That doesn't come with any particular privacy concerns however.

Right, I meant that there's no javascript API to communicate with a TPM directly as far as I know. You can still use a TPM as part of your auth to a website, it just has to go through a protocol where the browser handles the interaction. So a website can't leverage the TPM for tracking purposes afaik.

But web is really not so much my thing, so I'm now at the point where I'm probably going to start saying incorrect things.

It's too low level of an interface to directly expose to web apps tbh.

Ah so the vendors implementing the WebAuthN spec in their browser can use the TPM as "secure storage" for the related keys?

Yes.

Well you can't secure normal cookies against extraction with a TPM, because you have to extract them to use them.

So the question is how a particular protocol works, and whether a site can still identify you after you've deleted your session cookie. As far as I understand it, if you were wantonly using webauthn for all your session cookies, it would be relatively easy for a site to check if you're the same person as before.

> because you have to extract them to use them

Nope, the thing is that you ask the TPM to sign something with the key/secret, but the TPM will not allow you by design to exfiltrate the secret.

Doing that would not be a normal cookie, which is my point.

You would have the TPM hold a secret that's used to repeatedly re-authenticate the session. Though today I don't know that this is often the supported workflow - for example, most of my TPM-based policies only enforce device-authentication on sign-in and not on every API call.