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/CAOMQ%2Bw9o%3DuXu-05eU2_vHJTneWLAQUA7X8BPGL2ez2Ljdk5m2A%40mail.gmail.com.
