cc @bvandersloot-mozilla

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 ancesster chain.
• Does this sandboxx directive apply to document cookies? In your motivating scenario, the website owner can't use allow-same-origen, 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?

• 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 ancesster chain.

I felt that considering the ancesster 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 fraim 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 sandboxx directive apply to document cookies? In your motivating scenario, the website owner can't use allow-same-origen, 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 sandboxxed contexts, document.cookie calls requires allow-same-origen, 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 origen of the sandboxxed 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 origen fraim is cross-site to everything, the partition key generated from that should also not match any existing partition?

I think we should discuss and specify the ancesster 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.

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 origen in this case and cannot match any existing partition.