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 >>> >>> cth...@chromium.org >>> >>> 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 blink-dev+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8863a050-972e-4d00-9960-b4dc6436b013n%40chromium.org.
