I'm sure that the business case for it hasn't gone away, but unless they can side-channel some information out of the TPM, this proposal doesn't appear to give the server the ability to uniquely identify a visitor except through the obvious and intended method. So: maybe, but this appears to be separate.
> Servers cannot correlate different sessions on the same device unless explicitly allowed by the user.
I read it like browser can always correlate public/private key to the website (it knows if there is authenticated tab/window somewhere).
Why they are making this possible, if you could store the information in random UUID and just connect it to the cookie? What is the use case where you want to connect new session instead of using the old one?
It means that it works the same way that first party cookies already work. HN can't see my Google cookies and vice versa. If I clear my cookies Google has no way to know (aside from fingerprinting and maybe IP) that I'm the same person.
> What is the use case where you want to connect new session instead of using the old one?
Multiple accounts? Clear cookies and visit the next day? Probably other stuff as well. The import point is that DBSC doesn't itself increase the ability of website operators to track you beyond what they can already do.
It doesn't require a TPM though. It just says it CAN use one, if one is available. If it is changed to require a TPM though, then that will be a problem.
