Intent to Ship: Adding Cross-site Ancestor Chain Bit to CHIPS Partition Key

[Aaron Selya]

Contact emails

se...@chromium.org, dylan...@chromium.org, kaust...@chromium.org

Explainer

Keying of "CHIPS" cookies should align with other state: 

Specification

Add cross-site ancestor chain bit to spec: https://github.com/explainers-by-googlers/CHIPS-spec/pull/13

Summary

We are looking to align the partition key in CHIPS (Cookies Having Independent Partitioned State, aka partitioned cookies) with the existing implementation of StorageKey. 

The only sites that would experience different behavior, would be when a top-level site “A” embeds an iframe to a cross-site document on site “B”, and then the iframe B embeds an iframe that loads a document from site “A” (shorthand: A1->B->A2). Previously, partitioned cookies sent or received in the inner iframe A2 would be the same partitioned cookies sent or received in the outer frame A1. This is no longer true. 

This change is privacy neutral, but will have improved security characteristics, because it prevents cross-site iframes from embedding arbitrary endpoints of the top-level site with credentials, without first being granted permission to do so through the Storage Access API (SAA) or Cross-Origin Resource Sharing (CORS). 

The impact of this change is expected to be small as our metrics indicate that only 0.2% of CHIPS (partitioned cookies) set by the first party are currently being used in A1->B->A2 contexts. This constitutes 0.032% of all page loads (calculated using the usage of PartitionedCookie). For websites that do need access to the same cookies across A1 and A2 (in the A1->B->A2 configuration), we recommend using SameSite=None cookies *without* the Partitioned attribute, and invoking the Storage Access API (SAA) or using the Cross-Origin Resource Sharing (CORS). 

Blink component

Internals>Network>Cookies>PartitionedCookies

TAG review

Not requested, as this does not differ in any significant way from the original CHIPS design that was already reviewed by TAG.

TAG review status

N/A

Risks

Interoperability and Compatibility

The inclusion of a new element in the partition key will mean that partitioned cookies (CHIPS) created after the launch of this change will not be compatible with the partitioned cookies that already exist in users cookie jars. To address this, existing partitioned cookies will be migrated (without any need for developer action) to include the new cross-site ancestor chain bit value, which will be set with a value of true if the existing partition key does not match the host key (indicating a cross site ancestor is present) and false if the partition key does match the host key. This will ensure that most existing CHIPS have the same scope as they did prior to the change.  

Only 0.2% of partitioned cookies are utilized from within A1->B->A2 scenarios, but developers who need to be able to access cookies in A1->B->A2 scenarios will be able to use SAA, and CORS to gain access to those cookies, after transitioning to SameSite=None cookies without the Partitioned attribute.

To limit the impact of any significant breakages that may occur when this is deployed, the new feature will be gated by a flag allowing for it to be turned off easily. Additionally metrics are being gathered to proactively identify the sites that are going to be impacted by this change, so that we can do outreach to potentially impacted sites. As this feature gets deployed, we will monitor the bug and breakage reports to help identify issues and assist developers in transitioning to one of the other mechanisms that will allow their sites to work in an A1->B->A2 context.

As this does not differ in any significant way from the original partitioned cookies design that has been reviewed in the past, we are not seeking the various browsers to take official positions in their standards position repos.

There is support for the adoption of CHIPS from Firefox as well as support from them for adding the cross-site ancestor chain bit.

Webkit is still considering adopting CHIPS as we work through their concerns regarding partition size limitations. This will not be impacted by the addition of a cross-site ancestor chain bit. We updated the WebKit standards positions issue with a note regarding this change to the proposal.

Debuggability

DevTools will need to be updated to show the cross-site ancestor chain bit but otherwise it should be able to be debugged like other API calls.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

All platforms listed.

Is this feature fully tested by web-platform-tests?

We plan to land web-platform-tests shortly.

Flag name on chrome://flags

CookiePartitionKeyIncludesCrossSiteAncestorChainBit

Finch feature name

None

Requires code in //chrome?

False

Estimated milestones

Targeted shipping on desktop and Android in M125.

Anticipated spec changes

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5144832583663616

[Vladimir Levin]

On Mon, Mar 11, 2024 at 1:42 PM Aaron Selya <se...@chromium.org> wrote:

Contact emails

se...@chromium.org, dylan...@chromium.org, kaust...@chromium.org

Explainer

Keying of "CHIPS" cookies should align with other state: 

Specification

Add cross-site ancestor chain bit to spec: https://github.com/explainers-by-googlers/CHIPS-spec/pull/13

