The sysadmin documents that Google's interstitial fires on Firefox's user-agent string rather than actual DBSC capability — Safari also lacks DBSC but escapes the warning. Combined with the YouTube Polymer v1 episode in 2018 and the Meet hardware acceleration block in 2020, they argue the pattern is too consistent across eight years to be coincidental.
The editorial explicitly concedes DBSC is 'genuinely a good idea' for stopping session-cookie theft, which has become the dominant post-MFA attack vector. Binding cookies to a TPM or Secure Enclave makes stolen tokens worthless off the original device — a real defensive win regardless of who shipped it first.
The editorial highlights that Safari has not shipped DBSC either, yet Safari users see no interstitial — only Firefox is flagged. This proves the gate is keyed on the user-agent string rather than whether the browser actually supports the new credential binding, undermining the security justification.
The editorial notes Mozilla engineers have publicly tracked the DBSC spec and filed feedback on the IETF draft, signaling cautious interest. But with no shipped code and no timeline, Firefox users get blocked regardless of Mozilla's standards-process participation — a structural problem when the spec author also controls the dominant browser and a key web property.
A system administrator's post on tales.fromprod.com — currently sitting at 493 points on Hacker News — documents a fresh interstitial appearing on Google Workspace sign-in flows when accessed from Firefox. The screen labels Firefox an unsupported browser, cites "advanced security" as the rationale, and warns that access may be blocked outright in a future update. The behavior reproduces on current Firefox ESR and stable channels on Linux, macOS, and Windows. Chrome, Edge, and Brave (all Chromium) pass through cleanly.
Google's stated reason is security. The actual mechanism is Device-Bound Session Credentials (DBSC), a draft spec incubated in Chromium that binds a session cookie to a hardware-backed key — typically a TPM 2.0 module or Apple Secure Enclave. Once bound, a stolen cookie is worthless off the original device because every refresh requires a signature only that hardware can produce. DBSC is genuinely a good idea for stopping session-cookie theft, which is now the dominant post-MFA attack vector — and it is also, conveniently, only shipped in Chromium.
Firefox has not implemented DBSC. Mozilla engineers have publicly tracked the spec, filed feedback on the IETF draft, and signaled cautious interest, but there is no shipped code and no timeline. Safari hasn't shipped it either, but Safari users don't see the interstitial — Google's filter is browser-string-specific, not capability-specific.
This is the third time in roughly eight years that Google has used a "security" or "performance" framing to gate a core property behind Chromium. In 2018, the YouTube redesign quietly used a deprecated Polymer v1 API that ran 5x slower on Firefox and Edge until Mozilla patched around it. In 2020, Google Meet refused to enable hardware video acceleration outside Chrome. In 2026, the lever is DBSC. The pattern is so consistent that the question isn't whether the lockout is intentional — it's whether intentionality even matters when the outcome is identical.
The DBSC debate is a real one and worth getting right. Pro-DBSC: session cookie theft via infostealer malware is the actual breach vector behind most of the past two years' high-profile SaaS compromises — Snowflake, Okta-adjacent supply chain attacks, the LastPass blast radius. Hardware-bound sessions kill that class of attack outright. Anti-DBSC-as-deployed: a draft spec written and shipped by one vendor, then used as a market-access gate by a property that vendor controls, is the textbook definition of embrace-extend-extinguish. The same technique could be standardized through W3C with a multi-vendor implementation commitment first. Google chose not to wait.
Mozilla's revenue structure is the part that nobody on Hacker News is discussing enough. Roughly 80% of Mozilla Corporation revenue comes from a single line item: Google paying to be the default search engine in Firefox. That contract was extended through 2026 in a deal originally signed before the DOJ's antitrust verdict against Google Search. The renewal is now in active renegotiation under court-supervised remedies. If Google walks — or if the DOJ forces a structural separation — Mozilla loses its operating budget in a single quarter. A Workspace block doesn't have to actually ship to apply pressure; the interstitial is the message.
Mozilla's past responses to similar pressure are not encouraging. The YouTube/Polymer episode produced angry blog posts and a slow patch. The Manifest V3 fight produced a brief delay and then quiet capitulation on most extension API parity. Mozilla's pattern when Google leans is to publish a position paper, then ship the thing anyway six months late. A DBSC implementation in Firefox is now the rational engineering response, regardless of the standards politics.
If your organization runs Google Workspace and has any meaningful Firefox population — research teams, security teams, dev teams that test cross-browser, anyone on Linux — start the conversation now, not the week the block lands. Three concrete things to do this quarter:
Audit your SSO surface. If you use Google Workspace as your IdP for downstream SaaS via OIDC or SAML, a Firefox lockout at the Workspace login screen cascades into every app that federates through it. Map which apps actually require Workspace login vs. which just offer it as an option, and make sure your fallback IdP path (Okta, Entra, whatever) is wired and tested. The blast radius of a Workspace browser block isn't Gmail — it's every SaaS your engineers log into via "Sign in with Google."
Decide your DBSC posture. If you ship a web app with session cookies — which is approximately all of you — DBSC is going to land in your roadmap whether you want it or not. Chrome users will get it by default in the next 12 months. Read the IETF draft (`draft-ietf-httpbis-device-bound-cookies`), not the marketing page. Decide now whether you'll implement it server-side, ignore it and let Chrome handle the binding transparently, or wait for a multi-vendor implementation. The middle option is fine for most apps; the third is only fine if your threat model genuinely doesn't include cookie theft.
Stop treating Firefox as a free fallback. The honest read of the next eighteen months is that the Firefox population on any Google property will trend toward zero, by user attrition if not by force. If you maintain a web app and you've been quietly relying on "well, Firefox users can still use it," that calculus is about to change. Either commit to multi-browser testing as a first-class concern with budget and CI minutes, or be explicit with users that you're Chromium-only.
The interstitial is a trial balloon. Google will measure how loud the backlash gets, how many Workspace admins file tickets, and whether the press coverage shifts the DOJ remedy conversation. If the answer to all three is "not much," the block ships in Q3 or Q4 2026, conveniently after the search-default renewal terms are locked in. If the backlash is significant, the interstitial quietly disappears and reappears six months later in a softer form. The thing to watch isn't whether Firefox gets blocked — it's the DOJ filings in the Google Search remedy case, which will set the actual rules for whether Mozilla still has a business in 2027.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.