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) < [email protected]> 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) < > [email protected]> wrote: > >> >> >> On Tue, Mar 12, 2024 at 4:46 PM 'Aaron Selya' via blink-dev < >> [email protected]> 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 <[email protected]> >>> wrote: >>> >>>> >>>> >>>> On Mon, Mar 11, 2024 at 1:42 PM Aaron Selya <[email protected]> wrote: >>>> >>>>> Contact emails >>>>> >>>>> [email protected], [email protected], [email protected] >>>>> >>>>> >>>>> 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 [email protected]. >>>>> 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 [email protected]. >>> 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALXbKU6XqAia1JEgaomDHEwbdeBSv5JMQ85fGPSDDs1zOqGvdg%40mail.gmail.com.