Summary

We are looking to align the partition key in CHIPS (Cookies Having Independent Partitioned State, aka partitioned cookies) with the existing implementation of StorageKey. 

The only sites that would experience different behavior, would be when a top-level site “A” embeds an iframe to a cross-site document on site “B”, and then the iframe B embeds an iframe that loads a document from site “A” (shorthand: A1->B->A2). Previously, partitioned cookies sent or received in the inner iframe A2 would be the same partitioned cookies sent or received in the outer frame A1. This is no longer true. 

This change is privacy neutral, but will have improved security characteristics, because it prevents cross-site iframes from embedding arbitrary endpoints of the top-level site with credentials, without first being granted permission to do so through the Storage Access API (SAA) or Cross-Origin Resource Sharing (CORS). 

The impact of this change is expected to be small as our metrics indicate that only 0.2% of CHIPS (partitioned cookies) set by the first party are currently being used in A1->B->A2 contexts. This constitutes 0.032% of all page loads (calculated using the usage of PartitionedCookie). For websites that do need access to the same cookies across A1 and A2 (in the A1->B->A2 configuration), we recommend using SameSite=None cookies *without* the Partitioned attribute, and invoking the Storage Access API (SAA) or using the Cross-Origin Resource Sharing (CORS). 

Blink component

Internals>Network>Cookies>PartitionedCookies

TAG review

Not requested, as this does not differ in any significant way from the original CHIPS design that was already reviewed by TAG.

TAG review status

N/A

Risks

Interoperability and Compatibility

The inclusion of a new element in the partition key will mean that partitioned cookies (CHIPS) created after the launch of this change will not be compatible with the partitioned cookies that already exist in users cookie jars. To address this, existing partitioned cookies will be migrated (without any need for developer action) to include the new cross-site ancestor chain bit value, which will be set with a value of true if the existing partition key does not match the host key (indicating a cross site ancestor is present) and false if the partition key does match the host key. This will ensure that most existing CHIPS have the same scope as they did prior to the change.  

Only 0.2% of partitioned cookies are utilized from within A1->B->A2 scenarios, but developers who need to be able to access cookies in A1->B->A2 scenarios will be able to use SAA, and CORS to gain access to those cookies, after transitioning to SameSite=None cookies without the Partitioned attribute.

To limit the impact of any significant breakages that may occur when this is deployed, the new feature will be gated by a flag allowing for it to be turned off easily. Additionally metrics are being gathered to proactively identify the sites that are going to be impacted by this change, so that we can do outreach to potentially impacted sites. As this feature gets deployed, we will monitor the bug and breakage reports to help identify issues and assist developers in transitioning to one of the other mechanisms that will allow their sites to work in an A1->B->A2 context.

The first mitigation listed here is to migrate existing partitioned cookies to include the new bit, and the second mitigation is to have a flag that can disable this feature. Would disabling the feature also include migrating the existing cookies back to exclude the new bit?

And somewhat related, but does the format of the cookie request developers make have to change too, or is this bit determination purely done within the browser?

 

As this does not differ in any significant way from the original partitioned cookies design that has been reviewed in the past, we are not seeking the various browsers to take official positions in their standards position repos.

There is support for the adoption of CHIPS from Firefox as well as support from them for adding the cross-site ancestor chain bit.

Webkit is still considering adopting CHIPS as we work through their concerns regarding partition size limitations. This will not be impacted by the addition of a cross-site ancestor chain bit. We updated the WebKit standards positions issue with a note regarding this change to the proposal.

Debuggability

DevTools will need to be updated to show the cross-site ancestor chain bit but otherwise it should be able to be debugged like other API calls.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

All platforms listed.

Is this feature fully tested by web-platform-tests?

We plan to land web-platform-tests shortly.

Flag name on chrome://flags

CookiePartitionKeyIncludesCrossSiteAncestorChainBit

Finch feature name

None

Could you please clarify if the flag you mentioned is a Finch flag or something else?

Requires code in //chrome?

False

Estimated milestones

Targeted shipping on desktop and Android in M125.

Anticipated spec changes

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5144832583663616

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPSgjYROtVMp%3DmfBLFdW5KiRYkcFx0NG3U%3DT_vtbm2b7UEzm0w%40mail.gmail.com.

[Aaron Selya]

The first mitigation listed here is to migrate existing partitioned cookies to include the new bit, and the second mitigation is to have a flag that can disable this feature. Would disabling the feature also include migrating the existing cookies back to exclude the new bit?

