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 <https://docs.google.com/presentation/d/1S2N2vyGDaKAwP-5W5pVYqRNQ1RQndjlq4yVTny6hEIY/edit?usp=sharing> 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. On Tue, Mar 19, 2024 at 12:05 PM Aaron Selya <se...@google.com> wrote: > 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. > > On Tue, Mar 19, 2024 at 8:52 AM Mike Taylor <miketa...@chromium.org> > wrote: > >> 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? >> On 3/19/24 5:08 AM, Yoav Weiss (@Shopify) wrote: >> >> 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 >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSL78hpV-iy6Ce%3Dn4a-aU21-2vj%2Bce4D9rLE_R0oUWKpqQ%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/CALXbKU6qL3ycnNursXRQh3BQ5WKG792fGFTn5VDfcL94NvdpBg%40mail.gmail.com.
