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/70c8ea43-18cf-4f1e-89ac-dc83112ad87dn%40chromium.org.