Disabling the flag would not migrate the existing cookies back to exclude the new bit. It would make it so that the new bit value is not considered when checking equivalence. Not considering the value of the bit when is the current behavior so we anticipate no issues ignoring the bit if the flag needs to disable the feature.

 

And somewhat related, but does the format of the cookie request developers make have to change too, or is this bit determination purely done within the browser?

 

In almost all cases this is set within the browser. The only circumstance I've run into where the value could be set by a developer is with the chrome.cookies.set api for extensions.  This API allows the developer to set the site associated with the cookie partition key and with this change would allow for the bit value to be set as well.

[Yoav Weiss (@Shopify)]

On Tue, Mar 12, 2024 at 4:46 PM 'Aaron Selya' via blink-dev <blin...@chromium.org> wrote:

The first mitigation listed here is to migrate existing partitioned cookies to include the new bit, and the second mitigation is to have a flag that can disable this feature. Would disabling the feature also include migrating the existing cookies back to exclude the new bit?

Disabling the flag would not migrate the existing cookies back to exclude the new bit. It would make it so that the new bit value is not considered when checking equivalence. Not considering the value of the bit when is the current behavior so we anticipate no issues ignoring the bit if the flag needs to disable the feature.

Can you clarify what kind of flag are we talking about? Is this a Finch flag we expect to turn off if we encounter lots of breakage? An enterprise policy flag? A flag we expect users to use? (I doubt it's the latter, but clarifications would help :D)

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALXbKU7so-698-KYua_iQ6PPyHQ_NnBcnJr-XetP%2BDCG_gQeWA%40mail.gmail.com.

[Yoav Weiss (@Shopify)]

Also, can you flip on the relevant review gates in chromestatus.com?

[Aaron Selya]

The flag is a base::features flag named kAncestorChainBitEnabledInPartitionedCookies.

Updated the review gates on chromestatus.com

[Yoav Weiss (@Shopify)]

OK, so just to summarize my understanding:

• We expect this to have some impact on 0.032% of page views
• We have a Finch flag that can be used as a kill switch in case we see lots of breakage in the wild
• Developers can get around this deprecation by changing their cookies to be "same-site: none" *and* requesting SAA from users

Is the above correct? 

If so, 0.032% sounds like a lot. Would it be possible for y'all to same pages that trigger that use counter and see how many of them break and what does breakage look like?

[Mike Taylor]

It would also be helpful to discuss what breakage looks like in this case. Would it be a one-time loss of state (i.e., have to log in again), or something different?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSL78hpV-iy6Ce%3Dn4a-aU21-2vj%2Bce4D9rLE_R0oUWKpqQ%40mail.gmail.com.

[Aaron Selya]

Yoav, your understanding is correct.

I'm still in the process of finalizing the implementation. Once that is done, I'll audit some sites that metrics have indicated will experience breakage and report back my findings.

[Aaron Selya]

My apologies for the delay in following up on this.

When I finished my initial implementation and got to the point where I could begin testing, I found that my metrics were being flooded with a cookie named, "receive-cookie-deprication". After doing some research and testing I learned that this cookie is used by sites for testing the potential impact of third party cookie depreciation but doesn't have any impact on website functionality. To get a better sense of potential breakage, I landed updated metrics that filtered out that cookie. I then conducted a manual audit on 10 (of the 104) sites that indicated a possible impact with a build of chromium that had the finch flag turned on. 

I've summarized my findings in this slide deck but I was unable to find a breakage that caused a site to not perform as expected from the user's perspective. To be clear, this doesn't mean that there won't be breakage that occurs if/when this feature goes live, only that I was unable to find an example where the website was unable to perform as expected.

Additionally, with the filtering out of the "receive-cookie-deprication" cookie from the metrics, the occurrences of an A1->B-A2 cookie which this change would impact drops from 0.032% of overall page loads to 0.0012% of overall page loads.

[Yoav Weiss (@Shopify)]

Thanks for diving into this!!

I guess the scariest bit here would be paypal losing a cookie in the redirect. Even if you didn't find a visible impact in your testing, they may not be exhaustive, and breakage there feels riskier than in other mentioned domains.

Have you tried to reach out to Paypal folks and see what they say?

On Wed, May 1, 2024 at 8:05 PM Aaron Selya <se...@google.com> wrote:

My apologies for the delay in following up on this.

When I finished my initial implementation and got to the point where I could begin testing, I found that my metrics were being flooded with a cookie named, "receive-cookie-deprication". After doing some research and testing I learned that this cookie is used by sites for testing the potential impact of third party cookie depreciation but doesn't have any impact on website functionality. To get a better sense of potential breakage, I landed updated metrics that filtered out that cookie. I then conducted a manual audit on 10 (of the 104) sites that indicated a possible impact with a build of chromium that had the finch flag turned on. 

I've summarized my findings in this slide deck but I was unable to find a breakage that caused a site to not perform as expected from the user's perspective. To be clear, this doesn't mean that there won't be breakage that occurs if/when this feature goes live, only that I was unable to find an example where the website was unable to perform as expected.

Additionally, with the filtering out of the "receive-cookie-deprication" cookie from the metrics, the occurrences of an A1->B-A2 cookie which this change would impact drops from 0.032% of overall page loads to 0.0012% of overall page loads.

That's extremely reassuring!

[Aaron Selya]

Thank you for suggesting a deeper dive into this Yoav as I might not have discovered the significant impact that the "receive-cookie-deprication" cookies were having on my metrics without your prompting. 

I've reached out to some engineers at Paypal and hopefully they'll get back to me sometime next week. 

[Yoav Weiss (@Shopify)]

Any news from Paypal?

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPSgjYROtVMp%3DmfBLFdW5KiRYkcFx0NG3U%3DT_vtbm2b7UEzm0w%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALXbKU7so-698-KYua_iQ6PPyHQ_NnBcnJr-XetP%2BDCG_gQeWA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Aaron Selya]

