@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/CALXbKU7xUk%3DRGR1FgfWHvymyMJDhb%3DEPZW%3DgWpsy%3DyWfyj9_nQ%40mail.gmail.com.
