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 Statushttps://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/CAL5BFfVv0smi7_xWyGMs3ryYZBsNGi0ochdxHnZ3qa0tDn0TZQ%40mail.gmail.com.
