Contact emails se...@chromium.org, dylancut...@chromium.org, kaustub...@chromium.org
Explainer Keying of "CHIPS" cookies should align with other state: <https://github.com/privacycg/CHIPS/issues/40#issuecomment-1883726735> 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 <https://developers.google.com/privacy-sandbox/3pcd/chips#:~:text=A%20cookie%27s%20partition%20key%20is%20the%20site%20(scheme%20and%20registrable%20domain)%20of%20the%20top%2Dlevel%20URL%20the%20browser%20was%20visiting%20at%20the%20start%20of%20the%20request%20to%20the%20endpoint%20that%20set%20the%20cookie.> 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 <https://chromestatus.com/metrics/feature/timeline/popularity/4177>). 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 <https://issues.chromium.org/issues?q=customfield1222907:%22Internals%3ENetwork%3ECookies%3EPartitionedCookies%22> TAG review Not requested, as this does not differ in any significant way from the original CHIPS design that was already reviewed by TAG <https://github.com/w3ctag/design-reviews/issues/779>. 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 <https://github.com/mozilla/standards-positions/issues/678#issuecomment-1241916316> from Firefox as well as support from them for adding the cross-site ancestor chain bit <https://github.com/privacycg/meetings/blob/main/2023/telcons/10-12-minutes.md#keying-of-chips-cookies-should-align-with-other-state> . Webkit is still considering adopting CHIPS <https://github.com/WebKit/standards-positions/issues/50#issuecomment-1768040057> as we work through their concerns <https://github.com/privacycg/CHIPS/issues/74> 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 <https://bugs.chromium.org/p/chromium/issues/detail?id=1516984> 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 <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> ? We plan to land web-platform-tests shortly <https://bugs.chromium.org/p/chromium/issues/detail?id=1521791>. Flag name on chrome://flags CookiePartitionKeyIncludesCrossSiteAncestorChainBit <https://bugs.chromium.org/p/chromium/issues/detail?id=1521841> 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 -- 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+unsubscr...@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.
