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

Visit on Github.

Opened Oct 16, 2024

こんにちは 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'.

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:
  • Major unresolved issues with or opposition to this design: None so far
  • This work is being funded by: Google

Discussions

Log in to see TAG-private discussions.

Discussed Dec 16, 2024 (See Github)

Jeffrey had forgotten that he thought about this in October:

SameSite=None remains the most confusing cookie property. The use case seems fine to me, but I'm torn between wanting the sandbox value to say something about the meaning of a frame with this value set, vs saying specifically what it does. Sandbox values have so far said just what the effect is, so it's probably right to continue that policy, as this proposal does. This also seems to require browsing contexts to track more data, since right now they just have an origin, which is set to opaque for most sandboxed frames, and this would require them to save a site and use it for only certain cookie requests. Tentative response:

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.

Martin: Isn't this a self-own on the part of the page, which sandboxed a frame that needs cookie access?

Jeffrey: Kinda. I don't fully understand the use case, and the iframe could always be allow-same-origin, but maybe you want to give it less access.

Martin: I really don't like this whole cookie setup. The argument seems reasonable, but it's all a death by 500 papercuts.

Jeffrey: Both sandbox and SameSite=None are confusing, so of course we need to combine them.

Martin: I think Jeffrey's draft comment is roughly the right thing to say.

Jeffrey: Maybe we should also say that this whole area is hard to understand and could use a rethink, but we haven't done that, and these proponents aren't really responsible to do it either.

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](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe#sandbox) 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.
Comment by @jyasskin Dec 18, 2024 (See Github)

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.