Thanks for the context, Sam. I'm concerned that the Explainer doesn't outline any considered alternatives. Where can I read up on why this is the best possible design in this space? Has a summary of OT feedback been published anywhere?
Best, Alex On Monday, February 9, 2026 at 10:47:48 AM UTC-8 Rick Byers wrote: > Thanks Arnar and Sam for the additional detail and supportive color. It > makes sense to me. > > IMHO we are way past due for making auth more secure on the web. I've > found this W3C preso from Entersekt > <https://drive.google.com/file/d/1qxiGuKfwl8URcxAcG4ajm_3zH5xm9PBv/view> to > be compelling, they say (slide 6) that banking is actively moving away from > the web due to the lack of security relative to native platforms (which is > obviously about more than just cookie theft, but it's a start). Yesterday > my brokerage, qtrade.ca, sent me a security warning about the hostility > of the web including the guidance "Whenever possible, sign in using our > mobile app". Anything we have reason to believe can help with sites > adopting more secure authentication is urgent in my view. Perhaps the best > thing we can do to help is try to build partnerships with some of these > more "regular" web apps and understand what we can do to help them gain the > security benefits of DBSC? I hope we will be able to publish some case > studies about what we learn in the Google context. > > Rick > > On Mon, Feb 9, 2026 at 1:26 PM Arnar Birgisson <[email protected]> wrote: > >> I think it's worth noting that the design choice for browser-initiated >> refreshes, which was TAG's biggest gripe, is not there only because of >> partner feedback. >> >> The two reasons were: >> a) At scale, where one auth system serves a large set of apps with >> different ownership, it's not feasible to do the kind of migration that >> switching to server-initiated refreshes would require. >> >> b) For smaller and "regular" webapps that build on 3rd party frameworks, >> there isn't a way for frameworks to ship and migrate from cookie-based auth >> to server-initiated refreshes without a lot of work from the app developer. >> That problem is compounded when apps are built on a stack of frameworks. >> >> Reason a) is obviously motivated by Google, but it is well supported by >> partner feedback. But by its nature, we have no partners looking at DBSC >> from the PoV of b). Besides TAG, very few people outside Google have >> thought enough about DBSC to understand the challenges of b), and that's >> the discussion that was most challenging with TAG. It's at least my opinion >> that client-initiated refreshes are the *less* risky option for future >> adaptability. >> >> cheers, >> Arnar >> > >> On Mon, Feb 9, 2026 at 10:08 AM Sam Goto <[email protected]> wrote: >> >>> I haven't been directly involved with DBSC personally, asides from >>> rooting from the side lines, so I just wanted to stop by to show some >>> neutral support for DBSC on this thread and to try to add some comfort to >>> the architectural design risks that are being taken. >>> >>> DBSC has a concrete chance of helping with one of the biggest problems >>> in authentication on the Web, cookie theft. The fact that the team involved >>> has found a mechanism that can concretely help users at scale by satisfying >>> hard requirements from real-world developers seems to me like a checkpoint >>> worth capturing. >>> >>> I empathize with the tension described in the TAG review, but that >>> didn't seem to me like an irreversible technical choice, whereas closing >>> the window of opportunity to capture developer appetite and build a >>> community around it does. I'm pretty confident that DBSC, if it succeeds, >>> will go over a massive amount of API iterations and might look very >>> different from what's being proposed here, and that's OK. What I think is >>> most important is that with this baseline, the team can create a baseline >>> and gather real-world deployment and implementation experience to shape how >>> things plays along. >>> >>> I hope this helps, >>> >>> Sam >>> >>> >>> >>> >>> >>> >>> >>> On Monday, February 9, 2026 at 9:41:50 AM UTC-8 Mike Taylor wrote: >>> >>>> >>>> On 2/9/26 11:29 a.m., Rick Byers wrote: >>>> >>>> Ok LGTM1 to ship subject to working to get the WPTs passing on wpt.fyi >>>> one way or another. >>>> >>>> On Fri, Feb 6, 2026 at 5:16 PM Daniel Rubery <[email protected]> >>>> wrote: >>>> >>>>> > Thanks! Have a wpt.fyi URL? >>>>> >>>>> Here's our tests: >>>>> https://wpt.fyi/results/device-bound-session-credentials?label=experimental&label=master&aligned. >>>>> >>>>> It seems there's something wrong with the harness there, so we'll look >>>>> into >>>>> that. (My guess is that it's a result of DBSC being Finch-controlled and >>>>> using a VirtualTestSuite, which would improve the moment we ship) >>>>> >>>> >>>> Ah yes, generally we expect new web platform features to be >>>> status=experimental RuntimeEnabledFeatures >>>> <https://chromium.googlesource.com/chromium/src/+/main/third_party/blink/renderer/platform/RuntimeEnabledFeatures.md>, >>>> >>>> and that ensures they're enabled by default in most of our web platform >>>> tests (virtual/stable turns them off), and also enabled for web developers >>>> who are testing with --enable-experimental-web-platform-features. It's not >>>> a strict requirement but you might see if you can easily wire it up to >>>> enable in that case in addition to the finch knob. But as long as you are >>>> following finch best practices of enabling by default in code before >>>> pushing finch to 100% then IMHO it's not a big deal. >>>> >>>> I see >>>> https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/platform/runtime_enabled_features.json5;l=1908-1914?q=runtime_enabled_features.json >>>> >>>> is already set to "experimental" - but I'm not sure if the "origin_trial" >>>> keys prevent this from running on wpt.fyi w/o an OT token... >>>> >>>> >>>> > Please correct this to unsatisfied. >>>>> >>>>> > I read the TAG feedback and interpret it as preferring a different >>>>> architecture than what our customers have told us they prefer. Does that >>>>> seem right? Or is there another reason why we disagree on the suggestion >>>>> to >>>>> prefer a lower-level design? >>>>> >>>> >>>> Jeffrey: >>>> >>>>> Yep. The TAG's review is effectively a prediction that the way the >>>>> architecture is tailored to our current partners makes it easier for them >>>>> to adopt, at the cost of making the system harder to adapt to future >>>>> needs. >>>> >>>> >>>> Daniel: >>>> >>>>> Corrected to "Issues open" (I don't see an Unsatisfied option). Your >>>>> understanding is correct. We believe that the higher-level design makes >>>>> it >>>>> easier to deploy and more extensible for the future. Feedback from our >>>>> Origin Trials certainly supports the ease of deployment. >>>>> >>>> >>>> Thanks, makes sense to me. This is such a common tension in web >>>> platform design. FWIW I personally consider being too primitive-focused in >>>> the past to be my biggest technical career mistake >>>> <https://docs.google.com/presentation/d/19bz4CDrpOtxaqFe1tcrX1O3aBH40LU_i6hLtr-dfBDc/edit?slide=id.g34981a5734f_0_24#slide=id.g34981a5734f_0_24>. >>>> >>>> I think it's easier to recover from being too high-level (as we've done >>>> with, say, Wasm, Service Worker and CSS custom paint) than from being too >>>> low-level (as we've struggled to do with cookies and iframes). So while I >>>> respect TAG's expertise, I'm not going to lose any sleep over shipping >>>> despite their concern here. Building a self-sustaining flame >>>> <https://medium.com/@komorama/the-self-sustaining-flame-84326d2e1645> >>>> of adoption and leaning into the feedback from the partners who are >>>> motivated to iterate with us is our best overall defense. >>>> >>>> On Fri, Feb 6, 2026 at 2:03 PM Rick Byers <[email protected]> wrote: >>>>> >>>>>> Very happy to see this shipping! Just a couple questions. >>>>>> >>>>>> On Fri, Feb 6, 2026 at 4:56 PM Daniel Rubery <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> One correction here: our web platform tests are now complete. >>>>>>> >>>>>> >>>>>> Thanks! Have a wpt.fyi URL? >>>>>> >>>>>> On Friday, February 6, 2026 at 1:31:57 PM UTC-8 Chromestatus wrote: >>>>>>> >>>>>>>> *Contact emails* >>>>>>>> [email protected], [email protected], [email protected] >>>>>>>> >>>>>>>> *Explainer* >>>>>>>> https://github.com/w3c/webappsec-dbsc/blob/main/README.md >>>>>>>> >>>>>>>> *Specification* >>>>>>>> https://w3c.github.io/webappsec-dbsc >>>>>>>> >>>>>>>> *Summary* >>>>>>>> To enhance user security and combat session theft, Chrome is >>>>>>>> introducing [Device Bound Session Credentials (DBSC)]( >>>>>>>> https://developer.chrome.com/docs/web-platform/device-bound-session-credentials). >>>>>>>> >>>>>>>> This feature allows websites to bind a user's session to their >>>>>>>> specific >>>>>>>> device, making it significantly harder for stolen session cookies to >>>>>>>> be >>>>>>>> used on other machines. >>>>>>>> >>>>>>>> *Blink component* >>>>>>>> Blink >>>>>>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%22> >>>>>>>> >>>>>>>> *Web Feature ID* >>>>>>>> Missing feature >>>>>>>> >>>>>>>> *Motivation* >>>>>>>> Reduce session theft by offering an alternative to long-lived >>>>>>>> cookie bearer tokens, that allows session authentication that is bound >>>>>>>> to >>>>>>>> the user's device. This makes the web safer for users in that it is >>>>>>>> less >>>>>>>> likely their identity is abused, since malware is forced to act >>>>>>>> locally and >>>>>>>> thus becomes easier to detect and mitigate. At the same time the goal >>>>>>>> is to >>>>>>>> disrupt the cookie theft ecosystem and force it to adapt to new >>>>>>>> protections. >>>>>>>> >>>>>>>> *Initial public proposal* >>>>>>>> https://github.com/WICG/proposals/issues/106 >>>>>>>> >>>>>>>> *TAG review* >>>>>>>> https://github.com/w3ctag/design-reviews/issues/1052 >>>>>>>> >>>>>>>> *TAG review status* >>>>>>>> Pending >>>>>>>> >>>>>>> >>>>>> Please correct this to unsatisfied. >>>>>> >>>>>> I read the TAG feedback and interpret it as preferring a different >>>>>> architecture than what our customers have told us they prefer. Does that >>>>>> seem right? Or is there another reason why we disagree on the suggestion >>>>>> to >>>>>> prefer a lower-level design? >>>>>> >>>>>> >>>>>>>> *Origin Trial Name* >>>>>>>> Device Bound Session Credentials >>>>>>>> >>>>>>>> *Chromium Trial Name* >>>>>>>> DeviceBoundSessionCredentials >>>>>>>> >>>>>>>> *Origin Trial documentation link* >>>>>>>> https://github.com/w3c/webappsec-dbsc/blob/main/README.md >>>>>>>> >>>>>>>> *WebFeature UseCounter name* >>>>>>>> kDeviceBoundSessionRegistered >>>>>>>> >>>>>>>> *Origin Trial Name* >>>>>>>> Device Bound Session Credentials 2 >>>>>>>> >>>>>>>> *Chromium Trial Name* >>>>>>>> DeviceBoundSessionCredentials2 >>>>>>>> >>>>>>>> *Origin Trial documentation link* >>>>>>>> https://github.com/w3c/webappsec-dbsc/blob/main/README.md >>>>>>>> >>>>>>>> *WebFeature UseCounter name* >>>>>>>> kDeviceBoundSessionRequestInScope >>>>>>>> >>>>>>>> *Risks* >>>>>>>> >>>>>>>> >>>>>>>> *Interoperability and Compatibility* >>>>>>>> *No information provided* >>>>>>>> >>>>>>>> *Gecko*: No signal ( >>>>>>>> https://github.com/mozilla/standards-positions/issues/912) >>>>>>>> >>>>>>>> *WebKit*: No signal ( >>>>>>>> https://github.com/WebKit/standards-positions/issues/281) >>>>>>>> >>>>>>>> *Web developers*: Positive ( >>>>>>>> https://github.com/mozilla/standards-positions/issues/912#issuecomment-2204012985 >>>>>>>> ) >>>>>>>> >>>>>>>> *Other signals*: >>>>>>>> >>>>>>>> *WebView application risks* >>>>>>>> >>>>>>>> Does this intent deprecate or change behavior of existing APIs, >>>>>>>> such that it has potentially high risk for Android WebView-based >>>>>>>> applications? >>>>>>>> *No information provided* >>>>>>>> >>>>>>>> >>>>>>>> *Debuggability* >>>>>>>> *No information provided* >>>>>>>> >>>>>>>> *Will this feature be supported on all six Blink platforms >>>>>>>> (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?* >>>>>>>> No >>>>>>>> The initial support for TPMs is Windows-only. This feature will >>>>>>>> eventually support all platforms, as we integrate with the OS-specific >>>>>>>> key >>>>>>>> generation/usage mechanisms. >>>>>>>> >>>>>>>> *Is this feature fully tested by web-platform-tests >>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* >>>>>>>> No >>>>>>>> >>>>>>>> >>>>>>>> *Flag name on about://flags* >>>>>>>> enable-standard-device-bound-session-credentials, >>>>>>>> enable-standard-device-bound-session-persistence, >>>>>>>> enable-standard-device-bound-session-credentials-refresh quota >>>>>>>> >>>>>>>> *Finch feature name* >>>>>>>> DeviceBoundSessions >>>>>>>> >>>>>>>> *Rollout plan* >>>>>>>> Will ship enabled for all users >>>>>>>> >>>>>>>> *Requires code in //chrome?* >>>>>>>> False >>>>>>>> >>>>>>>> *Tracking bug* >>>>>>>> https://crbug.com/355059881 >>>>>>>> >>>>>>>> *Estimated milestones* >>>>>>>> Shipping on desktop 145 >>>>>>>> Origin trial desktop first 135 >>>>>>>> Origin trial desktop last 139 >>>>>>>> Origin trial desktop first 142 >>>>>>>> Origin trial desktop last 144 >>>>>>>> DevTrial on desktop 135 >>>>>>>> >>>>>>>> *Anticipated spec changes* >>>>>>>> >>>>>>>> Open questions about a feature may be a source of future web compat >>>>>>>> or interop issues. Please list open issues (e.g. links to known github >>>>>>>> issues in the project for the feature specification) whose resolution >>>>>>>> may >>>>>>>> introduce web compat/interop risk (e.g., changing to naming or >>>>>>>> structure of >>>>>>>> the API in a non-backward-compatible way). >>>>>>>> *No information provided* >>>>>>>> >>>>>>>> *Link to entry on the Chrome Platform Status* >>>>>>>> >>>>>>>> https://chromestatus.com/feature/5140168270413824?gate=5110303886409728 >>>>>>>> >>>>>>>> *Links to previous Intent discussions* >>>>>>>> Intent to Prototype: >>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/60bae138-43ee-4525-a549-461f241e9ae5n%40chromium.org >>>>>>>> Intent to Experiment: >>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/515ba278-c5fc-4ee0-8e88-21f34851778an%40chromium.org >>>>>>>> Intent to Experiment: >>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXLL9AD6SSyUXpDcSB9m8y9nVnnNzAMTK6qmui%3DzKnM8G_5A%40mail.gmail.com >>>>>>>> >>>>>>>> >>>>>>>> This intent message was generated by Chrome Platform Status >>>>>>>> <https://chromestatus.com>. >>>>>>>> >>>>>>> -- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "blink-dev" group. >>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>> send an email to [email protected]. >>>>>>> To view this discussion visit >>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2e43fba2-6da6-4cce-817d-9dd998ccb50cn%40chromium.org >>>>>>> >>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2e43fba2-6da6-4cce-817d-9dd998ccb50cn%40chromium.org?utm_medium=email&utm_source=footer> >>>>>>> . >>>>>>> >>>>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "blink-dev" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> >>>> To view this discussion visit >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9degdS%2BRRgWOsr99ZfZLZFObkN95GonAM7C%2BU9ZA9MDQ%40mail.gmail.com >>>> >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9degdS%2BRRgWOsr99ZfZLZFObkN95GonAM7C%2BU9ZA9MDQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>>> -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3666c93a-2a8f-4190-a57b-9f11c2242aabn%40chromium.org.
