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? On Wed, Mar 13, 2024 at 8:23 PM Aaron Selya <se...@google.com> wrote: > The flag is a base::features flag named > kAncestorChainBitEnabledInPartitionedCookies. > > Updated the review gates on chromestatus.com > > On Wed, Mar 13, 2024 at 11:25 AM Yoav Weiss (@Shopify) < > yoavwe...@chromium.org> wrote: > >> Also, can you flip on the relevant review gates in chromestatus.com? >> >> On Wed, Mar 13, 2024 at 11:24 AM Yoav Weiss (@Shopify) < >> yoavwe...@chromium.org> wrote: >> >>> >>> >>> On Tue, Mar 12, 2024 at 4:46 PM 'Aaron Selya' via blink-dev < >>> blink-dev@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) >>> >>> >>>> >>>> >>>>> 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. >>>> >>>> On Tue, Mar 12, 2024 at 2:53 PM Vladimir Levin <vmp...@chromium.org> >>>> wrote: >>>> >>>>> >>>>> >>>>> On Mon, Mar 11, 2024 at 1:42 PM Aaron Selya <se...@chromium.org> >>>>> wrote: >>>>> >>>>>> 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. >>>>>> >>>>> >>>>> 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 >>>>>> <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 >>>>>> >>>>> >>>>> 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+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 >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPSgjYROtVMp%3DmfBLFdW5KiRYkcFx0NG3U%3DT_vtbm2b7UEzm0w%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>> -- >>>> 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/CALXbKU7so-698-KYua_iQ6PPyHQ_NnBcnJr-XetP%2BDCG_gQeWA%40mail.gmail.com >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALXbKU7so-698-KYua_iQ6PPyHQ_NnBcnJr-XetP%2BDCG_gQeWA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- 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/CAOmohSL78hpV-iy6Ce%3Dn4a-aU21-2vj%2Bce4D9rLE_R0oUWKpqQ%40mail.gmail.com.
