LGTM1 based on the UseCounter being very low, but before shipping please update us on whether PayPal is not impacted.
On Wed, Jun 12, 2024 at 10:56 PM 'Aaron Selya' via blink-dev < blink-dev@chromium.org> wrote: > Daniel, > My initial metrics were significantly higher due to the presence of a > cookie named “receive-cookie-deprication”. This is a cookie > <https://developers.google.com/privacy-sandbox/relevance/setup/web/chrome-facilitated-testing#access_the_sec-cookie-deprecation_http_header>, > Google is using to help sites prepare for third-party cookie depreciation. > It does not actually impact site functionality or cause site breakage, > which is what the metrics were designed to try and identify. After > filtering those cookies from the metrics, the usage rate dropped down to > 0.0012% of page loads. This figure was shared as a part of my update on May > 1st. > > My intention with the statement regarding excluding cases from the count, > was to handle a situation where the metrics were being significantly > impacted by a single identifiable case. In which the cookie that triggered > the metrics could be proven to not have an impact on site behavior or cause > breakage. This exact scenario occurred with the > “receive-cookie-deprication” and was part of my justification for filtering > that cookie from the metrics. > > On Wed, Jun 12, 2024 at 7:55 AM Daniel Bratell <bratel...@gmail.com> > wrote: > >> From my point of view, the only concern is web compatibility. We need to >> prove to ourselves that this is web compatible enough to ship and >> unfortunately the use counters are a bit high (0.032%) . You have done >> further analysis so we know that the actual risk is lower than that but is >> it low enough? >> >> You have mentioned that the counter would be lower if certain cases are >> excluded, but I am not sure I understand if that was just informative or if >> you consider giving those sites an exemption? >> >> Since this thread has been going a while I might have misunderstood >> parts, so maybe you can give an update or summary of the web compatibility >> risk? >> >> /Daniel >> >> >> On 2024-06-07 21:44, 'Aaron Selya' via blink-dev wrote: >> >> Devtools updates have landed (see attached screenshot) and are available >> in Canary. >> >> On Thu, Jun 6, 2024 at 9:44 AM Aaron Selya <se...@google.com> wrote: >> >>> I haven't heard back from Paypal yet, I'm planning on following up with >>> them today to see if they have any updates on their testing. >>> >>> Besides hearing back from them, is there any other information that's >>> holding up LGTM? >>> >>> On Thu, May 30, 2024 at 1:53 PM Aaron Selya <se...@google.com> wrote: >>> >>>> @Chris, completed the testing section as requested. >>>> >>>> @Yoav, paypal requested a test site they could use for determining >>>> independently if the feature was activated for their testing. I provided >>>> them with a glitch.me <https://splashy-broadleaf-carp.glitch.me/> site >>>> that shows if an A1->B->A2 embed is receiving cookies set in the top level >>>> site. If I don't hear back from them by the middle of next week, I'll reach >>>> out for a status update from them. >>>> >>>> >>>> >>>> On Wed, May 22, 2024 at 11:39 AM Chris Harrelson <chris...@chromium.org> >>>> wrote: >>>> >>>>> Please also fill out the Testing section on chromestatus.com. >>>>> >>>>> On Wed, May 22, 2024 at 7:50 AM 'Aaron Selya' via blink-dev < >>>>> blink-dev@chromium.org> wrote: >>>>> >>>>>> Had a good initial conversation with them on Monday letting them know >>>>>> about the issue. They're going to do some testing with the feature >>>>>> enabled >>>>>> to try and gauge the impact the feature will have on their backend. I'm >>>>>> hopeful that they'll give us an update by early next week. >>>>>> >>>>>> On Wed, May 22, 2024 at 10:21 AM Yoav Weiss (@Shopify) < >>>>>> yoavwe...@chromium.org> wrote: >>>>>> >>>>>>> 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/CALXbKU4S-uqANu6JeJUxBy2vNecqfmnoqkQXQyeprdc_Qjo3BA%40mail.gmail.com >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALXbKU4S-uqANu6JeJUxBy2vNecqfmnoqkQXQyeprdc_Qjo3BA%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/CALXbKU6hhVnSwx%2BwKL1haCmtAq7Cx5qZ6ghmMOsMEoHkAd%3DA6A%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALXbKU6hhVnSwx%2BwKL1haCmtAq7Cx5qZ6ghmMOsMEoHkAd%3DA6A%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/CALXbKU4MeFwdTqpMM5CDHvz0xL51PsbsuA3w5wLhR6-EEZp6Qw%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALXbKU4MeFwdTqpMM5CDHvz0xL51PsbsuA3w5wLhR6-EEZp6Qw%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/CAOMQ%2Bw92FRf_uz%3D8NTAP92sH%3DEjLOeXOBWjqUB4WbFqBx6oKWQ%40mail.gmail.com.
