I’m actually surprised none has heard or talked about this considering to my understanding this is utilizing encryption and it’s founded fundamentally to prevent stealers (on the browser side).
It is also a standard to utilize the TPM on your computer so another use of that TPM chip and a useful one at that. This might be the “HTTPS of Cookies” we’re looking for. This will mean that 2FA and passkeys mechanisms we recommend are fully effective if the standard is adopted.
Keep in mind that we know it is in testing and can be enabled on chrome in the flags (not sure about chromium) and no website utilizes it but I thought I’d point out especially as PG and all other websites rely on cookie to save logins.
The Github readme goes all in details so I would encourage reading it instead as it highlights everything including the non-goals.
Keep in mind that we know it is in testing and can be enabled on chrome in the flags (not sure about chromium) and no website utilizes it but I thought I’d point out especially as PG and all other websites rely on cookie to save logins.
I really dont think rubbing it in was necessary (outside of sharing the video so thanks for that)
On the blog though:
Improving user protection
We are currently experimenting with a DBSC prototype to protect some Google Account users running Chrome Beta. This is an early initiative to gauge the reliability, feasibility, and the latency of the protocol on a complex site, while also providing meaningful protection to our users. When it’s deployed fully, consumers and enterprise users will get upgraded security for their Google accounts under the hood automatically. We are also working to enable this technology for our Google Workspace and Google Cloud customers to provide another layer of account security.
This prototype is integrated with the way Chrome and Google Accounts work together, but is validating and informing all aspects of the public API we want to build.
From a privacy perspective a site could just probe if your browser supports DBSC, and if you do you are on Windows and have a TPM chip. Another thing to disable in chrome://flags when it lands.
Each session is backed by a unique key and DBSC does not enable sites to correlate keys from different sessions on the same device, to ensure there’s no persistent user tracking added. The user can delete the created keys at any time by deleting site data in Chrome settings. The out-of-band refresh of short-term cookies is only performed if a user is actively using the session (e.g. browsing the website).
DBSC doesn’t leak any meaningful information about the device beyond the fact that the browser thinks it can offer some type of secure storage. The only information sent to the server is the per-session public key which the server uses to certify proof of key possession later.
Until the W3C doesn’t make it a web standard I’m very skeptics it will be widely adopted. It’s been discussed but usually it takes quite a long time. It would be cool though.
Interesting but it still won’t solve the problem because the attacker can use the victim’s browser remotely and do whatever they want that way. This problem wasn’t even a browser issue to begin with, it’s the OS that should enforce proper sandboxing.
It is super common to “bind” credentials to contexts / sessions. Pretty standard design choice in any of the new protocols / frameworks that have been standardized or are being standardized. As for www cookies… they were born in a wide-open jar different world and (I imagine) have a lot of catching up to do.
yt-dlp for YouTube video downloading and similar utilities utilise browser cookies in order to bypass Google’s attempts to block it. I wouldn’t be surprised if this is the biggest motivation for this “feature” given their every attempt to enshittify YouTube and any ad/frontend bypasses.
