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/6bc2256c-bd4c-4e79-97c8-f3a2c5850790n%40chromium.org.
