Thank you for suggesting a deeper dive into this Yoav as I might not have discovered the significant impact that the "receive-cookie-deprication" cookies were having on my metrics without your prompting.
I've reached out to some engineers at Paypal and hopefully they'll get back to me sometime next week. On Fri, May 3, 2024 at 8:50 AM Yoav Weiss (@Shopify) <yoavwe...@chromium.org> wrote: > Thanks for diving into this!! > > I guess the scariest bit here would be paypal losing a cookie in the > redirect. Even if you didn't find a visible impact in your testing, they > may not be exhaustive, and breakage there feels riskier than in other > mentioned domains. > > Have you tried to reach out to Paypal folks and see what they say? > > On Wed, May 1, 2024 at 8:05 PM Aaron Selya <se...@google.com> wrote: > >> 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. >> > > That's extremely reassuring! > > >> >> 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/CALXbKU7AxVtVbUNO840uUyBQJN_0XLUAP6TQaDD%3DOXycf5Kiuw%40mail.gmail.com.
