There is an ongoing conversation with Mozilla and Safari for the coordinated removal of wildcard support for ACAH.
Firefox has this implemented <https://bugzilla.mozilla.org/show_bug.cgi?id=1687364> behind a flag, same as we do, and we are waiting for Safari's plans at this point. On Thu, Jul 20, 2023 at 12:46 AM Yoav Weiss <yoavwe...@chromium.org> wrote: > Any updates on this? :) > > On Wed, May 24, 2023 at 10:48 AM Javier Garcia Visiedo < > visi...@chromium.org> wrote: > >> I was targeting M116, which is aligned with what Firefox indicated. >> However, other browsers are yet to confirm their timeline, and they have >> indicated they might need more time, which makes 116 unrealistic if we want >> to get other browsers in addition to Firefox onboard. >> >> Regarding the outreach plan, we haven't discussed it in detail, but I >> imagine it'd be something like blog posts from each vendor, in addition to >> the existing warnings on the developer tools. >> >> I'll come back once I get more details from the remaining vendors. >> >> On Tue, May 23, 2023 at 8:07 PM Yoav Weiss <yoavwe...@chromium.org> >> wrote: >> >>> I'd be supportive of a coordinated change, given that popular 3P >>> outreach was successful, and 1P use is unlikely to result in user visible >>> breakage. >>> What's the timeline you have in mind? What's the outreach plan to make >>> developers aware of this upcoming change? >>> >>> On Tuesday, May 16, 2023 at 7:03:34 PM UTC+2 vis...@google.com wrote: >>> >>>> Yes, I've got a positive response from the two 3P APIs (relatively >>>> popular). One case is already solved and in production, the second one, >>>> responsible for a huge increase on the UKM entries from February - March is >>>> solved and testing right now. >>>> >>>> However, I believe we still want to coordinate the launch with other >>>> browsers. Discussions are ongoing in this sense, and so far Firefox >>>> confirmed they are in a similar situation, code complete and ready to ship >>>> if / when we are. >>>> >>>> On Mon, May 15, 2023 at 10:57 PM Mike Taylor <miketa...@chromium.org> >>>> wrote: >>>> >>>>> Hi Javier, >>>>> >>>>> On 4/5/23 5:54 AM, Javier Garcia Visiedo wrote: >>>>> >>>>> For these visual elements, are there any common threads that you could >>>>>> notice? E.g. Any common 3P providers? >>>>>> >>>>> >>>>> In all cases I've seen, these are 1P requests of the form >>>>> https://foo.example to https://api.foo.example/api/v1/blah. I've not >>>>> found many sites with these visual element impacts, so I've been trying >>>>> to contact them. So far with no luck. >>>>> >>>>> I guess the same question also applies to the non-visual breakage. >>>>>> (you mentioned analytics and personalization providers) >>>>> >>>>> >>>>> These account for the majority of the cases I found, and all but 2 of >>>>> them are 1P. >>>>> >>>>> I have identified two cases of 3P which are quite relevant, and have >>>>> just made contact with them. I will provide an update once I receive >>>>> feedback. >>>>> >>>>> Any luck hearing back from these sites? >>>>> >>>>> >>>>> >>>>> On Thu, Mar 30, 2023 at 1:35 AM Yoav Weiss <yoavwe...@chromium.org> >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Wed, Mar 29, 2023 at 11:01 AM Yoav Weiss <yoavwe...@chromium.org> >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Mar 29, 2023 at 10:32 AM Javier Garcia Visiedo < >>>>>>> visi...@chromium.org> wrote: >>>>>>> >>>>>>>> Thank you for your quick reply Yoav, >>>>>>>> >>>>>>>> Please find my answers inline. >>>>>>>> >>>>>>>> >>>>>>>> On Wednesday, March 29, 2023 at 4:35:32 PM UTC+9 Yoav Weiss wrote: >>>>>>>> >>>>>>>> Thank you so much, Javier! :) That's some great analysis! >>>>>>>> >>>>>>>> On Wed, Mar 29, 2023 at 7:51 AM Javier Garcia Visiedo < >>>>>>>> visi...@chromium.org> wrote: >>>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Please find the summary of my findings, after analyzing the UKM >>>>>>>> data. >>>>>>>> >>>>>>>> Currently, the UKM data shows 2,087 distinct domains (eTLD+1) >>>>>>>> sending a wildcard for ACAH and/or ACAO in response to a credentialled >>>>>>>> request. The UKM data is not good at showing events over time, but the >>>>>>>> use >>>>>>>> counter >>>>>>>> <https://chromestatus.com/metrics/feature/timeline/popularity/3873> >>>>>>>> indicates the feature use is currently at 0.12% of total page loads, >>>>>>>> and >>>>>>>> the monthly average of page loads has been steadily increasing since >>>>>>>> the >>>>>>>> introduction of the use counter. >>>>>>>> >>>>>>>> Out of the 2,087 domains found in the UKM, the top one accounts for >>>>>>>> 39.24% of the total navigations in the UKM (54% within top 20 sites), >>>>>>>> using >>>>>>>> this feature. The user experience is not visibly impacted for this >>>>>>>> site, as >>>>>>>> CORS is blocking calls to a publisher.Ads are displayed properly, so >>>>>>>> apparently the blocked calls are impacting some kind of targeted ads >>>>>>>> API. >>>>>>>> This site came into the data set for the first time in March 2023, and >>>>>>>> it’s >>>>>>>> very popular, so we expect to observe a big bump on the use counter >>>>>>>> from >>>>>>>> now on. This site is an outlier in terms of traffic volume, compared to >>>>>>>> other sites present in the UKM, and given the lack of Ux impact we >>>>>>>> decided >>>>>>>> to exclude it from the analysis presented below, to get a better >>>>>>>> representation for the rest of the sites. >>>>>>>> >>>>>>>> Excluding the top site, we tested the next top 20 domains in number >>>>>>>> of navigations using this feature, accounting for 42% of the total >>>>>>>> navigation in the UKM. In addition to this, we sampled the long tail >>>>>>>> for 11 >>>>>>>> more sites randomly, for an additional 3,4% of the total navigation in >>>>>>>> the >>>>>>>> UKM. >>>>>>>> >>>>>>>> Extrapolating data from the sampling, we classified sites in the >>>>>>>> following categories: >>>>>>>> >>>>>>>> - >>>>>>>> >>>>>>>> No Ux impact: 94.85% of the navigations are free from visible >>>>>>>> user experience impacts. In most cases, CORS policy is blocking >>>>>>>> calls to >>>>>>>> personalization or analytics APIs. >>>>>>>> >>>>>>>> >>>>>>>> "CORS policy" here refers to the status quo before this feature >>>>>>>> ships? >>>>>>>> >>>>>>>> >>>>>>>> No, these calls are blocked when activating the feature >>>>>>>> >>>>>>> >>>>>>> Oh, ok. So these may have invisible breakage, that results in some >>>>>>> ancillary service failure, but that users are unlikely to notice. >>>>>>> >>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> - >>>>>>>> >>>>>>>> Impact to critical functionality, overall experience, log-in, >>>>>>>> etc.: 2.6% >>>>>>>> - >>>>>>>> >>>>>>>> Impact to ancillary elements being blocked by CORS policy, such >>>>>>>> as ads or widgets not essential to the overall page functionality: >>>>>>>> 2.55% >>>>>>>> >>>>>>>> Putting these numbers in context of the total page loads reported >>>>>>>> by the use counter, 0,0062% of the total page loads experience some UX >>>>>>>> regression due to the introduction of this feature. Of these, 0,0031% >>>>>>>> was >>>>>>>> unusable. >>>>>>>> >>>>>>>> We reached out to the site owners with Ux impacts, and we were able >>>>>>>> to confirm that 100% of the sites identified to have critical impact >>>>>>>> have >>>>>>>> already migrated out of this feature. >>>>>>>> >>>>>>>> That's a bit higher than what we're typically comfortable with, but >>>>>>>> it's great to hear that sites you reach out to react quickly. >>>>>>>> How much of that impact was in the top 20 (where we can reasonably >>>>>>>> reach out) vs. the long tail (where it'd be significantly harder to >>>>>>>> communicate things beyond deprecation logs and reports)? >>>>>>>> >>>>>>>> >>>>>>>> For sites with high impact (already addressed) 100% were found in >>>>>>>> the top 20. >>>>>>>> >>>>>>> >>>>>>> That's very reassuring, thanks! >>>>>>> >>>>>>> >>>>>>>> For sites where some visual elements are blocked, 55% (1.48% of >>>>>>>> total navigations registered in the UKM for this feature) are part of >>>>>>>> the >>>>>>>> top 20, 45% in the long tail, with 1.07% of total navigations in the >>>>>>>> UKM. >>>>>>>> >>>>>>> >>>>>> For these visual elements, are there any common threads that you >>>>>> could notice? E.g. Any common 3P providers? >>>>>> I guess the same question also applies to the non-visual breakage. >>>>>> (you mentioned analytics and personalization providers) >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>>> >>>>>>>> Happy to further clarify the data if needed. >>>>>>>> >>>>>>>> Thanks >>>>>>>> Javier >>>>>>>> >>>>>>>> On Wednesday, July 13, 2022 at 2:49:30 PM UTC+9 Yoav Weiss wrote: >>>>>>>> >>>>>>>> Hey Javier! >>>>>>>> >>>>>>>> The benefits of UKM is that it can give us a list of URLs that have >>>>>>>> some breakage potential. The laternative is to cross the usecounter >>>>>>>> with >>>>>>>> HTTPArchive data, but that has a strong bias towards homepages, so may >>>>>>>> miss >>>>>>>> a lot of pages that require a login and are not the homepage. With a >>>>>>>> more >>>>>>>> accurate list of URLs, we'd be able to better assess the usage and >>>>>>>> potential breakage. >>>>>>>> >>>>>>>> Cheers :) >>>>>>>> Yoav >>>>>>>> >>>>>>>> On Wed, Jul 13, 2022 at 3:52 AM Javier Garcia Visiedo < >>>>>>>> visi...@chromium.org> wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> I am starting a UKM collection review to opt in the existing use >>>>>>>> counter >>>>>>>> <https://chromestatus.com/metrics/feature/timeline/popularity/3873> >>>>>>>> into an UKM. Sorry if my question is too naive, I just wanted to >>>>>>>> understand >>>>>>>> what benefits would the UKM add over the existing use counter? Or is >>>>>>>> it the >>>>>>>> intention to add additional metrics to it? Thanks! >>>>>>>> Cheers >>>>>>>> Javier >>>>>>>> >>>>>>>> >>>>>>>> On Thursday, January 27, 2022 at 1:33:19 AM UTC+9 Chris Harrelson >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hi, just checking in on this intent. From the API owners' >>>>>>>> perspective, we're going to wait for the UKM, thanks. >>>>>>>> >>>>>>>> On Wed, Jan 12, 2022 at 7:41 AM Yutaka Hirano <yhir...@chromium.org> >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hi Yoav, >>>>>>>> >>>>>>>> Thank you for the suggestions. I'll try to add UKM. >>>>>>>> >>>>>>>> > One other question that came up: Is the usage related to >>>>>>>> developers adding the "Authorization" header on their own, or is it >>>>>>>> something the browser sends under certain circumstances? (e.g. when >>>>>>>> receiving 401 responses with "WWW-Autenticate" headers) >>>>>>>> >>>>>>>> This is only for authorization headers set by scripts (via fetch() >>>>>>>> and XHR). Authorization headers the browser attaches are out of scope. >>>>>>>> >>>>>>>> On Thu, Jan 6, 2022 at 2:15 AM Yoav Weiss <yoavwe...@chromium.org> >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hey Yutaka! >>>>>>>> >>>>>>>> We discussed this at the API owners meeting today (Daniel, Chris, >>>>>>>> Alex, MikeT and myself). >>>>>>>> It seems like the risk here is too high to remove support as is, >>>>>>>> and a reasonable next step may be to add the metric to UKM and get a >>>>>>>> more >>>>>>>> detailed view of which sites are using it and how. That would enable >>>>>>>> us to >>>>>>>> better assess breakage, and reach out to those sites to reduce current >>>>>>>> usage until potential breakage reaches acceptable levels. >>>>>>>> >>>>>>>> One other question that came up: Is the usage related to developers >>>>>>>> adding the "Authorization" header on their own, or is it something the >>>>>>>> browser sends under certain circumstances? (e.g. when receiving 401 >>>>>>>> responses with "WWW-Autenticate" headers) >>>>>>>> Would renaming the headers used in such authentication protocols be >>>>>>>> a useful alternative to consider? I'm guessing that doing that would >>>>>>>> require server changes as well, so won't necessarily help with cases of >>>>>>>> existing content, but may help to move newer auth flows to make safer >>>>>>>> CORS >>>>>>>> choices. >>>>>>>> >>>>>>>> Cheers :) >>>>>>>> Yoav >>>>>>>> >>>>>>>> On Thursday, December 9, 2021 at 12:17:40 PM UTC+1 Yutaka Hirano >>>>>>>> wrote: >>>>>>>> >>>>>>>> We've been showing a deprecation message since 94 >>>>>>>> <https://chromiumdash.appspot.com/commit/9a817d69a132822ddf2954120e96a3efa2290071>. >>>>>>>> Sadly the deprecation message hasn't decreased the usage so far. >>>>>>>> >>>>>>>> On Thu, Dec 9, 2021 at 1:52 AM Mike West <mk...@chromium.org> >>>>>>>> wrote: >>>>>>>> >>>>>>>> From my perspective, it's a bit worrying that you found >>>>>>>> user-visible breakage in a random sampling of the otherwise small >>>>>>>> number of >>>>>>>> sites that fall into this category. As Yoav suggested, there's some >>>>>>>> additional likelihood that we're not seeing some breakage that requires >>>>>>>> sign-in. It might be worthwhile to raise a deprecation warning for this >>>>>>>> behavior, and remove it after giving developers some time to adjust, >>>>>>>> perhaps with an enterprise policy for good measure. I'd be happy with a >>>>>>>> 3-release timeline, with removal thereafter. That might drive the usage >>>>>>>> down to the point where we can reasonably remove it. If it doesn't, we >>>>>>>> might need to do some more research (wiring this counter up to UKM, for >>>>>>>> instance) to see if we can track down more clear sources of potential >>>>>>>> breakage. >>>>>>>> >>>>>>>> -mike >>>>>>>> >>>>>>>> On Thursday, December 2, 2021 at 6:56:40 AM UTC+1 Yutaka Hirano >>>>>>>> wrote: >>>>>>>> >>>>>>>> On Thu, Dec 2, 2021 at 12:29 AM Yoav Weiss <yoavwe...@chromium.org> >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Dec 1, 2021 at 4:00 PM Yutaka Hirano <yhir...@chromium.org> >>>>>>>> wrote: >>>>>>>> >>>>>>>> Sorry for the delay! >>>>>>>> >>>>>>>> I checked 10 sites. I saw console errors in three sites among them: >>>>>>>> 1. https://cchatty.com/ >>>>>>>> 2. https://techrxiv.org/ >>>>>>>> 3. https://bodyshake.com/ >>>>>>>> >>>>>>>> I only see a visible breakage in 1 (cards in the main panel are >>>>>>>> invisible). On other sites I don't see any visible differences. >>>>>>>> Please note that this feature is related to authorization so it is >>>>>>>> likely to break things when signing in. >>>>>>>> >>>>>>>> >>>>>>>> So it's possible that the breakage only occurs for logged in users, >>>>>>>> and is not something you'd be able to see when spot checking their >>>>>>>> homepage? >>>>>>>> >>>>>>>> >>>>>>>> Yeah, I think so. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Dec 1, 2021 at 8:11 PM Yoav Weiss <yoavwe...@chromium.org> >>>>>>>> wrote: >>>>>>>> >>>>>>>> Friendly ping on Chris' question >>>>>>>> >>>>>>>> On Thursday, November 4, 2021 at 8:31:36 PM UTC+1 Chris Harrelson >>>>>>>> wrote: >>>>>>>> >>>>>>>> Would it be feasible to get a random list of 10-20 sites that hit >>>>>>>> the use counter and see if they are broken badly by this feature? >>>>>>>> >>>>>>>> On Thu, Nov 4, 2021 at 4:54 AM Yutaka Hirano <yhir...@chromium.org> >>>>>>>> wrote: >>>>>>>> >>>>>>>> (friendly ping) >>>>>>>> >>>>>>>> On Mon, Nov 1, 2021 at 1:57 PM Yutaka Hirano <yhir...@chromium.org> >>>>>>>> wrote: >>>>>>>> >>>>>>>> Thank you for the feedback. >>>>>>>> >>>>>>>> Do you have concrete steps for the investigation in your mind? >>>>>>>> >>>>>>>> On Fri, Oct 29, 2021 at 4:30 AM Mike West <mk...@chromium.org> >>>>>>>> wrote: >>>>>>>> >>>>>>>> I think it's reasonable for us to dig into the data a little bit to >>>>>>>> determine whether the 0.04% number quoted above will result in >>>>>>>> user-facing >>>>>>>> breakage. Yutaka, is that something you'd be willing to dig into? >>>>>>>> >>>>>>>> The direction seems philosophically correct to me, so I'd like to >>>>>>>> see it ship, but I'd also like to make sure we're not making the web >>>>>>>> worse >>>>>>>> for users by doing so. >>>>>>>> >>>>>>>> -mike >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Oct 21, 2021 at 12:04 PM Yutaka Hirano < >>>>>>>> yhir...@chromium.org> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Oct 21, 2021 at 6:25 PM Yoav Weiss <yoavwe...@chromium.org> >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Oct 21, 2021 at 9:55 AM Yutaka Hirano <yhir...@chromium.org> >>>>>>>> wrote: >>>>>>>> >>>>>>>> (The implementation CL >>>>>>>> <https://chromium-review.googlesource.com/c/chromium/src/+/3226283> >>>>>>>> is under review. This intent is written as if it's landed.) >>>>>>>> >>>>>>>> Contact emailsyhir...@chromium.org >>>>>>>> >>>>>>>> Specificationhttps://fetch.spec.whatwg.org/ >>>>>>>> #cors-non-wildcard-request-header-name >>>>>>>> >>>>>>>> Summary >>>>>>>> >>>>>>>> A CORS non-wildcard request header[1] is an HTTP request header >>>>>>>> which is not covered by the wildcard symbol ("*") in the >>>>>>>> access-control-allow-headers header. "authorization" is the only >>>>>>>> member of >>>>>>>> CORS non-wildcard request-header. Currently we treat the header as a >>>>>>>> usual >>>>>>>> header, which is problematic for security reasons. Implement it, and >>>>>>>> change >>>>>>>> the current behavior. 1: https://fetch.spec.whatwg.org/ >>>>>>>> #cors-non-wildcard-request-header-name >>>>>>>> >>>>>>>> >>>>>>>> Blink componentBlink>SecurityFeature>CORS >>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ESecurityFeature%3ECORS> >>>>>>>> >>>>>>>> TAG reviewNot needed because this implements an existing feature. >>>>>>>> >>>>>>>> TAG review statusNot applicable >>>>>>>> >>>>>>>> Risks >>>>>>>> >>>>>>>> >>>>>>>> Interoperability and Compatibility >>>>>>>> >>>>>>>> Interoperability risk is low because Mozilla and Apple showed an >>>>>>>> intent to implement this behavior. There is some compatibility risk, >>>>>>>> as the >>>>>>>> use counter[2] shows 0.04% websites would be affected. To mitigate the >>>>>>>> risk, we've shown a deprecation message for a few milestones. >>>>>>>> >>>>>>>> >>>>>>>> Can you similarly send deprecation reports as well? How long have >>>>>>>> the deprecation messages been in place? Did we see any decline in the >>>>>>>> numbers? >>>>>>>> >>>>>>>> We've shown the deprecation message since Chrome 94 >>>>>>>> <https://chromiumdash.appspot.com/commit/9a817d69a132822ddf2954120e96a3efa2290071> >>>>>>>> whose >>>>>>>> beta promotion was on Aug 26 and stable release was on Sep 21. >>>>>>>> We use CountDeprecation which sends deprecation reports >>>>>>>> automatically IIUC. >>>>>>>> >>>>>>>> I don't see any decline. >>>>>>>> >>>>>>>> >>>>>>>> Have we looked into which URLs are triggering this? (and if it's a >>>>>>>> few medium-sized properties or many tiny ones) >>>>>>>> >>>>>>>> >>>>>>>> I haven't looked at the data. >>>>>>>> >>>>>>>> Did we try outreach? >>>>>>>> >>>>>>>> No. >>>>>>>> >>>>>>>> >>>>>>>> We have an enterprise policy so that administrators can keep the >>>>>>>> existing behavior. We're planning to remove the policy on Chrome 103. >>>>>>>> 2: >>>>>>>> https://www.chromestatus.com/metrics/feature/popularity# >>>>>>>> AuthorizationCoveredByWildcard >>>>>>>> >>>>>>>> >>>>>>>> Gecko: Positive Firefox showed a positive signal in a private >>>>>>>> thread. >>>>>>>> >>>>>>>> WebKit: Positive Apple showed a positive signal in a private >>>>>>>> thread. >>>>>>>> >>>>>>>> Web developers: No signals >>>>>>>> >>>>>>>> >>>>>>>> Debuggability >>>>>>>> >>>>>>>> We'll show a CORS error to the devtools console. >>>>>>>> >>>>>>>> >>>>>>>> Is this feature fully tested by web-platform-tests >>>>>>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> >>>>>>>> ?Yes >>>>>>>> >>>>>>>> Flag nameCorsNonWildcardRequestHeadersSupport >>>>>>>> >>>>>>>> Requires code in //chrome?False (or, True only for the enterprise >>>>>>>> policy.) >>>>>>>> >>>>>>>> Tracking bughttps://crbug.com/1176753 >>>>>>>> >>>>>>>> Estimated milestones >>>>>>>> >>>>>>>> 97 >>>>>>>> >>>>>>>> Link to entry on the Chrome Platform Status >>>>>>>> https://chromestatus.com/feature/5742041264816128 >>>>>>>> -- >>>>>>>> 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/CABihn6G2mzUAH_Ghrqmb1xM7XetfKgB%3DMUkX0DED7yWbL4JfGg%40mail. >>>>>>>> gmail.com >>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABihn6G2mzUAH_Ghrqmb1xM7XetfKgB%3DMUkX0DED7yWbL4JfGg%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/CABihn6GB-CbbCqx0VHa7%3DLoZr%2BZN-O7o7XwTGkxXEYQa9OfupQ%40mail. >>>>>>>> gmail.com >>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABihn6GB-CbbCqx0VHa7%3DLoZr%2BZN-O7o7XwTGkxXEYQa9OfupQ%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/ >>>>>>>> CABihn6EqkidJF3mjfnztmMnKrEpb%3DPTvW-kpW0s_bWCM%3DOXY8A% >>>>>>>> 40mail.gmail.com >>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABihn6EqkidJF3mjfnztmMnKrEpb%3DPTvW-kpW0s_bWCM%3DOXY8A%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/CAMFgMgw_1WzXH6ewDJQk3bKrz%3DwdPzUp%2B7vRDKpMzeRK%2B43%3DUw%40mail.gmail.com >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMFgMgw_1WzXH6ewDJQk3bKrz%3DwdPzUp%2B7vRDKpMzeRK%2B43%3DUw%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/0333ba45-d1e2-8afe-0431-0d6254d794e0%40chromium.org >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0333ba45-d1e2-8afe-0431-0d6254d794e0%40chromium.org?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/CAMFgMgzVvSxN1JH%2BjhHQZ4UnXidrUjRbXhomMAgf92KPMURmBA%40mail.gmail.com.
