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
<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/43cf71d9-a621-4ca9-a690-56ea29715d9c%40chromium.org.
