Allowing SameSite=None Cookies in First-Party Sandboxed Contexts

[aamuley]

Request for Mozilla Position on an Emerging Web Specification

• Specification title: Allowing SameSite=None Cookies in First-Party Sandboxed Contexts
• Specification or proposal URL (if available): Allowing SameSite=None Cookies in First-Party Sandboxed Contexts whatwg/html#10915
• Explainer URL (if available): https://github.com/explainers-by-googlers/csp-sandbox-allow-same-site-none-cookies
• Proposal author(s) (@-mention GitHub accounts): @aamuley @DCtheTall
• Caniuse.com URL (optional):
• Bugzilla URL (optional):
• Mozillians who can provide input (optional):
• WebKit standards-position: Requested Allowing SameSite=None Cookies in First-Party Sandboxed Contexts WebKit/standards-positions#450

Other information

When third-party cookies (3PC) are blocked by Chrome and Firefox, contexts with the Content-Security-Policy: sandbox header or <iframe> sandbox attribute are no longer able to use SameSite=None cookies. The frame must include the allow-same-origin value to use cookies, which relaxes many security protections including the opaque origin.

We want to restore existing behavior and enable a frame to signal the browser to include SameSite=None cookies in first-party requests from sandboxed frames when 3PC restrictions are active with the allow-same-site-none-cookies value

[tomrittervg]

cc @bvandersloot-mozilla

[artines1]

Thanks for your request. I have a few questions about this proposal.

• You mentioned that the calculation is based on the document's URL. However, it's unclear whether or not the calculation needs to consider the ancestor chain.
• Does this sandbox directive apply to document cookies? In your motivating scenario, the website owner can't use allow-same-origin, so I suppose the document cookie is unavailable. Should this new directive preserve the same behavior, or will it apply further to document cookies?
• Couldn’t the website owner use CHIPS to keep accessing Same-Site=None cookies when 3PCs are blocked?

[aamuley]

• You mentioned that the calculation is based on the document's URL. However, it's unclear whether or not the calculation needs to consider the ancestor chain.

I felt that considering the ancestor chain could be more of an implementation detail so I chose to omit that (although that will likely be required for the Chromium implementation). If this value is set in a cross-site embed, allowing the embedded frame to access a SameSite=None cookie from its domain seems like it would allow a 3PC. I can add this to the specification if this detail is agreed upon, just wanted to keep it broad to start.

• Does this sandbox directive apply to document cookies? In your motivating scenario, the website owner can't use allow-same-origin, so I suppose the document cookie is unavailable. Should this new directive preserve the same behavior, or will it apply further to document cookies?

This directive will not apply to document cookies for the reasoning you mentioned. In sandboxed contexts, document.cookie calls requires allow-same-origin, which would make this directive a no-op.

• Couldn’t the website owner use CHIPS to keep accessing Same-Site=None cookies when 3PCs are blocked?

Since the origin of the sandboxed document is opaque, I dont quite understand how adding a partitioned attribute would change this behavior since the context would still be considered cross-site for 3PC blocking regardless of the partitioned attribute.

Not sure how CHIPS is implemented in Mozilla but I would additionally assume for the CHIPS part, if the SiteForCookies of an opaque origin frame is cross-site to everything, the partition key generated from that should also not match any existing partition?

[johannhof]

I think we should discuss and specify the ancestor chain details, @aamuley maybe we could file an issue for that on the explainer?

That's also my understanding of the partition key, but it would be great if we had tests for this.

[artines1]

CHIPS cookies are allowed in cross-site contexts when 3PC is blocked, so I thought the SameSite=None cookies were still allowed. But you are correct that the partitionKey will be opaque origin in this case and cannot match any existing partition.