Let embedees optionally request access to partitioned cookies and storage

[johnwilander]

Partitoned cookies have been discussed a lot in Privacy CG and some use cases seem to fit well with it. Safari shipped partitioned cookies 2017-2018, mostly saw compatibility issues, and replaced them with simple third-party cookie blocking instead. Since then, both Firefox and Edge have started blocking most/many third-party cookies and the need for partitioned cookies as a standardized behavior has emerged. Firefox has already implemented partitioned cookies and storage and WebKit+CFNetwork has a dormant implementation.

We should consider an optional parameter to document.requestStorageAccess() that allows for the embedee to signal all kinds of wishes, one of them that it is fine with partitioned cookies and storage. That could allow for prompt-free, undelayed cookie access. Perhaps even relax the user interaction requirement.

(Future uses of the optional parameter to document.requestStorageAccess() could be to allow the initiation of a login flow if unpartitioned storage access is granted but the user is not yet logged in to the embedee, something that several developers have asked for.)

[johnwilander]

For reference, see: #13

[annevk]

This would be for sites on some kind of tracking list that start out without any kind of storage? Because I think ideally this would be the default. (Even more ideal would be if we didn't need the lists long term as the partitioning would keep it all in check.)

[johnwilander]

This would be for sites on some kind of tracking list that start out without any kind of storage? Because I think ideally this would be the default. (Even more ideal would be if we didn't need the lists long term as the partitioning would keep it all in check.)

As mentioned in the issue and on Privacy CG calls, WebKit has seen compatibility issues for partitioned cookies. A solution for that is to make cross-site embedees explicitly opt in to partitioned cookies while blocking their cookies by default.

WebKit+CFNetwork has blocked pure cross-site cookies for 18 years with the exception of 2017-2018 when we tried partitioned cookies. For us, partitioned cookies by default only leads to more cookies.

The proposal here is to allow browsers to block cross-site cookies by default and give developers an explicit way of opting into them. The blocking can be based on whatever the browser wants, including lists.

[englehardt]

As mentioned in the issue and on Privacy CG calls, WebKit has seen compatibility issues for partitioned cookies.

How widespread were these issues? Can you reference any examples? I'm asking because we haven't seen such issues, but also haven't shipped our partitioning by default. I also wonder whether some of the differences in webcompat could be explained by Safari historically shipping a policy that blocked third-party cookie access by default and Firefox historically allowing it by default.

[englehardt]

We should consider an optional parameter to document.requestStorageAccess() that allows for the embedee to signal all kinds of wishes, one of them that it is fine with partitioned cookies and storage. That could allow for prompt-free, undelayed cookie access. Perhaps even relax the user interaction requirement.

I can only see this working if we remove the interaction requirement. I think it's important to ensure that a partitioned third-party iframe has the same capabilities and scope of storage as a first-party iframe on the same site. We don't want to further incentivize websites to embed content in the first-party context. So I think it would then be a question of what mode is more web compatible, i.e., storage access by default, or storage blocked by default w/ friction-less partitioned storage available with a single call to the Storage Access API.

We'd probably also have to update hasStorageAccess from true/false to "none/partitioned/full" or something like that. In Firefox hasStorageAccess currently returns false whenever "full" access is not granted -- both when storage access is blocked and when it is partitioned.

[krgovind]

Some of us on the Chrome team have also been thinking about opt-in partitioned cookies a.k.a "chips", by introducing a new cookie attribute. We just posted an explainer-style document here.

[johnwilander]

As mentioned in the issue and on Privacy CG calls, WebKit has seen compatibility issues for partitioned cookies.

How widespread were these issues?
I wouldn't say they were very widespread but it did impact one very popular site and it was very hard to get a good overall picture given how tricky it is to understand failures due to servers getting confused about cookies. We discussed with developers and our conclusion was that almost no one wanted partitioned cookies, they wanted access to their first-party cookies as third-party so we decided to focus on the Storage Access API and phase out partitioned cookies.

Can you reference any examples? I'm asking because we haven't seen such issues, but also haven't shipped our partitioning by default.

Sorry, those were not public conversations as I recall. This all happened more than three years ago and the sites may have changed due to ITP since then.

I also wonder whether some of the differences in webcompat could be explained by Safari historically shipping a policy that blocked third-party cookie access by default and Firefox historically allowing it by default.

This was the case in at least one instance. I would expect a lot more broken embeds in Firefox with third-party cookie blocking whereas in Safari, embedees have always known that they may not have access to cookies. I seen several instances where Safari has special code that allows cookies to be blocked.

[johnwilander]

We should consider an optional parameter to document.requestStorageAccess() that allows for the embedee to signal all kinds of wishes, one of them that it is fine with partitioned cookies and storage. That could allow for prompt-free, undelayed cookie access. Perhaps even relax the user interaction requirement.

I can only see this working if we remove the interaction requirement. I think it's important to ensure that a partitioned third-party iframe has the same capabilities and scope of storage as a first-party iframe on the same site. We don't want to further incentivize websites to embed content in the first-party context. So I think it would then be a question of what mode is more web compatible, i.e., storage access by default, or storage blocked by default w/ friction-less partitioned storage available with a single call to the Storage Access API.

I think relaxing the user interaction requirement for access to partitioned cookies is very reasonable.

We'd probably also have to update hasStorageAccess from true/false to "none/partitioned/full" or something like that. In Firefox hasStorageAccess currently returns false whenever "full" access is not granted -- both when storage access is blocked and when it is partitioned.

Agreed.

[erik-anderson]

If we don't have a user interaction requirement, it would be nice if this could work right out of the gate without waiting on script to run, requestStorageAccess to be called, and then waiting for the promise to resolve.

Additionally, given the historical observation about compat issues, having a requestStorageAccess call apply parititioning to all of the cookies on that domain seems potentially problematic if only portions of the site logic/its cookies are resilient to/compatible with cookie partitioning.

Having an explicit per-cookie marking as described in the "CHIPS" proposal that Kaustubha just shared looks like a better model.

[johnwilander]

If we don't have a user interaction requirement, it would be nice if this could work right out of the gate without waiting on script to run, requestStorageAccess to be called, and then waiting for the promise to resolve.

Then you're either proposing partitioning by default, which we are reluctant to try again for above stated reasons, or a response header. Anything else will be based on processing in the web content process which forces async opening of cookie access in the networking process and at that point it's much better to let developers have a distinct event at which cookies are available.

Additionally, given the historical observation about compat issues, having a requestStorageAccess call apply parititioning to all of the cookies on that domain seems potentially problematic if only portions of the site logic/its cookies are resilient to/compatible with cookie partitioning.

I don't think so. At that point, it's up to the developer whereas if we change default behavior it's much more on the browser to try not to break things that aren't supposed to be broken.

Having an explicit per-cookie marking as described in the "CHIPS" proposal that Kaustubha just shared looks like a better model.

I haven't had time to read the CHIPS proposal but the server is not guaranteed to know at request time whether it's embedded or not and thus will not know if the cookie will be partitioned or not. Maybe the Chrome folks cover that in their explainer.

[johannhof]

If we don't have a user interaction requirement, it would be nice if this could work right out of the gate without waiting on script to run, requestStorageAccess to be called, and then waiting for the promise to resolve.

Then you're either proposing partitioning by default, which we are reluctant to try again for above stated reasons.

It seems like outside of specific web compat issues there’s no actual disagreement here that partitioned cookies by default would be a superior API design. Aligning on that would be a major benefit for developers and in the long run reduce compat issues for all of us. Categorically discarding that idea (and instead adding even more complex fractured API surface) because of momentary compat issues feels shortsighted to me.

As Steve noted it would be great to be able to quantify the level of breakage in Safari and understand why Firefox is not affected. If it’s more or less one big site being affected maybe it’s possible to put them on a compat-list of sites that would not get partitioned cookies? If they’re not broken in Firefox (though maybe they are) then surely they can solve this for Safari in a reasonable time frame?

[johnwilander]

If we don't have a user interaction requirement, it would be nice if this could work right out of the gate without waiting on script to run, requestStorageAccess to be called, and then waiting for the promise to resolve.

Then you're either proposing partitioning by default, which we are reluctant to try again for above stated reasons.

It seems like outside of specific web compat issues there’s no actual disagreement here that partitioned cookies by default would be a superior API design. Aligning on that would be a major benefit for developers and in the long run reduce compat issues for all of us. Categorically discarding that idea (and instead adding even more complex fractured API surface) because of momentary compat issues feels shortsighted to me.

As Steve noted it would be great to be able to quantify the level of breakage in Safari and understand why Firefox is not affected. If it’s more or less one big site being affected maybe it’s possible to put them on a compat-list of sites that would not get partitioned cookies? If they’re not broken in Firefox (though maybe they are) then surely they can solve this for Safari in a reasonable time frame?

I don't think me digging up notes and bug reports from three years ago is that helpful, especially since Safari has been more strict on cookies all along, is already blocking all third party cookies, and sees different cookie behavior because of being at the front of cookie restrictions. Note that trackers typically think that Safari users have turned off all tracking prevention if they can set cookies as third parties. That "signal" will change if we turn on partitioned cookies again.

It could be that WebKit has to have a quirks list for sites that break if we allow partitioned cookies.

We'd like to hear from other browsers that ship partitioned cookies either by default or for a large portion of their user base before making a decision. We already tried and decided it wasn't worth it three years ago. No privacy benefit and developers didn't want them. So far, we're the only ones who have tried by default afaik.

[johnwilander]

I believe Microsoft's auth team has already started using document.cookie as a test vector to check their storage access status. They at least mentioned it in some Privacy CG Slack thread. That would break if we allow partitioned cookies by default.

[krgovind]

I haven't had time to read the CHIPS proposal but the server is not guaranteed to know at request time whether it's embedded or not and thus will not know if the cookie will be partitioned or not. Maybe the Chrome folks cover that in their explainer.

The explainer currently does not include a mechanism to indicate whether the cookie is partitioned or not, but it's an open issue that we're interested in solving. We've documented some ideas in privacycg/CHIPS/issues/2

[johnwilander]

I haven't had time to read the CHIPS proposal but the server is not guaranteed to know at request time whether it's embedded or not and thus will not know if the cookie will be partitioned or not. Maybe the Chrome folks cover that in their explainer.

The explainer currently does not include a mechanism to indicate whether the cookie is partitioned or not, but it's an open issue that we're interested in solving. We've documented some ideas in DCtheTall/CHIPS/issues/2

Revealing anything about a cookie's attributes would be a whole new thing and break a ≈25 year stretch of only letting sites read back a cookie's value. I would be against that since it removes the browser's ability to silently decide whether or not it wants to honor certain attributes. That in turn can lead to compatibility issues where developers only test in one or two browsers, falsely assume that the attribute will be treated in a certain way, and write JavaScript or server-side code that breaks when the attribute is not treated in that way.

What I was trying to say is that the server may want or need to know at response time whether it is in a situation where partitioned cookies come into play or not.

[krgovind]

Revealing anything about a cookie's attributes would be a whole new thing and break a ≈25 year stretch of only letting sites read back a cookie's value...

Indeed. I also used the phrase "indicate whether the cookie is partitioned or not" very loosely actually. At this point, the ideas we have in mind are just to add an indicator in the request header to denote when the request is coming from a partitioned context.

[jasonnutter]

I believe Microsoft's auth team has already started using document.cookie as a test vector to check their storage access status. They at least mentioned it in some Privacy CG Slack thread. That would break if we allow partitioned cookies by default.

We are considering that approach, yes. It is basically a way of verifying that we can read/write cookies once storage access has been granted (as the Safari cookie policy would still prevent cookies to be set in 3p context if they haven't been set in a 1p context, even if Storage Access has been granted).

[johnwilander]

It seems like outside of specific web compat issues there’s no actual disagreement here that partitioned cookies by default would be a superior API design. Aligning on that would be a major benefit for developers and in the long run reduce compat issues for all of us. Categorically discarding that idea (and instead adding even more complex fractured API surface) because of momentary compat issues feels shortsighted to me.

Thinking some more on this, I think one aspect is being missed here. Partitioned cookies are a compatibility measure. That was obvious to me when I interacted with developers about such cookies under the year where we had them. Partitioned cookies made several things "work" on the surface, tricking embedded content to think it had regular cookies, but breaking that content's actual purpose of using cookies which was often for auth. That's why we worked hard on the Storage Access API to provide a path to access to first-party cookies as a third party. That's what developers told us they wanted.

Browsers that have had no restrictions on cookies before will likely see more breakage than Safari if they block cross-site cookies. However, partitioning cookies will mostly serve as a way to blindside those pieces of embedded content and there will be many years of subtle failure instead of loud failure with blocked cross-site cookies.

For Safari, allowing partitioned cookies by default will confuse decades old code that has reliably been able to tell if it has access to its first party cookies by checking document.cookie in an iframe. Supporting partitioned cookies by default will break that and create compatibility issues for us. Thus, what looks like a great compatibility story for e.g. Firefox may not be as great for Safari. We are willing to work toward interop, of course. I just want to make it clear that partitioned cookies are a compatibility measure themselves and will create more problems for Safari, rather than less.

[johnwilander]

Another thing to note is that sites cannot clear their partitioned storage without the user browsing to the partition(sic) website (see privacycg/storage-partitioning#11). That was another concern developers brought up with us with partitioned cookies – they could log the user out server-side across sites but not client-side. Making partitioned cookies an opt-in thing means developers at least know what they are signing up for when they create them.

[johannhof]

I believe Microsoft's auth team has already started using document.cookie as a test vector to check their storage access status. They at least mentioned it in some Privacy CG Slack thread. That would break if we allow partitioned cookies by default.

We are considering that approach, yes. It is basically a way of verifying that we can read/write cookies once storage access has been granted (as the Safari cookie policy would still prevent cookies to be set in 3p context if they haven't been set in a 1p context, even if Storage Access has been granted).

I don't think that you should get storage access in this case, as in both the requestStorageAccess call as well has hasStorageAccess should fail there. Would you consider this a bug in WebKit @johnwilander? It feels like WebKit should account for this in the "implementation defined" steps in https://privacycg.github.io/storage-access/#determine-the-storage-access-policy.

(Besides that I can see your point in the last two comments, John.)

[johannhof]

Something else that comes to mind when we don't need an async mechanism is that we could use Document Policy to add a header that integrates with the SAA, such as Document-Policy: partitioned-storage=cookies. This would be an extension of SAA but it doesn't have to be for browsers that don't want to enable SAA.

This feels like it would cover the use cases @krgovind is after while avoiding the addition of another cookie attribute @johnwilander is concerned about.

[krgovind]

Thanks for the brainstorming, @johannhof !

Something else that comes to mind when we don't need an async mechanism is that we could use Document Policy to add a header that integrates with the SAA, such as Document-Policy: partitioned-storage=cookies. This would be an extension of SAA but it doesn't have to be for browsers that don't want to enable SAA.

I don't know very much about Document Policy, but from a cursory reading (and the name), it seems that it is scoped to documents and better suited to things like rendering options? A couple of notes:

• Cookies are scoped to domains, or hostnames (depending on how they're configured); so I wonder if it will cause developer confusion if the policy is mistakenly specified on some documents on the same domain/hostname, but not on others.
  • On browsers that support SAA, if the domain in question had been granted storage access to unpartitioned cookies, would this policy force the context to be partitioned?
• Cookies need to be sent on requests; while Document Policy is a response header. I think we may run into a chicken-and-egg problem?

This feels like it would cover the use cases @krgovind is after while avoiding the addition of another cookie attribute @johnwilander is concerned about.

What John said was:

Revealing anything about a cookie's attributes would be a whole new thing and break a ≈25 year stretch of only letting sites read back a cookie's value. I would be against that since it removes the browser's ability to silently decide whether or not it wants to honor certain attributes. That in turn can lead to compatibility issues where developers only test in one or two browsers, falsely assume that the attribute will be treated in a certain way, and write JavaScript or server-side code that breaks when the attribute is not treated in that way.

What I was trying to say is that the server may want or need to know at response time whether it is in a situation where partitioned cookies come into play or not.

My interpretation of John's concern is that we need to be able to indicate to developers whether their cookies are partitioned/unpartitioned, considering that not all browsers may support a new Partitioned attribute. I think we can address that with CHIPS as follows:

• Developers are required to specify a Partitioned attribute to opt-in the cookies that can be partitioned. The attribute also requires the __Host- prefix. I believe this means that - given a cookie name, and a hostname/origin - there is only one matching cookie.
• Browsers that support/understand the Partitioned attribute must also be required to send an additional header such as Sec-Fetch-Third-Party: 1 when the cookie is being sent on a request being made from a third-party/partitioned context. The presence of this request header will then allow the developer to infer that their cookie has indeed been partitioned.
• If the browser also supports SAA, and the domain has been granted storage access, there may be additional unpartitioned cookies that get sent on the request.

[johnwilander]

@johannhof, has Mozilla had a chance to discuss the idea of an optional parameter to document.requestStorageAccess() which opts into partitioned cookies and storage, potentially prompt-free and with no user interaction requirement?

[johannhof]

As I had mentioned in other places, we're generally open to adding more options to the requestStorageAccess call and can see prompt-free partitioned cookies as part of that.

One general concern I have is about the relationship with CHIPS. I think CHIPS is trying to solve some valid problems and could work alongside SAA, but it would be great if these mechanisms were at least interoperable and ideally somehow integrated from a developer standpoint.

[michael-oneill]

Even partitioned cookies, as do top-level first-party cookies, need user consent under ePrivacy.
It follows there must be a way for the top-level site to block partitioned cookies, and probably delete them if they are already there. I know Clear-Site-Data can do that (for the browsers that support it), but this is too non-specific or drastic..

The reason is that some storage use, e.g. some cookie names or localStorage items etc., is fine without prior consent if a particular usage has been declared as "strictly necessary to to fulfil a service requested by the user". Only the top-level site can know this, so it must be able to selectively block storage use. It can controlm the rendering of third-party content but it would be good to allow third-party content that either did not use storage or was guarenteed to request consent before using storage.

So if partitioned cookies can be used without a prompt, the top-level site needs to be able to stop that.

[krgovind]

One general concern I have is about the relationship with CHIPS. I think CHIPS is trying to solve some valid problems and could work alongside SAA, but it would be great if these mechanisms were at least interoperable and ideally somehow integrated from a developer standpoint.

@johannhof - We intend to propose CHIPS as PrivacyCG work item within the next couple of weeks, and would be happy to iterate on the proposal with this group's feedback.

[nwang-highspot]

@johnwilander If Safari does not support partitioned cookies, how third party application inner iframe get cookies without extra user interaction? The third party application only needs its own cookie for authentication, no need to get any info from first-party cookies.

[h3ku]

@johnwilander If Safari does not support partitioned cookies, how third party application inner iframe get cookies without extra user interaction? The third party application only needs its own cookie for authentication, no need to get any info from first-party cookies.

Has there been any further discussion on this, especially regarding the security implications?

I believe the absence of a method for iframes to request partitioned cookies without prompting will lead to decreased security for users.

When developers find that their application's authentication doesn't work due to being inside an iframe, they are likely to transfer the user token from cookies to IndexedDB/LocalStorage, which can be accessed without prompting in a partitioned manner. This is detrimental for users because there is no mechanism to prevent JavaScript from accessing this storage (unlike the HttpOnly attribute for cookies). This means that user tokens would be exposed in the event of a security issue like an XSS attack on the application, or other security concerns such as supply chain attacks with malicious dependencies.

I think having CHIPS support in Safari would be the way to go.