Hello, Device Bound Session Credentials can only interface between the site and the primitives given by the operating system. Chrome’s implementation only supports DBSC for devices with TPMs on Windows. Given that a meaningful proportion of Windows devices don’t have TPMs today, sites are not likely to lock out users without Windows TPMs. I do share your concerns about the potential ecosystem effects as our platform support rises though.
It's not clear to me if your email suggests that restricting to specific issuers is a dangerous future direction or a worry about the current feature. Device Bound Session Credentials as designed today does not support any kind of TPM attestation on behalf of sites. Sites are not able to determine details about how the user agent stores the key, so your concerns about restricting to specific issuers cannot happen. That only leaves some risk around segmenting the web for users without TPMs. Given the limits on usage in Origin Trials, I think that risk is very low while still experimenting. We should definitely re-evaluate that risk before shipping. Does that address your concerns? Thanks, Dan Rubery On Tuesday, March 11, 2025 at 6:27:25 PM UTC-7 Morgaine (de la faye) wrote: > Hello. I'm writing in to express concerns I have related to this > experiment & proposal. > > Just yesterday, we saw YouTube add DRM to all video downloads, breaking > many user's flows for the yt-dlp user-agent. > At present, there's a workaround, which is to log in via an alternative > user agent and extract a so called PO Token, and to transfer that > credential to the yt-dlp user agent. > The specification here seems like it would directly obstruct the user from > transferring their agency like this; a bound cookie count not be transfered > and it's unclear if another user agent could find or use the TPM stored key. > Thus, it feels like the strong security guarantees here work directly > counter to user agency, in contravention of RFC 8890 The Internet is for > End Users. > https://github.com/yt-dlp/yt-dlp/issues/12563 > https://news.ycombinator.com/item?id=43321145 > https://github.com/yt-dlp/yt-dlp/wiki/PO-Token-Guide > > I don't see any way to resolve this conflict. Given that, I strongly > disfavor locking the user out of their agency like this, and wish to > protest the development of this specification as harmful and controlling > and manipulative of the web, against user interests. This should never ever > be allowed on the web. > > A more modest concern I also have. Currently only an abstract concern: > As written this specification seems like it at least does not prevent > other user agents from implementing this specification, doesn't seem to > require any specific JWT signing issuer authority system to work; it's just > the user's computer. (Considerably better than the abandoned much-maligned > & very constricting Web Environment Integrity proposal, which required > specific servers to vouch for the assertion). But I also worry about a > Jevon's Paradox situation, where the site's ability to rely on signed JWTs > is something that then becomes further controlled & used to filter the web, > force & restrict browser choice over time, by adding additional > restrictions on what JWTs are accepted during registration (ex, requiring > specific issuers, who can then be called to verify the JWT). The shape of > the JWT here seems like it opens up a lot of possibility for sites to pick > and choose what implementations they would or would not accept. That would > be actively harmful to the web. > > Given the timing of YouTube introducing universal DRM everywhere, this > feels like an incredibly ominous & scary shift to propose today. The > proposal of creating a contract between a TPM block and a website > explicitly locks the user out of agency that has been fundamental to the > web, and a condemn technology that would write a new contract for the web > that would exclude the user and user agency like that. > > On Wednesday, March 12, 2025 at 12:39:33 AM UTC Daniel Rubery wrote: > >> Contact emails dru...@chromium.org, the...@chromium.org, >> arn...@chromium.org > > >> >> Explainer https://github.com/w3c/webappsec-dbsc/blob/main/README.md >> >> Specification https://w3c.github.io/webappsec-dbsc >> >> Summary >> >> A way for websites to securely bind a session to a single device. It will >> let servers have a session be securely bound to a device. The browser will >> renew the session periodically as requested by the server, with proof of >> possession of a private key. >> >> >> Blink component Blink >> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%22> >> >> TAG review https://github.com/w3ctag/design-reviews/issues/1052 >> >> TAG review status Pending >> >> Origin Trial documentation link >> https://github.com/w3c/webappsec-dbsc/blob/main/README.md >> >> Risks >> When the experiment comes to an end, Chrome will no longer refresh any >> bound cookies. Sites should not enforce DBSC in a way that makes this >> difficult for users (e.g. triggering logouts). >> >> Interoperability and Compatibility >> *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 >> None, not currently shipping on WebView >> >> Goals for experimentation >> >> We want overall feedback on the header-based API. Note that error >> handling during session refresh is complex. It is not yet recommended that >> sites enforce strictly on the presence of device bound cookies (e.g. >> logging users out if they're missing). The error rate should be >> sufficiently low to understand if the API is unclear or overly complex. >> >> Debuggability >> >> Requests are visible in chrome://net-export, and more information is >> available as UMA histograms at chrome://histograms#Net. >> DeviceBoundSessions >> >> 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> >> ? Yes >> >> 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 >> >> Requires code in //chrome? False >> >> Estimated milestones >> Shipping on desktop >> 143 >> Origin trial desktop first >> 135 >> DevTrial on desktop >> 135 >> >> Link to entry on the Chrome Platform Status >> https://chromestatus.com/feature/5140168270413824?gate=5106323928121344 >> >> 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 >> >> >> 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 blink-dev+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/dabc7fd7-9b41-4770-9fd1-77a89360f520n%40chromium.org.
