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/63e0647f-29fe-4494-9e93-21172533dc49n%40chromium.org.
