Thanks Ken for addressing this feedback. Despite the lack of consensus I believe we should ship this now, so LGTM3.
Of course we should continue to look at user feedback, UXR and developer feedback to ensure we're striking a great experience for users here (as with FedCM which raises similar concerns depending on the details of UX treatment). It seems like we can always remove immediate mode if we decide it's user-hostile in practice, or even intervene on sites exhibiting a certain pattern of user-hostile behavior. So the only one-way door I personally worry about here is allowing fear of abuse to prevent further deployment experience, exploration and learning. On Wed, Apr 8, 2026 at 9:24 AM Ken Buchanan <[email protected]> wrote: > Do API owners have any other questions or concerns about this? This launch > is targeting Chrome 148 which branched on Monday. > > On Thu, Apr 2, 2026 at 3:45 PM Ken Buchanan <[email protected]> wrote: > >> >> We've decided to accept that change. The spec PR and explainer have been >> updated, and there is a change to the Chrome implementation in code review. >> >> The Chrome privacy team asked us to tighten the rate limiter to >> compensate for not consuming the transient user gesture. Requests are >> rejected if more than two are made within a five-second window on a single >> page. >> >> >> On Wed, Apr 1, 2026 at 2:58 PM Ken Buchanan <[email protected]> wrote: >> >>> Yoav, we are still investigating on our side but here's an update. >>> >>> We had not considered the possibility of requiring a user gesture >>> without consuming it until some of your organization's people raised the >>> possibility last month. The use case is that this API could be called, and >>> then a popup would be triggered in the case where no credentials are >>> available. Consuming the transient activation would prevent the popup from >>> working. >>> >>> If we change that, it should be done before initial launch. Relaxing the >>> restriction later would make it difficult for a site to know in advance >>> whether the popup will work. >>> >>> We have an ongoing internal discussion about the question and I will >>> update this thread when we reach a conclusion. >>> >>> On Wed, Mar 25, 2026 at 11:32 AM Yoav Weiss (@Shopify) < >>> [email protected]> wrote: >>> >>>> One point that came up last week (and apparently also as part of the >>>> TAG review) is that because this consumes user activation, developers may >>>> have a hard time integrating this feature into auth flows, that often >>>> involve popups. >>>> >>>> Is this something you considered? If this turns out to be an issue with >>>> developers, can this change without breakage? >>>> >>>> On Wednesday, March 25, 2026 at 2:40:23 PM UTC+1 Ken Buchanan wrote: >>>> >>>>> Friendly ping on this intent. It currently has two approvals from API >>>>> owners. >>>>> >>>>> On Wed, Mar 18, 2026 at 5:57 PM Jeffrey Yasskin <[email protected]> >>>>> wrote: >>>>> >>>>>> On Wed, Mar 18, 2026 at 1:53 PM Ken Buchanan <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Mar 18, 2026 at 11:59 AM Jeffrey Yasskin < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> On Wed, Mar 18, 2026 at 8:32 AM Ken Buchanan <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Mar 18, 2026 at 10:16 AM Daniel Bratell < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> How obvious will the existence of browser stored credentials be >>>>>>>>>> to the web site? >>>>>>>>>> >>>>>>>>>> What if I clear site data in the browser? >>>>>>>>>> >>>>>>>>> >>>>>>>>> Since the credentials come from the passkey provider/password >>>>>>>>> manager, clearing site data has no effect. >>>>>>>>> >>>>>>>> >>>>>>>> In the TAG review, I thought everyone had agreed that if the user >>>>>>>> uses browser UI to sign out of a site (which is accomplished by >>>>>>>> clearing >>>>>>>> site data), the browser should hide the fact that the user has a >>>>>>>> passkey >>>>>>>> until the user next chooses to sign in with a passkey. I now see that >>>>>>>> you >>>>>>>> removed that section from the explainer after I last looked: >>>>>>>> https://github.com/w3c/webauthn/wiki/Explainer:-WebAuthn-immediate-mediation/_compare/cef140c78ffe6ea855eb3f8d3c56db7cb17596c8...874f2dcf4c3b831db8169a92ccf828a03ff6551e. >>>>>>>> At the very least, this should continue to live in the Alternatives >>>>>>>> Considered section, with the reason for choosing against it. >>>>>>>> >>>>>>> >>>>>>> Thank you for the suggestion. I have added that to the explainer. >>>>>>> >>>>>> >>>>>> Thanks! >>>>>> >>>>>> >>>>>>> >>>>>>>> But I'll re-iterate the TAG's >>>>>>>> <https://github.com/w3ctag/design-reviews/issues/1092#issuecomment-3630215411> >>>>>>>> feedback >>>>>>>> <https://github.com/w3ctag/design-reviews/issues/1092#issuecomment-3630215411> >>>>>>>> that it's user-hostile to force someone to go over to Incognito in >>>>>>>> order to >>>>>>>> hide the fact that they have an account. If I want to use the 'guest' >>>>>>>> flow >>>>>>>> on a site that I've previously logged into, the UI that you've >>>>>>>> mocked in the explainer >>>>>>>> <https://github.com/w3c/webauthn/wiki/Explainer:-WebAuthn-immediate-mediation#contextual-sign-in-moments> >>>>>>>> forces me to 'close' my attempt to check out in order to get to the >>>>>>>> guest >>>>>>>> flow. This seems likely to coerce users to sign in, since they don't >>>>>>>> actually want to 'close' their attempt to check out. Browsers shouldn't >>>>>>>> facilitate that. >>>>>>>> >>>>>>> >>>>>>> I share the view that in general we should minimize information >>>>>>> leakage through side channels. However, it's far from certain that the >>>>>>> API >>>>>>> would be abused in this way, since the scenario where this is possible >>>>>>> is >>>>>>> rare in practice. One advantage of this API change is that the browser >>>>>>> does >>>>>>> not guarantee UI will be shown even if credentials are available. This >>>>>>> allows for flexibility to add restrictions later if we observe the >>>>>>> feature >>>>>>> being used in user-hostile ways. Doing that would pose no risk of >>>>>>> breakage. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> This touches on Alex's point about litigating specific UI choices: >>>>>>>> it's fine if there are some "good" UIs and some "bad" UIs for a >>>>>>>> proposed >>>>>>>> API shape. The problem with this one is that I haven't yet seen a UI >>>>>>>> design >>>>>>>> for it that gives the user a free choice between >>>>>>>> logging-in-with-their-passkey and using some other method to accomplish >>>>>>>> their goal. If no such UI exists, that's an issue with the API itself. >>>>>>>> >>>>>>>> Jeffrey >>>>>>>> >>>>>>>> In terms of obviousness, a site that wanted to know if UI was shown >>>>>>>>> could fairly easily determine it by timing how long it takes before >>>>>>>>> the >>>>>>>>> promise is rejected (i.e., it can distinguish between no UI being >>>>>>>>> shown, >>>>>>>>> and UI being shown but the user dismissing it). >>>>>>>>> >>>>>>>>> One limitation we've added is that in incognito mode this API >>>>>>>>> behaves the same as when there are no credentials available, based on >>>>>>>>> users >>>>>>>>> having a higher expectation of privacy while using that mode. >>>>>>>>> >>>>>>>>> >>>>>>>>>> /Daniel >>>>>>>>>> On 2026-03-11 16:35, Ken Buchanan wrote: >>>>>>>>>> >>>>>>>>>> Hi Yoav, >>>>>>>>>> >>>>>>>>>> That's correct. Apple agrees with the use case but dislikes the >>>>>>>>>> information leakage. The website can easily infer that browser UI is >>>>>>>>>> being >>>>>>>>>> shown, which lets them know a passkey exists for this user even if >>>>>>>>>> the user >>>>>>>>>> does not choose to sign in with one. >>>>>>>>>> >>>>>>>>>> We spent some time exploring their alternative proposal. It ends >>>>>>>>>> up being something quite different, though, and we decided to >>>>>>>>>> continue with >>>>>>>>>> this based on partner feedback. Since in their case the promise >>>>>>>>>> would not >>>>>>>>>> be rejected if no passkeys are available, the website must offer an >>>>>>>>>> alternative on the page before the method is called. Much of the >>>>>>>>>> current >>>>>>>>>> design's value is that it allows the page to perform some action >>>>>>>>>> (such as a >>>>>>>>>> navigation) only if this API does not succeed. >>>>>>>>>> >>>>>>>>>> The two proposals can co-exist in the specification, and we >>>>>>>>>> haven't ruled out pursuing Apple's alternative also. They would be >>>>>>>>>> invoked >>>>>>>>>> in different situations. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, Mar 11, 2026 at 11:21 AM Yoav Weiss (@Shopify) < >>>>>>>>>> [email protected]> wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Monday, March 9, 2026 at 7:51:08 PM UTC+1 Alex Russell wrote: >>>>>>>>>>> >>>>>>>>>>> Hey Ken, >>>>>>>>>>> >>>>>>>>>>> It's disappointing to hear that the TAG was trying to litigate >>>>>>>>>>> specific UI choices, rather than helping to guide the API's design. >>>>>>>>>>> As a >>>>>>>>>>> general matter, we should not be specifying *any* explicit UI: >>>>>>>>>>> >>>>>>>>>>> https://infrequently.org/2020/07/why-ui-isnt-specified/ >>>>>>>>>>> >>>>>>>>>>> If we've made that mistake here, it's not too late to change >>>>>>>>>>> course (although it's reasonable to leave non-normative "for >>>>>>>>>>> instance" >>>>>>>>>>> examples and Explainer illustrations). If we didn't, then I'm >>>>>>>>>>> inclined to >>>>>>>>>>> suggest that we have a conversation with our friends on the TAG >>>>>>>>>>> about the >>>>>>>>>>> opportunities for UI treatments that APIs provide vs. requirements. >>>>>>>>>>> As I >>>>>>>>>>> understand your API, an explicit form treatment is still possible >>>>>>>>>>> in any UI >>>>>>>>>>> that prefers that. Is that wrong? >>>>>>>>>>> >>>>>>>>>>> Best, >>>>>>>>>>> >>>>>>>>>>> Alex >>>>>>>>>>> >>>>>>>>>>> On Thursday, March 5, 2026 at 11:34:59 AM UTC-8 Ken Buchanan >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> *Contact emails* >>>>>>>>>>> [email protected], [email protected] >>>>>>>>>>> >>>>>>>>>>> *Explainer* >>>>>>>>>>> https://github.com/w3c/webauthn/wiki/Explainer:-WebAuthn- >>>>>>>>>>> immediate-mediation >>>>>>>>>>> >>>>>>>>>>> *Specification* >>>>>>>>>>> https://github.com/w3c/webauthn/pull/2291 >>>>>>>>>>> >>>>>>>>>>> *Design docs* >>>>>>>>>>> >>>>>>>>>>> https://github.com/w3c/webauthn/wiki/Explainer:-WebAuthn- >>>>>>>>>>> immediate-mediation >>>>>>>>>>> >>>>>>>>>>> *Summary* >>>>>>>>>>> A new mode for navigator.credentials.get() that causes browser >>>>>>>>>>> sign-in UI to be displayed to the user if there is a passkey or >>>>>>>>>>> password >>>>>>>>>>> for the site that is immediately known to the browser, or else >>>>>>>>>>> rejects the >>>>>>>>>>> promise with NotAllowedError if there is no such credential >>>>>>>>>>> available. This >>>>>>>>>>> allows the site to avoid showing a sign-in page if the browser can >>>>>>>>>>> offer a >>>>>>>>>>> choice of sign-in credentials that are likely to succeed, while >>>>>>>>>>> still >>>>>>>>>>> allowing a traditional sign-in page flow for cases where there are >>>>>>>>>>> no such >>>>>>>>>>> credentials. >>>>>>>>>>> >>>>>>>>>>> *Blink component* >>>>>>>>>>> Blink>WebAuthentication >>>>>>>>>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EWebAuthentication%22> >>>>>>>>>>> >>>>>>>>>>> *Web Feature ID* >>>>>>>>>>> webauthn <https://webstatus.dev/features/webauthn> >>>>>>>>>>> >>>>>>>>>>> *Motivation* >>>>>>>>>>> Most sign-in experiences on the web use sign-in pages that offer >>>>>>>>>>> multiple options for accessing an account, such as >>>>>>>>>>> username/password input >>>>>>>>>>> fields, federated sign-in buttons, and sometimes explicit WebAuthn >>>>>>>>>>> or >>>>>>>>>>> passkey buttons. When the browser is aware of passkeys or passwords >>>>>>>>>>> that >>>>>>>>>>> the user has for the site, this API mode makes the sign-in page >>>>>>>>>>> unnecessary >>>>>>>>>>> by instead showing simple browser account selection UI when the >>>>>>>>>>> user begins >>>>>>>>>>> a sign-in attempt. Signing in with this flow reduces friction and >>>>>>>>>>> avoids >>>>>>>>>>> user confusion from having to remember which sign-in option they >>>>>>>>>>> have used >>>>>>>>>>> previously on a given site. The main difference between this and >>>>>>>>>>> current >>>>>>>>>>> modal WebAuthn sign-in UI is that for users without any such >>>>>>>>>>> credentials, >>>>>>>>>>> no browser UI will be shown, and their sign-in experience will be >>>>>>>>>>> unchanged >>>>>>>>>>> from what it is today (typically, a navigation to the site's >>>>>>>>>>> sign-in page). >>>>>>>>>>> >>>>>>>>>>> *Initial public proposal* >>>>>>>>>>> https://github.com/w3c/webauthn/issues/2228 >>>>>>>>>>> >>>>>>>>>>> *TAG review* >>>>>>>>>>> https://github.com/w3ctag/design-reviews/issues/1092 >>>>>>>>>>> >>>>>>>>>>> TAG has closed its review with unsatisfied on the basis that >>>>>>>>>>> they do not believe a modal browser dialog is preferable to a form >>>>>>>>>>> for user >>>>>>>>>>> sign-in experiences. There was extensive discussion of this topic >>>>>>>>>>> on both >>>>>>>>>>> the TAG review issue and the WebAuthn WG issue. >>>>>>>>>>> >>>>>>>>>>> This conflicts with the feedback we have received from >>>>>>>>>>> developers of major relying parties who believe this enables them >>>>>>>>>>> to build >>>>>>>>>>> meaningfully better user experiences. They believe that a modal >>>>>>>>>>> dialog that >>>>>>>>>>> appears only when passkeys are available will be more successful >>>>>>>>>>> for users >>>>>>>>>>> attempting to sign in. Additionally, achieving the goal of signing >>>>>>>>>>> in a >>>>>>>>>>> user while keeping them in the current page context is very >>>>>>>>>>> difficult with >>>>>>>>>>> the current API. >>>>>>>>>>> >>>>>>>>>>> Apple has stated that it supports the goals of this mode, but >>>>>>>>>>> has objected on a different basis from TAG. It favors an >>>>>>>>>>> alternative API >>>>>>>>>>> form that it believes will have better privacy properties ( >>>>>>>>>>> https://github.com/w3c/webauthn/issues/2228#issuecomment- >>>>>>>>>>> 3443764943). Notably, Apple's proposal and Immediate mode would >>>>>>>>>>> be invoked in different situations, and are not mutually exclusive. >>>>>>>>>>> >>>>>>>>>>> Since Immediate mode does not guarantee that UI will be shown on >>>>>>>>>>> invocation, we maintain flexibility to tweak this later in ways >>>>>>>>>>> that limit >>>>>>>>>>> its use. >>>>>>>>>>> >>>>>>>>>>> *TAG review status* >>>>>>>>>>> Issues addressed >>>>>>>>>>> >>>>>>>>>>> *Origin Trial Name* >>>>>>>>>>> Immediate Mediation for Passkeys and Passwords >>>>>>>>>>> >>>>>>>>>>> *Chromium Trial Name* >>>>>>>>>>> WebAuthenticationImmediateGet >>>>>>>>>>> >>>>>>>>>>> *Origin Trial documentation link* >>>>>>>>>>> https://github.com/w3c/webauthn/wiki/Explainer:-WebAuthn- >>>>>>>>>>> immediate-mediation >>>>>>>>>>> >>>>>>>>>>> *WebFeature UseCounter name* >>>>>>>>>>> kCredentialsGetImmediateMediationWithWebAuthnAndPasswords >>>>>>>>>>> >>>>>>>>>>> *Risks* >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> *Interoperability and Compatibility* >>>>>>>>>>> *Gecko*: No signal (https://github.com/moz >>>>>>>>>>> illa/standards-positions/issues/1239) >>>>>>>>>>> >>>>>>>>>>> *WebKit*: Negative (https://github.com/W >>>>>>>>>>> ebKit/standards-positions/issues/504) Feedback is on the WG >>>>>>>>>>> issue: https://github.com/w3c/webauthn/issues/2228#issuecomm >>>>>>>>>>> ent-3443764943 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Naively reading through WebKit folks' feedback, they seem >>>>>>>>>>> supportive of the use case, but interested in a different shape >>>>>>>>>>> that won't >>>>>>>>>>> expose the presence of the passkey to the site. >>>>>>>>>>> Is there a chance to converge here? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> *Web developers*: Positive (https://github.com/w >>>>>>>>>>> 3c/webauthn/issues/2228#issuecomment-3999513181) >>>>>>>>>>> >>>>>>>>>>> *Other signals*: >>>>>>>>>>> >>>>>>>>>>> *WebView application risks* >>>>>>>>>>> >>>>>>>>>>> Does this intent deprecate or change behavior of existing APIs, >>>>>>>>>>> such that it has potentially high risk for Android WebView-based >>>>>>>>>>> applications? >>>>>>>>>>> *No information provided* >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> *Debuggability* >>>>>>>>>>> *No information provided* >>>>>>>>>>> >>>>>>>>>>> *Will this feature be supported on all six Blink platforms >>>>>>>>>>> (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?* >>>>>>>>>>> Yes >>>>>>>>>>> >>>>>>>>>>> *Is this feature fully tested by web-platform-tests >>>>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* >>>>>>>>>>> Yes >>>>>>>>>>> https://wpt.fyi/results/webauthn/getcredential-ui-mode- >>>>>>>>>>> immediate.https.html?label=master&label=experimental& >>>>>>>>>>> aligned&q=getcredential-ui-mode-immediate.https.html >>>>>>>>>>> >>>>>>>>>>> *DevTrial instructions* >>>>>>>>>>> https://docs.google.com/document/d/18iV5eUBM4NVoNx0gqPSxPyJA >>>>>>>>>>> jPdrfIR75vcMDBewzZU/edit?tab=t.0#heading=h.uj0x12ysuohk >>>>>>>>>>> >>>>>>>>>>> *Flag name on about://flags* >>>>>>>>>>> web-authentication-immediate-get >>>>>>>>>>> >>>>>>>>>>> *Finch feature name* >>>>>>>>>>> WebAuthenticationImmediateGet >>>>>>>>>>> >>>>>>>>>>> *Rollout plan* >>>>>>>>>>> Will ship enabled for all users >>>>>>>>>>> >>>>>>>>>>> *Requires code in //chrome?* >>>>>>>>>>> True >>>>>>>>>>> >>>>>>>>>>> *Tracking bug* >>>>>>>>>>> https://issues.chromium.org/issues/408002783 >>>>>>>>>>> >>>>>>>>>>> *Launch bug* >>>>>>>>>>> https://launch.corp.google.com/launch/4394539 >>>>>>>>>>> >>>>>>>>>>> *Measurement* >>>>>>>>>>> Use counters: >>>>>>>>>>> CredentialsGetImmediateMediationWithWebAuthnAndPasswords >>>>>>>>>>> CredentialsGetImmediateMediationWithWebAuthnOnly >>>>>>>>>>> CredentialsGetImmediateMediationWithPasswordsOnly We are also >>>>>>>>>>> tracking user interactions with the modal UI that will be shown >>>>>>>>>>> when this >>>>>>>>>>> is used. >>>>>>>>>>> >>>>>>>>>>> *Estimated milestones* >>>>>>>>>>> Shipping on desktop147Origin trial desktop first139Origin trial >>>>>>>>>>> desktop last141Origin trial extension 1 end milestone144DevTrial >>>>>>>>>>> on desktop136Shipping on Android147DevTrial on Android142Shipping >>>>>>>>>>> on WebView147 >>>>>>>>>>> >>>>>>>>>>> *Link to entry on the Chrome Platform Status* >>>>>>>>>>> https://chromestatus.com/feature/5164322780872704?gate=51770 >>>>>>>>>>> 75746734080 >>>>>>>>>>> >>>>>>>>>>> *Links to previous Intent discussions* >>>>>>>>>>> Intent to Prototype: https://groups.goog >>>>>>>>>>> le.com/a/chromium.org/d/msgid/blink-dev/CALjHGKrQEs4TDzuzb%3 >>>>>>>>>>> D0B00S4OmkE4a1NbZGi19sCueTKvN_m9w%40mail.gmail.com >>>>>>>>>>> Ready for Trial: https://groups.google.c >>>>>>>>>>> om/a/chromium.org/g/blink-dev/c/zC13ioLIZ_E/m/P-P6B6gNCQAJ >>>>>>>>>>> Intent to Experiment: https://groups.goo >>>>>>>>>>> gle.com/a/chromium.org/d/msgid/blink-dev/CALjHGKpJkA9G6De6D4 >>>>>>>>>>> %3DRNSbLMRdy8Yfa6B%3DgDNWeqTyHfv8sSg%40mail.gmail.com >>>>>>>>>>> Intent to Extend Experiment 1: https://groups.google.com/a >>>>>>>>>>> /chromium.org/d/msgid/blink-dev/CALjHGKpLbqYVnSMfNgxh45TSbP9 >>>>>>>>>>> j6AU2JvLWow%3DH1ihr5v%2Bj0A%40mail.gmail.com >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> This intent message was generated by Chrome Platform Status >>>>>>>>>>> <https://chromestatus.com/>. >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>> 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 visit >>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALjHGKoR0EskBNkLxcaRRO0wtfGe-0po0mxnFH_VhSnpFt49Zw%40mail.gmail.com >>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALjHGKoR0EskBNkLxcaRRO0wtfGe-0po0mxnFH_VhSnpFt49Zw%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 visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALjHGKqq%3DfM%2BYc%2BQeQDfPviifs%2BEcUwyw_Q3UKDgmKNF0NxR1A%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALjHGKqq%3DfM%2BYc%2BQeQDfPviifs%2BEcUwyw_Q3UKDgmKNF0NxR1A%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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY8_t7fYRYtfPGVhqm81ipEoqX7hq8bB2i%3DXO8x0hnB_iA%40mail.gmail.com.
