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
<https://github.com/WICG/local-network-access/blob/main/explainer.md>
Specification
https://wicg.github.io/local-network-access
<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/5737414355058688>,https://chromestatus.com/feature/5954091755241472
<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
<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
<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 tohttp://test.example
<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, .localdomains, 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
<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
<https://github.com/mozilla/standards-positions/issues/1260>
WebKit: No signal. Request for signals:
https://github.com/WebKit/standards-positions/issues/520
<https://github.com/WebKit/standards-positions/issues/520>
Web developers: Mixed signals
(https://github.com/explainers-by-googlers/local-network-access/issues
<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/
<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
WebViewhttps://developer.android.com/privacy-and-security/local-network-permission
<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
<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 <https://crbug.com/394009026>
Launch bug
https://launch.corp.google.com/launch/4395658
<https://launch.corp.google.com/launch/4395658>
Sample links
https://lna-testing.notyetsecure.com
<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
<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
<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
<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
<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/88058ad2-a5c7-4099-ba17-240836e6bf70%40gmail.com.
