Expose partitioning in serialized cookies

[johannhof]

WebDriver has a representation of cookies that contains some of their most relevant concepts for test introspection. It's currently missing support for the "Partition Key" of a cookie when using CHIPS. Because the partition key is more than just a site, it's a site and an ancestor chain bit (or potentially no partition key at all), it's not clear what it should serialize to.

As a straw man suggestion just to get some input, I could imagine splitting it up into two attributes:

• cookie["partitionKeySite"], which is either a DOMString representing a site, or undefined.
• cookie["partitionKeyHasCrossSiteAncestors"], which is a boolean that represents whether or not the partition key has the ancestor chain bit (yes this is a really long name)

Any thoughts / suggestions @annevk @dcthetall @bvandersloot-mozilla?

[OrKoN]

Partitioning should be accounted for in the WebDriver BiDi spec https://w3c.github.io/webdriver-bidi/#module-storage

[annevk]

Did you consider partitionKey holding an object? Or is it normal that if something is an object you flatten that into differently-named top-level members?

[johannhof]

Did you consider partitionKey holding an object? Or is it normal that if something is an object you flatten that into differently-named top-level members?

Yeah... an object sounds like the obvious right choice here. I was looking at that list and just assumed it has to be flat.

[johannhof]

Partitioning should be accounted for in the WebDriver BiDi spec https://w3c.github.io/webdriver-bidi/#module-storage

So I asked this question internally at Google but it probably makes sense to repeat here, too: It seems a bit unfortunate to have two different interfaces for cookies, especially when they have diverging feature sets.

Does it make sense to deprecate all Cookie APIs in WebDriver Classic and just add new features to Bidi moving forward?

[johannhof]

Looking at the Bidi spec I also don't think it has the same idea of "partition" that we have here... It seems to simply separate different partitions based on origins that can access a cookie, and then allow the API to get any cookie within that "partition" based on matching attributes? Maybe I'm misreading it, but I don't see how this is the same as the CHIPS Cookie partitioning concept.

[annevk]

@burg and @gsnedders are best suited to answer whether to only enhance BiDi. Since this is not for Interop 2025 I suspect that would be okay.

[jgraham]

I think it's easier to add features in BiDi at this point; we can backport them if there's demand.

It seems very possible that the current cookie partitioning setup in the BiDi spec isn't correct; the state of the art here has been in flux and we were trying to understand what was needed to support different implementations existing site isolation behaviour, as well as future changes. Additional review and input from the people working on this would be much appreciated.

Re partitionKey; it already is an object. It could still have properties with values that are themselves objects, but I'm not sure I really understand what the concern is.

[johannhof]

I think it's easier to add features in BiDi at this point; we can backport them if there's demand.

So I get that about new features, for example, I think (non-cookie) storage features should probably live in BiDi. But it looks like there's still some basic support for Classic, which to me sounds like it should account for partitioned cookies in a basic way, e.g. including them in the list of gettable cookies (#1893) and exposing the partition key in the Cookie object.

It seems very possible that the current cookie partitioning setup in the BiDi spec isn't correct; the state of the art here has been in flux and we were trying to understand what was needed to support different implementations existing site isolation behaviour, as well as future changes. Additional review and input from the people working on this would be much appreciated.

Re partitionKey; it already is an object. It could still have properties with values that are themselves objects, but I'm not sure I really understand what the concern is.

Yeah, so, I'm trying to wrap my head around the architecture in the BiDi spec - it seems to mirror the way that Firefox Containers are implemented, which could maybe be used in some way to support partitioned cookies, but is definitely a bit heavy-handed for that purpose and makes me appreciate the simple interface that we have in Classic.

For Storage partitioning, the BiDi approach might work better - I haven't really thought about that too much :)

Honestly, having both interfaces supported at the same time seems useful.

[OrKoN]

@johannhof the spec allows extending the partitionKey with implementation-specific keys (e.g., hasCrossSiteAncestor). I have been starting to add the implementation for Chromium here https://github.com/GoogleChromeLabs/chromium-bidi/pull/2437 but have not finished it. If CHIPS gets cross-browser support, we should integrate it better into the spec and as jgraham said there could be issues with the spec as well (e.g., I filed https://github.com/w3c/webdriver-bidi/issues/820) since we tried to make it cross-browser while in practice the cookie partitioning behaves somewhat different across browsers.

[gsnedders]

How does this differ to #1893? Cookie serialisation is only used by Get All Cookies and Get Named Cookie, and thus this seems like these are duplicates? Or is the intention that #1893 considers the question of "what cookies do 'Get All Cookies' and 'Get Named Cookie' return", and this (#1894) considers the question of "should we expose the partition key"?

@burg and @gsnedders are best suited to answer whether to only enhance BiDi. Since this is not for Interop 2025 I suspect that would be okay.

We need to define the WebDriver Classic behaviour for cookies, regardless of what we do in BiDi.

Yeah, so, I'm trying to wrap my head around the architecture in the BiDi spec - it seems to mirror the way that Firefox Containers are implemented, which could maybe be used in some way to support partitioned cookies, but is definitely a bit heavy-handed for that purpose and makes me appreciate the simple interface that we have in Classic.

The intention was to work with all existing browser partitioning models, c.f. https://github.com/w3c/webdriver-bidi/issues/287. It's certainly plausible that we didn't do a good enough job at understanding exactly what different browsers do, or what exactly cookie stores store.

[johannhof]

@johannhof the spec allows extending the partitionKey with implementation-specific keys (e.g., hasCrossSiteAncestor). I have been starting to add the implementation for Chromium here GoogleChromeLabs/chromium-bidi#2437 but have not finished it. If CHIPS gets cross-browser support, we should integrate it better into the spec and as jgraham said there could be issues with the spec as well (e.g., I filed w3c/webdriver-bidi#820) since we tried to make it cross-browser while in practice the cookie partitioning behaves somewhat different across browsers.

Cool, thanks for picking that up. I should note that CHIPS is supported in Chrome and Safari today, with Firefox working through some bugs to re-enable it. We haven't fully standardized it yet but are working on that. The shipping behavior for CHIPS should be consistent with the spec for all browsers.

[johannhof]

How does this differ to #1893? Cookie serialisation is only used by Get All Cookies and Get Named Cookie, and thus this seems like these are duplicates? Or is the intention that #1893 considers the question of "what cookies do 'Get All Cookies' and 'Get Named Cookie' return", and this (#1894) considers the question of "should we expose the partition key"?

Yeah, it's the latter. I think we should both return partitioned cookies in those methods and also expose the partition key on WebDriver Classic Cookies objects.

@burg and @gsnedders are best suited to answer whether to only enhance BiDi. Since this is not for Interop 2025 I suspect that would be okay.

We need to define the WebDriver Classic behaviour for cookies, regardless of what we do in BiDi.

Yeah, I agree we should support partitioned cookies in Classic, it seems like a baseline cookie functionality to me.

Yeah, so, I'm trying to wrap my head around the architecture in the BiDi spec - it seems to mirror the way that Firefox Containers are implemented, which could maybe be used in some way to support partitioned cookies, but is definitely a bit heavy-handed for that purpose and makes me appreciate the simple interface that we have in Classic.

The intention was to work with all existing browser partitioning models, c.f. w3c/webdriver-bidi#287. It's certainly plausible that we didn't do a good enough job at understanding exactly what different browsers do, or what exactly cookie stores store.

Yeah, reading through the discussions it makes sense how you arrived there, and as noted above it doesn't seem incompatible, just a bit more complicated, which is probably fine, especially if Classic has a simpler API.