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/CALMy46Tp7J%3DtiOyX6XkU%3DHE08zo77eywAjQa%3D8s9EkvPkDGbew%40mail.gmail.com.
