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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >>> 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 < >>>> [email protected]> 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) < >>>>> [email protected]> 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) < >>>>>>> [email protected]> 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 <[email protected]> >>>>>>>> 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 <[email protected]> >>>>>>>>> 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 < >>>>>>>>>> [email protected]> 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 <[email protected]> >>>>>>>>>>> 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) < >>>>>>>>>>>> [email protected]> 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) < >>>>>>>>>>>>> [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/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 [email protected]. >>>>> 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 [email protected]. > 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALXbKU4MeFwdTqpMM5CDHvz0xL51PsbsuA3w5wLhR6-EEZp6Qw%40mail.gmail.com.
