Given that the design of this feature doesn't require a specific backend implementation, going to approve it.
LGTM On Thursday, March 13, 2025 at 3:50:18 PM UTC-7 Daniel Rubery wrote: > 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/b1c96d41-314b-4def-8eef-c1b2656b0b11n%40chromium.org.
