Cross-site cookies standardization, part 2

[annevk]

I've done some triage to figure out if there are additional items that warrant discussion. Building on #16 and what did not get addressed in yesterday's meeting, that gives:

4. Interaction of cross-site cookies and SameSite=None.
5. Adding more contextual information to requests: Sec-Fetch-Ancestors? w3c/webappsec-fetch-metadata#56 & Fetch-Metadata to indicate when the browser is in a partitioned context w3c/webappsec-fetch-metadata#80 (see User agents should indicate to servers whether a request is cross-site CHIPS#2 for context).
6. Ephemeral partitioned third-party storage (including cookies) by Brave: Top-Frame lifetime, partitioned storage for embedded frames proposals#18.

(Obviously open for further additions, but I figured I'd file this directly to keep track of it.)

Edit: I moved what is now 6 to the end as it's somewhat unrelated to cookies.

[johannhof]

I think all these are super important to figure out and discuss, I just wonder if our regular meeting format can allow folks to properly deep dive into those (maybe with some preparatory coordination beforehand).

[annevk]

I figured I'd at least have some slides next time (help appreciated) to set context and obviate the need for some of the questions that we ended up with yesterday, but I'd also be happy to discuss these with a smaller group.

[annevk]

Meeting slides: https://docs.google.com/presentation/d/1OBR1mfp_EEBOQJr26tQd6LUmU8CmZOClQqVBMjSabd4/edit.

Meeting minutes: https://github.com/privacycg/meetings/blob/main/2022/telcons/05-12-minutes.md.

Follow-up issue on A1 -> B -> A2 (and SameSite=None): privacycg/storage-partitioning#31.

Related issue on keying in CHIPS: privacycg/CHIPS#40.

I think this can be closed. @johannhof @krgovind can you double check?

[johannhof]

We can probably close this, but I think it might be worth tracking the larger discussion around SameSite=None and what would happen to it in a world without third party cookies (what about POST requests, do we still need "lax"?). Do you think storage-partitioning is the right place for that?

[annevk]

Yeah, let's track cookie issues that don't have a good home there for now.

I also realized we don't have a good issue there for exposing partitionedness so I'm filing that as well.

[johannhof]

We met at TPAC to continue this discussion (slides, I don't think we had a scribe which is entirely my fault), here's a summary of what we ended up discussing and agreeing on:

Cookie Layering:

• We want to move forward with our plans for Cookie Layering. As we have general alignment between browser vendors on this idea we think that we should continue the discussion in the IETF HTTP WG.
• We discussed some details of how layering would work and largely agreed on the rough proposed structure, with a few caveats. Specifically, the cookie RFC / cookie store should hold the authority over decisions to set or return cookies given the information passed in by its consumers (e.g. SameSite / 3P context information). The keying of cookie entries based on rules such as partitioning should be done by HTML/Fetch based on a custom key that the store will receive.

Cross-site cookies vs. SameSite=None

• There was no opposition to allowing SameSite=None cookies to be written or read in an A > B > A setting. Chrome will likely adopt this behavior when blocking 3P cookies.
• Similarly, there were no concerns about allowing SameSite=None cookies to be sent in Scenario 2
• @johnwilander noted that Safari had some custom blocking rules for cookies in cross-site navigations, though I'm not sure we were able to capture them accurately, so a written version would be nice. I think there is a general desire to better understand Safari cookie blocking rules (e.g. on navigation) and how they relate to SameSite. We later discussed that @annevk might be able to document this for us.

Thank you everyone for a great productive chat!

[johannhof]

cc @krgovind

[johannhof]

@krgovind made me aware of two small additions to the above:

• @annevk suggested that there are still security ("confused deputy") concerns for Scenario 1 and 2; so we need to discuss with WebAppSec folks and make sure they're ok with that.
• For Scenario 4, John mentioned that Safari has a similar carveout for extensions