Any news from Paypal? On Friday, May 3, 2024 at 7:15:58 PM UTC+2 Aaron Selya wrote:
> 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/ec4c847a-d146-4d1d-9831-f6ee93664892n%40chromium.org.
