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/decd3b4a-b5e6-4968-bdf8-60437ce60f53n%40chromium.org.
