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).

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.

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?

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?

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.

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!

cc @krgovind

@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

I think when SameSite=None is used those concerns do not quite apply. At the very least, the website ought to know that in such cases it can be confused about authority and should use other tools to check for the correct authority. (At that point in the meeting we might have been talking past each other a bit, my apologies for that.)

Embracing SameSite=None cookies as a unique special case that can enter other partitions might be okay.

Ok, yeah, I actually agree with that, thanks for following up!