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/CAOmohSLYKR3v25karPM7E3%3Dz3%2BwHp%3DD4zVMngLT_NX7Ji0CvbA%40mail.gmail.com.
