Early Design Review: Allowing First-Party SameSite=None Cookies in Sandboxed Contexts

[aamuley]

こんにちは TAG-さん!

I'm requesting a TAG review for allowing SameSite=None cookies in first-party sandboxed contexts in browsers with third-party cookie (3PC) restrictions.

In order to prevent malicious attacks from untrusted content, servers can include a Content-Security-Policy: sandbox HTTP header or sandbox attribute on an embedded iframe. This policy results in the browser treating the frame as an opaque origin, and requests originating from it cannot include SameSite=Strict/Lax cookies. However, for the purposes of 3PC blocking, the opaque origin also causes the browser to treat same-site subresource embeds on the top-level as cross-site, so SameSite=None cookies are also excluded from requests.

To preserve legacy behavior and mitigate future breakage due to 3PC blocking, we would like to introduce a method for servers to indicate to the browser that they wish a sandboxed context to include first-party SameSite=None cookies in requests using a Content-Security-Policy or HTML iframe sandboxing value: 'allow-same-site-none-cookies'.

• Explainer (minimally containing user needs and example code):
  https://github.com/explainers-by-googlers/csp-sandbox-allow-same-site-none-cookies/blob/main/README.md
• User research: N/A
• Security and Privacy self-review: https://github.com/explainers-by-googlers/csp-sandbox-allow-same-site-none-cookies/blob/main/tag_self_review.md
• GitHub repo: https://github.com/explainers-by-googlers/csp-sandbox-allow-same-site-none-cookies
• Primary contacts (and their relationship to the specification):
  • Anusha Muley (@aamuley, Google Chrome, author)
  • Dylan Cutler (@DCtheTall, Google Chrome, author)
• Organization/project driving the design: Google Chrome
• External status/issue trackers for this feature (publicly visible, e.g. Chrome Status): https://chromestatus.com/feature/5090336588955648

Further details:

• I have reviewed the TAG's Web Platform Design Principles
• The group where the incubation/design work on this is being done (or is intended to be done in the future):
  Web Application Security WG
• The group where standardization of this work is intended to be done ("unknown" if not known): unknown
• Existing major pieces of multi-implementer review or discussion of this design:
  • Initial Proposal Issue: Add new CSP sandbox directive to allow SameSite=None cookies on top-level frames w3c/webappsec-csp#664
  • TPAC discussion: https://pad.w3.org/p/WebAppSec_2024-09-26#L505
• Major unresolved issues with or opposition to this design: None so far
• This work is being funded by: Google

[jyasskin]

Thanks for sending this to us. We think the use case looks reasonable, but we'd like to make sure that the relevant working groups get a chance to check that the behavior is right and that this doesn't add too much complexity to spec and other-engine infrastructure. In particular, it looks like it might be tricky to save the site so it's reliably only used for including these particular cookies in requests. Please drive w3c/webappsec-csp#664 to a conclusion, and work on a PR for the appropriate sections of HTML.

We are reminded again that cookies are now at the point that you need a doctorate in that domain to make any sense of them. The combination with the iframe sandbox attribute really takes it to the next level in terms of web developer hostility. That's not your fault, but we think that this area of the platform is well overdue for a serious rethink.