Chrome is binding sessions to the TPM; Mozilla has said no to DBSC

Google’s security blog (April 9) and a Workspace update (May 28) made Device Bound Session Credentials generally available for Chrome on Windows. An August 12 recap noted the rollout had reached a portion of users from Chrome 147 on Windows and 150 on macOS, that Google’s own accounts switched in late May with no user toggle, and that Mozilla had published a negative position in early August.

What DBSC does

Chrome generates a key pair and stores the private key in the TPM (Windows) or Secure Enclave (macOS) when hardware is available. Sites issue short-lived cookies. When a cookie expires, Chrome proves possession of the key before the server mints a new one. A copied cookie expires quickly without the key. Sites add registration and refresh endpoints; the existing front-end cookie check can stay.

Mozilla’s objections

The August recap summarized two Mozilla points: DBSC still leaves a window where a stolen cookie works, and the re-authentication flow is an ad-hoc protocol that does not fit normal cookie management. Mozilla also worried sites could later demand hardware attestation. Google has said attestation of that kind is not planned. Apple has not taken a final public position; it has flagged that DBSC could complicate restoring a device from backup.

• Windows GA: Chrome 146+ (April blog); Workspace default from May 25 rollout
• macOS: announced for Chrome 150 in the August recap
• Firefox: negative position, no implementation commitment

Takeaways

• DBSC only helps on sites that implement the protocol
• There is no Chrome user setting to turn it off for Google accounts
• It is not a cross-browser standard in production yet

Source: Google / August recap