Reading the issue, it looks like they've figured out the issue, which involves iframes and permission policies.
In case there are others still having issues, we've written an adoption guide <https://docs.google.com/document/d/1QQkqehw8umtAgz5z0um7THx-aoU251p705FbIQjDuGs/edit?usp=sharing> (which the MSAL authors referenced) that will hopefully help answer many, if not all questions. /hubert On Tuesday, November 4, 2025 at 8:57:58 AM UTC-5 Tim Abbott wrote: > Just flagging that the rollout of this feature in Chrome 142 has impacted > MSAL re-authentication for internal web apps. See > https://github.com/azuread/microsoft-authentication-library-for-js/issues/8100 > > > On Tuesday, 30 September 2025 at 03:44:02 UTC+1 Chris Thompson wrote: > >> A quick update: We have decided to delay our launch by one milestone due >> to a bug that could break certain captive portals on Android ( >> crbug.com/448107420). We are now targeting M142 for our full launch. >> This small delay should also help affected sites have a bit more time to >> adapt to the new permission prompt. >> >> On Wed, Sep 3, 2025 at 3:34 PM Vladimir Levin <[email protected]> >> wrote: >> > LGTM3 >>> >>> Thanks, >>> Vlad >>> >>> On Wed, Sep 3, 2025, 12:58 p.m. Chris Harrelson <[email protected]> >>> wrote: >>> >> Thanks for all the detailed explanations. LGTM2. >>>> >>>> On Wed, Sep 3, 2025 at 8:48 AM Chris Thompson <[email protected]> >>>> wrote: >>>> >>> *To Vlad's questions:* >>>>> >>>>> > - I assume direct navigation to a local network is fine and remains >>>>> without permission? (like navigating to your router's settings page) >>>>> >>>>> Correct, main frame navigations are not currently in scope. >>>>> >>>>> > - By "secure context", you mean that the page which wants to access >>>>> local network has to be secure. Is that right? >>>>> >>>>> Yes, to be granted the permission the requesting page must be a secure >>>>> context. >>>>> >>>>> > - What's the behavior of local file (file://) accessing local >>>>> network? >>>>> >>>>> This is somewhat weakly specified currently (file:// URLs are weird in >>>>> general), but Chromium's behavior is to treat them the same as >>>>> http://localhost/ and thus not subject to LNA restrictions. >>>>> >>>>> *To Daniel's question:* >>>>> >>>>> > I don't quite understand how these people are affected. Will >>>>> something break for them, or open up for them? If something breaks, how >>>>> badly does it break? Or is it something that we want to break? >>>>> >>>>> Certain requests would fail due to the combination of the LNA >>>>> permission requiring secure contexts and mixed content blocking. >>>>> >>>>> The main case that breaks is a public site making a request to >>>>> http://a.example, which *resolves* to a local IP address (or the >>>>> loopback address). Today, that site could be on HTTP to avoid having >>>>> these >>>>> requests blocked as mixed content. With LNA, the site must be on HTTPS to >>>>> request the permission, *but* the browser can't know that these >>>>> subresource requests are until after we've resolved the hostname (which >>>>> occurs *after* mixed content blocking). >>>>> >>>>> For fetch() calls, we have the `targetAddressSpace` option for >>>>> pre-specifying that requests like this are to the local network, and thus >>>>> we can exempt them from mixed content blocking. This may require some >>>>> slight modifications to existing sites to add the flag to any affected >>>>> fetch() calls to avoid breakage. >>>>> >>>>> The reverse OT helps give a temporary escape hatch here, to give sites >>>>> more time to adapt (such as adding `targetAddressSpace` flags, migrating >>>>> to >>>>> HTTPS, etc.). We plan to follow up with any sites that enroll in the OT >>>>> to >>>>> try to see if there are additional affordances we could add to the spec >>>>> and >>>>> our implementation to help address why they can't migrate to HTTPS yet. >>>>> >>>>> On Wed, Sep 3, 2025 at 8:35 AM Daniel Bratell <[email protected]> >>>>> wrote: >>>>> >>>> In addition to Vlad's questions, I have one question about this line in >>>>>> the Compat section: >>>>>> >>>>>> > Based on our UseCounter >>>>>> PrivateNetworkAccessInsecureResourceNotKnownPrivate, we currently >>>>>> estimate >>>>>> an upper bound of 0.004% of page loads may make local network requests >>>>>> which would currently run afoul of mixed content blocking despite the >>>>>> exceptions we have added. >>>>>> >>>>>> I don't quite understand how these people are affected. Will >>>>>> something break for them, or open up for them? If something breaks, how >>>>>> badly does it break? Or is it something that we want to break? >>>>>> >>>>>> /Daniel >>>>>> >>>>>> >>>>>> On 2025-09-03 17:29, Vladimir Levin wrote: >>>>>> >>>>> Hey, I just wanted to clarify a couple of use cases: >>>>>> >>>>>> - I assume direct navigation to a local network is fine and remains >>>>>> without permission? (like navigating to your router's settings page) >>>>>> - By "secure context", you mean that the page which wants to access >>>>>> local network has to be secure. Is that right? >>>>>> - What's the behavior of local file (file://) accessing local >>>>>> network? >>>>>> >>>>>> Thanks, >>>>>> Vlad >>>>>> >>>>>> On Wednesday, September 3, 2025 at 10:23:02 AM UTC-4 Alex Russell >>>>>> wrote: >>>>>> >>>>>> Sorry, failed to spot the long discussion in Considered Alternatives >>>>>>> in the Explainer. Thanks for putting it all down there. >>>>>>> >>>>>>> LGTM1 >>>>>>> >>>>>>> On Wednesday, September 3, 2025 at 3:20:54 PM UTC+1 Alex Russell >>>>>>> wrote: >>>>>>> >>>>>> Is there a document that summarises why Private Network Access was >>>>>>>> abandoned? And was there any discussion of explicit API for this? >>>>>>>> >>>>>>>> Best, >>>>>>>> >>>>>>>> Alex >>>>>>>> >>>>>>>> On Wednesday, September 3, 2025 at 12:32:02 AM UTC+1 Chris Thompson >>>>>>>> wrote: >>>>>>>> >>>>>>> Contact emails >>>>>>>>> >>>>>>>>> [email protected] >>>>>>>>> >>>>>>>> >>>>>>>>> Explainer >>>>>>>>> >>>>>>>>> https://github.com/WICG/local-network-access/blob/main/explainer.md >>>>>>>>> >>>>>>>>> Specification >>>>>>>>> >>>>>>>>> https://wicg.github.io/local-network-access >>>>>>>>> >>>>>>>>> Summary >>>>>>>>> >>>>>>>>> Chrome 141 restricts the ability for sites to make requests to the >>>>>>>>> user's local network, gated behind a permission prompt. >>>>>>>>> >>>>>>>>> A local network request is any request from a public website to a >>>>>>>>> local IP address or loopback, or from a local website (e.g. intranet) >>>>>>>>> to >>>>>>>>> loopback. Gating the ability for websites to perform these requests >>>>>>>>> behind >>>>>>>>> a permission mitigates the risk of cross-site request forgery attacks >>>>>>>>> against local network devices such as routers, and reduces the >>>>>>>>> ability of >>>>>>>>> sites to use these requests to fingerprint the user's local network. >>>>>>>>> >>>>>>>>> This permission is restricted to secure contexts. If granted, the >>>>>>>>> permissions additionally relaxes mixed content blocking for local >>>>>>>>> network >>>>>>>>> requests (since many local devices are not able to obtain publicly >>>>>>>>> trusted >>>>>>>>> TLS certificates). Requests from insecure contexts will be silently >>>>>>>>> rejected. Sites may temporarily opt-out of the secure contexts >>>>>>>>> restriction >>>>>>>>> using the reverse origin trial “Local Network Access from >>>>>>>>> Non-Secure Contexts >>>>>>>>> <https://developer.chrome.com/origintrials/#/view_trial/3826370833404657665>”, >>>>>>>>> >>>>>>>>> included in this launch. >>>>>>>>> >>>>>>>>> This initial version of Local Network Access (LNA) applies to >>>>>>>>> subresource requests, fetch() requests, and navigating subframes. In >>>>>>>>> the >>>>>>>>> near future we plan to send a separate Intent-to-Ship for applying >>>>>>>>> LNA to >>>>>>>>> WebSockets, WebTransport, and WebRTC connections. >>>>>>>>> >>>>>>>>> This work supersedes a prior effort called "Private Network >>>>>>>>> Access" (e.g., https://chromestatus.com/feature/5737414355058688, >>>>>>>>> https://chromestatus.com/feature/5954091755241472) which used >>>>>>>>> preflight requests to allow local devices to opt-in to receiving >>>>>>>>> requests. >>>>>>>>> >>>>>>>>> Enterprises that need to disable or auto-grant the permission can >>>>>>>>> do so using the LocalNetworkAccessAllowedForUrls >>>>>>>>> <https://chromeenterprise.google/policies/#LocalNetworkAccessAllowedForUrls> >>>>>>>>> >>>>>>>>> and LocalNetworkAccessBlockedForUrls >>>>>>>>> <https://chromeenterprise.google/policies/#LocalNetworkAccessBlockedForUrls> >>>>>>>>> >>>>>>>>> policies. The value of '*' can be used to allow local network access >>>>>>>>> on all >>>>>>>>> URLs, matching the behavior prior to rolling out the restrictions. At >>>>>>>>> launch, the policies can be set using custom configurations >>>>>>>>> <https://support.google.com/chrome/a/answer/14749672>. >>>>>>>>> >>>>>>>>> >>>>>>>>> Blink component >>>>>>>>> >>>>>>>>> Blink>SecurityFeature>LocalNetworkAccess >>>>>>>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ESecurityFeature%3ELocalNetworkAccess%22> >>>>>>>>> >>>>>>>>> TAG review >>>>>>>>> >>>>>>>>> https://github.com/w3ctag/design-reviews/issues/1116 >>>>>>>>> >>>>>>>>> TAG review status >>>>>>>>> >>>>>>>>> Issues addressed (satisfied with concerns) >>>>>>>>> >>>>>>>>> Origin Trial Name >>>>>>>>> >>>>>>>>> Local Network Access from Non-Secure Contexts >>>>>>>>> <https://developer.chrome.com/origintrials/#/view_trial/3826370833404657665> >>>>>>>>> >>>>>>>>> Chromium Trial Name >>>>>>>>> >>>>>>>>> LocalNetworkAccessNonSecureContextAllowed >>>>>>>>> >>>>>>>>> Origin Trial documentation link >>>>>>>>> >>>>>>>>> https://developer.chrome.com/blog/local-network-access >>>>>>>>> >>>>>>>>> Risks >>>>>>>>> >>>>>>>>> Interoperability and Compatibility >>>>>>>>> >>>>>>>>> Interoperability risks: >>>>>>>>> >>>>>>>>> LNA requires a Secure Context to make local network requests, but >>>>>>>>> exempts some of these local network requests from mixed content >>>>>>>>> checks (if >>>>>>>>> the user grants permission). If another browser does not implement >>>>>>>>> LNA, >>>>>>>>> these same local network requests might be blocked as mixed content, >>>>>>>>> or the >>>>>>>>> site might need to serve over HTTPS for Chrome and over HTTP for >>>>>>>>> browsers >>>>>>>>> that don't implement LNA (to avoid triggering mixed content). >>>>>>>>> >>>>>>>>> Compatibility risks: >>>>>>>>> >>>>>>>>> There are some local network requests types that we cannot know >>>>>>>>> ahead of time will be going to the local network (e.g., a subresource >>>>>>>>> request to http://test.example which then resolves to >>>>>>>>> 192.168.0.1). These would be blocked as mixed content, as mixed >>>>>>>>> content >>>>>>>>> checks happen before hostname resolution (i.e., they occur before >>>>>>>>> "Obtain a >>>>>>>>> connection" in Fetch). Explicit local IP addresses, .local >>>>>>>>> domains, and fetch() requests with the new `targetAddressSpace` >>>>>>>>> fetch() >>>>>>>>> option are exempted from mixed content checks, but other connection >>>>>>>>> types >>>>>>>>> may be difficult for developers to work around mixed content blocking >>>>>>>>> (e.g., WebSockets wicg/local-network-access#16 >>>>>>>>> <https://github.com/wicg/local-network-access/issues/16>). >>>>>>>>> >>>>>>>>> Alongside shipping these restrictions we are running a reverse >>>>>>>>> origin trial to allow sites to (temporarily) opt-out of the secure >>>>>>>>> contexts >>>>>>>>> requirement -- this would be an escape hatch for mixed content. This >>>>>>>>> origin >>>>>>>>> trial can only be enabled through origin tokens delivered via HTTP >>>>>>>>> header >>>>>>>>> due the trial affecting the security policy of the document being >>>>>>>>> loaded. >>>>>>>>> >>>>>>>>> We have previously run a Dev Trial and a 50% Finch experiment on >>>>>>>>> Canary/Dev/Beta which helped alert potentially affected developers >>>>>>>>> and find >>>>>>>>> some bugs early before shipping. Based in part on questions from >>>>>>>>> affected >>>>>>>>> developers we have put together an “LNA Adoption Guide >>>>>>>>> <https://docs.google.com/document/d/1QQkqehw8umtAgz5z0um7THx-aoU251p705FbIQjDuGs/edit?usp=sharing>” >>>>>>>>> >>>>>>>>> to help affected sites adapt to these new restrictions. >>>>>>>>> >>>>>>>>> Based on our UseCounter >>>>>>>>> PrivateNetworkAccessInsecureResourceNotKnownPrivate >>>>>>>>> <https://chromestatus.com/metrics/feature/timeline/popularity/5319>, >>>>>>>>> we currently estimate an upper bound of 0.004% of page loads may make >>>>>>>>> local >>>>>>>>> network requests which would currently run afoul of mixed content >>>>>>>>> blocking >>>>>>>>> despite the exceptions we have added. >>>>>>>>> >>>>>>>>> >>>>>>>>> Gecko: Under consideration ( >>>>>>>>> https://groups.google.com/a/mozilla.org/g/dev-platform/c/B8oN3ARp_j0/m/rWKXmnj4AAAJ) >>>>>>>>> >>>>>>>>> Firefox is prototyping based on our spec draft. Request for signals: >>>>>>>>> https://github.com/mozilla/standards-positions/issues/1260 >>>>>>>>> >>>>>>>>> WebKit: No signal. Request for signals: >>>>>>>>> https://github.com/WebKit/standards-positions/issues/520 >>>>>>>>> >>>>>>>>> Web developers: Mixed signals ( >>>>>>>>> https://github.com/explainers-by-googlers/local-network-access/issues). >>>>>>>>> >>>>>>>>> Feedback from developers has been mixed, both due the new burden of a >>>>>>>>> permission prompt (compared to PNA) and from some of the difficulty >>>>>>>>> of >>>>>>>>> navigating mixed content (the same as PNA). Many developers >>>>>>>>> understand the >>>>>>>>> reasoning behind adding the new permission though, and are >>>>>>>>> productively >>>>>>>>> engaging on how they can avoid issues. >>>>>>>>> >>>>>>>>> Other signals: Brave ships a "localhost access" permission (see >>>>>>>>> https://brave.com/privacy-updates/27-localhost-permission/) >>>>>>>>> >>>>>>>>> Ergonomics >>>>>>>>> >>>>>>>>> N/A >>>>>>>>> >>>>>>>>> >>>>>>>>> Activation >>>>>>>>> >>>>>>>>> A new permission will be shown to users, which may be unexpected. >>>>>>>>> If users deny the permission, functionality may break (potentially >>>>>>>>> requiring additional support from site owners). Part of our goal for >>>>>>>>> having >>>>>>>>> a Dev Trial was to give site owners time to adjust their requests >>>>>>>>> (especially if they need to use the mixed content exemptions) and to >>>>>>>>> potentially adapt their UX flows so the permission requests are less >>>>>>>>> surprising to users. We have collected some advice for how sites can >>>>>>>>> adapt >>>>>>>>> to these new restrictions in our “LNA Adoption Guide >>>>>>>>> <https://docs.google.com/document/d/1QQkqehw8umtAgz5z0um7THx-aoU251p705FbIQjDuGs/edit?usp=sharing> >>>>>>>>> ”. >>>>>>>>> >>>>>>>>> >>>>>>>>> Security >>>>>>>>> >>>>>>>>> Exempting some requests from mixed content checks based on >>>>>>>>> declared targetAddressSpace could potentially be used to arbitrarily >>>>>>>>> bypass >>>>>>>>> mixed content. To avoid this, Chrome verifies that the actual >>>>>>>>> resolved >>>>>>>>> address space matches what was declared, and blocks the request if it >>>>>>>>> does >>>>>>>>> not. >>>>>>>>> >>>>>>>>> >>>>>>>>> WebView application risks >>>>>>>>> >>>>>>>>> These restrictions do not apply to WebView (see below). >>>>>>>>> >>>>>>>>> >>>>>>>>> Debuggability >>>>>>>>> >>>>>>>>> When a request would be blocked under LNA, we add a new DevTools >>>>>>>>> Issue with details. >>>>>>>>> >>>>>>>>> >>>>>>>>> Will this feature be supported on all six Blink platforms >>>>>>>>> (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)? >>>>>>>>> >>>>>>>>> No >>>>>>>>> >>>>>>>>> Android WebView currently doesn't support letting apps grant any >>>>>>>>> new permission types, so the Local Network Access permission is >>>>>>>>> currently >>>>>>>>> unconditionally granted in WebView. In parallel to this effort, >>>>>>>>> Android is >>>>>>>>> adding a Local Network permission which would apply to the app that >>>>>>>>> embeds >>>>>>>>> the WebView >>>>>>>>> https://developer.android.com/privacy-and-security/local-network-permission >>>>>>>>> >>>>>>>>> >>>>>>>>> Is this feature fully tested by web-platform-tests >>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>>>>> ? >>>>>>>>> >>>>>>>>> No >>>>>>>>> >>>>>>>>> We have coverage of core aspects of the feature in WPTs and are >>>>>>>>> actively working on building out the test suite >>>>>>>>> https://wpt.fyi/results/fetch/local-network-access >>>>>>>>> <https://wpt.fyi/results/fetch/local-network-access>. We have >>>>>>>>> additional testing coverage in Chromium browser tests, particularly >>>>>>>>> for >>>>>>>>> areas that are difficult to write WPTs for. >>>>>>>>> >>>>>>>>> >>>>>>>>> DevTrial instructions >>>>>>>>> >>>>>>>>> https://developer.chrome.com/blog/local-network-access >>>>>>>>> >>>>>>>>> Flag name on about://flags >>>>>>>>> >>>>>>>>> local-network-access-check >>>>>>>>> >>>>>>>>> Finch feature name >>>>>>>>> >>>>>>>>> LocalNetworkAccessChecks >>>>>>>>> >>>>>>>>> Rollout plan >>>>>>>>> >>>>>>>>> Will ship enabled for all users >>>>>>>>> >>>>>>>>> Requires code in //chrome? >>>>>>>>> >>>>>>>>> True >>>>>>>>> >>>>>>>>> Tracking bug >>>>>>>>> >>>>>>>>> https://crbug.com/394009026 >>>>>>>>> >>>>>>>>> Launch bug >>>>>>>>> >>>>>>>>> https://launch.corp.google.com/launch/4395658 >>>>>>>>> >>>>>>>>> Sample links >>>>>>>>> >>>>>>>>> https://lna-testing.notyetsecure.com >>>>>>>>> >>>>>>>>> Estimated milestones >>>>>>>>> >>>>>>>>> Shipping on desktop >>>>>>>>> >>>>>>>>> 141 >>>>>>>>> >>>>>>>>> Origin trial desktop first >>>>>>>>> >>>>>>>>> 141 >>>>>>>>> >>>>>>>>> Origin trial desktop last >>>>>>>>> >>>>>>>>> 146 >>>>>>>>> >>>>>>>>> DevTrial on desktop >>>>>>>>> >>>>>>>>> 138 >>>>>>>>> >>>>>>>>> Shipping on Android >>>>>>>>> >>>>>>>>> 141 >>>>>>>>> >>>>>>>>> Origin trial Android first >>>>>>>>> >>>>>>>>> 141 >>>>>>>>> >>>>>>>>> Origin trial Android last >>>>>>>>> >>>>>>>>> 146 >>>>>>>>> >>>>>>>>> DevTrial on Android >>>>>>>>> >>>>>>>>> 139 >>>>>>>>> >>>>>>>>> >>>>>>>>> Anticipated spec changes >>>>>>>>> >>>>>>>>> Open questions about a feature may be a source of future web >>>>>>>>> compat or interop issues. Please list open issues (e.g. links to >>>>>>>>> known >>>>>>>>> github issues in the project for the feature specification) whose >>>>>>>>> resolution may introduce web compat/interop risk (e.g., changing to >>>>>>>>> naming >>>>>>>>> or structure of the API in a non-backward-compatible way). >>>>>>>>> >>>>>>>>> None >>>>>>>>> >>>>>>>>> Link to entry on the Chrome Platform Status >>>>>>>>> >>>>>>>>> >>>>>>>>> https://chromestatus.com/feature/5152728072060928?gate=5199213979500544 >>>>>>>>> >>>>>>>>> Links to previous Intent discussions >>>>>>>>> >>>>>>>>> Intent to Prototype: >>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALMy46SB%2Bv9dnp-wrJ4WH0R4UJmWuutq1st92%3D_zOyhnLJ_vkw%40mail.gmail.com >>>>>>>>> >>>>>>>>> Intent to Experiment: >>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHEiSH03XUPgcAkVmE25PpvDXMsx%3D16Kgeid_KJ8vRgyvueNuA%40mail.gmail.com >>>>>>>>> >>>>>>>>> Ready for Developer Testing: >>>>>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/D4nqAa3FUN8/m/WFVmJYh0BAAJ >>>>>>>>> >>>>>>>>> >>>>>>>>> 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/8863a050-972e-4d00-9960-b4dc6436b013n%40chromium.org >>>>>> >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8863a050-972e-4d00-9960-b4dc6436b013n%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 [email protected]. >>>> >>>> >>>>> To view this discussion visit >>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALMy46SACi%2B3kGz_sQUfYxK9ucSjp0GMzKNyVgPip5mynf4nAg%40mail.gmail.com >>>>> >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALMy46SACi%2B3kGz_sQUfYxK9ucSjp0GMzKNyVgPip5mynf4nAg%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/CAOMQ%2Bw8SK69gpEaZ7GZcvb6nzAmd5sDKR3UzRHvtJ1MNexryxg%40mail.gmail.com >>>> >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8SK69gpEaZ7GZcvb6nzAmd5sDKR3UzRHvtJ1MNexryxg%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/7b889d5b-e86f-461f-97ef-1a9dd7d9a7d3n%40chromium.org.
