*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.
