Chrome’s DBSC Stops Cookie Theft — But Linux Is Left Behind

For years, one of the most effective attacks against web users has had nothing to do with guessing passwords. Steal a session cookie — a small token the browser holds after login — and you can walk straight into someone’s account, bypassing multi-factor authentication entirely. Google’s new Device Bound Session Credentials (DBSC) standard, now shipping in Chrome 146, is designed to make that attack useless. The catch: protection is currently limited to Windows, with macOS on the near horizon and Linux receiving no commitment at all.

The Cookie Theft Problem

When you log into a website, the server issues your browser a session cookie. This token acts as a bearer credential: whoever holds it gets access, no password required. Infostealer malware families such as LummaC2 have become highly sophisticated at silently harvesting these cookies from browser memory and local storage, then exfiltrating them to attacker-controlled servers. Because cookies can remain valid for days or weeks, attackers often bundle and sell stolen sessions long after the victim’s device has been cleaned.

Historically, the defence was reactive: detect anomalous logins after the fact using heuristics around IP addresses, user-agent strings, and behaviour patterns. Persistent, well-resourced attackers learned to evade these signals. DBSC represents a shift from detection to prevention.

How DBSC Works

The core idea is elegantly simple: a stolen cookie should be useless without the private key that was created alongside it — and that key never leaves the device.

The entire process is invisible to users. Websites integrate DBSC by adding two new HTTP headers — Secure-Session-Registration at login and a refresh endpoint — while their existing authentication logic continues to work unchanged.

What Google Has Already Observed

DBSC did not launch cold in Chrome 146. Google quietly rolled out an early version of the protocol across its own properties — Gmail, Google Workspace, and Google Account sign-in — over the past year. The Chrome team reported a measurable reduction in session theft for sessions protected by DBSC during that period, lending real-world validation to the protocol before its public launch.

Platform Support: Where Things Stand

The Linux Gap

Linux users occupy an awkward position. Most modern Linux machines — especially those running on mainstream x86 hardware — ship with a TPM 2.0 chip. The kernel has had TPM support for years, and tools like tpm2-tools provide userspace access. There is no fundamental hardware barrier preventing Chrome from using it.

Yet Google has not announced Linux support. Several likely reasons contribute to the delay. Linux occupies a small slice of consumer browser market share, making it a lower priority for a feature aimed at mass-market session theft. The Linux ecosystem is also fragmented: TPM access APIs, key storage conventions, and security subsystems vary meaningfully across distributions, making a robust and consistent implementation more complex. Perhaps most importantly, Linux is far less commonly targeted by the infostealer malware families — LummaC2 and its ilk — that DBSC is specifically designed to neutralise. Attackers follow the money, and the money is predominantly on Windows.

The Longer Road: Software Keys and Broader Coverage

Google has signalled awareness that hardware-only coverage leaves gaps. The team is actively exploring software-based key storage as a fallback for devices without dedicated secure hardware — or platforms where hardware integration has not yet been implemented. Software keys offer weaker guarantees than TPM-backed ones (they can theoretically be read by sufficiently privileged malware), but they would still force attackers to operate on the victim’s device in real time rather than exfiltrating and replaying tokens elsewhere. This could extend meaningful protection to Linux users as an intermediate step, even before full TPM integration arrives.

An Open Standard, Not Just a Chrome Feature

DBSC was developed through the W3C Web Application Security Working Group, with Google and Microsoft both contributing to the specification. It was published as a First Public Working Draft on the W3C Recommendation track — meaning it is intended to become a mandatory-compliance web standard, not a Google-proprietary extension. Microsoft Edge ran its own DBSC origin trial on Windows in late 2025. Firefox and Safari are formally evaluating it.

The trajectory mirrors how other browser security standards have rolled out: one major vendor implements and validates the technology at scale, empirical data accumulates, and adoption broadens. For now, Windows users on Chrome 146 gain meaningful protection. macOS users are weeks away. Linux users remain in line — position unknown, queue length uncertain.