Had a good initial conversation with them on Monday letting them know about the issue. They're going to do some testing with the feature enabled to try and gauge the impact the feature will have on their backend. I'm hopeful that they'll give us an update by early next week.

Any news from Paypal?

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPSgjYROtVMp%3DmfBLFdW5KiRYkcFx0NG3U%3DT_vtbm2b7UEzm0w%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALXbKU7so-698-KYua_iQ6PPyHQ_NnBcnJr-XetP%2BDCG_gQeWA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Chris Harrelson]

Please also fill out the Testing section on chromestatus.com.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALXbKU4S-uqANu6JeJUxBy2vNecqfmnoqkQXQyeprdc_Qjo3BA%40mail.gmail.com.

[Aaron Selya]

@Chris, completed the testing section as requested. 

@Yoav, paypal requested a test site they could use for determining independently if the feature was activated for their testing. I provided them with a glitch.me site that shows if an A1->B->A2 embed is receiving cookies set in the top level site. If I don't hear back from them by the middle of next week, I'll reach out for a status update from them.

[Aaron Selya]

I haven't heard back from Paypal yet, I'm planning on following up with them today to see if they have any updates on their testing. 

Besides hearing back from them, is there any other information that's holding up LGTM?

[Aaron Selya]

Devtools updates have landed (see attached screenshot) and are available in Canary.

[Daniel Bratell]

From my point of view, the only concern is web compatibility. We need to prove to ourselves that this is web compatible enough to ship and unfortunately the use counters are a bit high (0.032%) . You have done further analysis so we know that the actual risk is lower than that but is it low enough?

You have mentioned that the counter would be lower if certain cases are excluded, but I am not sure I understand if that was just informative or if you consider giving those sites an exemption?

Since this thread has been going a while I might have misunderstood parts, so maybe you can give an update or summary of the web compatibility risk?

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALXbKU6hhVnSwx%2BwKL1haCmtAq7Cx5qZ6ghmMOsMEoHkAd%3DA6A%40mail.gmail.com.

[Aaron Selya]

Daniel,
My initial metrics were significantly higher due to the presence of a cookie named “receive-cookie-deprication”. This is a cookie, Google is using to help sites prepare for third-party cookie depreciation. It does not actually impact site functionality or cause site breakage, which is what the metrics were designed to try and identify. After filtering those cookies from the metrics, the usage rate dropped down to 0.0012% of page loads. This figure was shared as a part of my update on May 1st. 

My intention with the statement regarding excluding cases from the count, was to handle a situation where the metrics were being significantly impacted by a single identifiable case. In which the cookie that triggered the metrics could be proven to not have an impact on site behavior or cause breakage. This exact scenario occurred with the “receive-cookie-deprication” and was part of my justification for filtering that cookie from the metrics.

[Chris Harrelson]

LGTM1 based on the UseCounter being very low, but before shipping please update us on whether PayPal is not impacted.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALXbKU4MeFwdTqpMM5CDHvz0xL51PsbsuA3w5wLhR6-EEZp6Qw%40mail.gmail.com.

[Yoav Weiss (@Shopify)]

LGTM2

[Daniel Bratell]

LGTM3

/Daniel