Intent to Experiment: Device Bound Session Credentials

[Daniel Rubery]

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

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? 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.

[Morgaine (de la faye)]

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. 

[Daniel Rubery]

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

[Alex Russell]

Given that the design of this feature doesn't require a specific backend implementation, going to approve it.

LGTM