A1 -> B -> A2 nested documents and cookies (and SameSite=None)

[annevk]

Assume a document nesting scenario of A1 -> B -> A2 whereby A1 and A2 are same-origin with each other and cross-site with B. In the real world this sometimes materializes as a publisher embedding an ad distributor that then decides to display an ad from the publisher.

As discussed in #25 and elsewhere it's generally considered good practice for A2 to be severed from A1 to avoid confused deputy attacks, which is why browsers are considering adding the "has cross-origin ancestors" bit to the partitioning key.

Now unlike other state, cookies have the unique ability to indicate these confused deputy attacks are defended against through the usage of SameSite=None. As such, the argument has been made that sending unpartitioned cookies to A2 is okay, as long as they use SameSite=None.

This creates some weirdness in that from a theoretical perspective B and A2 should not really be any different in terms of their relationship with A1. As in, both of them are partitioned. However, given the existing use cases and the unique ability of cookies to indicate confused deputy attacks were considered upon creation (to be clear, I somewhat doubt web developers consider that in detail, they also just want things to work) it might be acceptable to privilege A2.

Alternatives:

• SameSite=None does not have special privileges that allow it to ignore the "has cross-origin ancestors" bit when setting the cookie. (This would be my personal preference as this kind of logic where we only look at part of the total key seems rather scary.)
• We introduce another attribute specifically for these "has cross-origin ancestors" bit scenarios. I don't think there's enough benefit to the churn this ends up necessitating. SameSite=None already indicates a disregard for security.

(We discussed this scenario as part of privacycg/meetings#19.)

[johannhof]

As mentioned in privacycg/meetings#19 (comment) we met about this at TPAC and there don't seem to be any concerns with continuing to send SameSite=None cookies in this scenario. Not sure if we want to continue tracking this issue until we're able to standardize the behavior or if we want to close it.

[johannhof]

See caveat mentioned in privacycg/meetings#19 (comment) which means we may still want to discuss this with WebAppSec or similar security folks.