LGTM to experiment via Finch in pre-stable channels. I love the strategy of automatically popping a permission prompt. I'm optimistic we can get this tuned to minimize breakage while maximizing developer predictability and user understandability, but I can totally imagine that it'll take some tuning to get there. Please let us know when you feel confident enough in the data to start experimenting in stable - that'll be a key point in the rollout I believe and probably worthy of some extra discussion on the tradeoffs.
Ensuring users have transparency and control over local network access is important for security and privacy, thank you for working on it! Rick On Tue, Jun 24, 2025 at 4:21 PM Hubert Chao <hc...@chromium.org> wrote: > Note: this is for pre-stable experimentation through Finch, not for an > Origin Trial. > > Contact emails > > cth...@chromium.org > > hc...@chromium.org > > > Explainer > > https://github.com/WICG/local-network-access > > Specification > > > https://docs.google.com/document/d/1n0kKxt9pS9qDlu_9i5W8IXA594r4pUOKmN9H35cZ8j0/edit?tab=t.0 > > Design docs > > https://github.com/explainers-by-googlers/local-network-access > > > https://docs.google.com/document/d/1n0kKxt9pS9qDlu_9i5W8IXA594r4pUOKmN9H35cZ8j0/edit?usp=sharing > > Summary > > Restricts the ability 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 for various reasons). > > 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 have local devices opt-in. > > > Blink component > > Blink>SecurityFeature>CORS>PrivateNetworkAccess > <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ESecurityFeature%3ECORS%3EPrivateNetworkAccess%22> > > TAG review > > https://github.com/w3ctag/design-reviews/issues/1116 > > TAG review status > > Pending > > Origin Trial documentation link > > https://github.com/WICG/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 (e.g., > WebSockets > https://github.com/explainers-by-googlers/local-network-access/issues/16). > > We hope that our Dev Trial will help identify compatibility issues. When > we fully ship we also plan on 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. > > > 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, no formal request for > signals yet > > WebKit: No signal No request for signals yet > > 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, and if > users deny the permission functionality may break (potentially requiring > additional support from site owners). Part of our goal for having a Dev > Trial is 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. > > > Security > > Exempting some requests from mixed content checks based on declared > targetAddressSpace could potentially be used to arbitrarily bypass mixed > content. To avoid this, LNA does an additional check that the actual > resolved address space matches what was declared, and blocks the request if > it does not. > > > WebView application risks > > Does this intent deprecate or change behavior of existing APIs, such that > it has potentially high risk for Android WebView-based applications? > > None > > > Goals for experimentation > > We intend to evaluate implementation of Local Network Access (LNA) through > more widespread testing to ensure that we (a) do not capture any requests > that are not LNA requests, and (b) all request that are LNA are captured > and trigger a permissions check. > > Intending to turn on up to 100% in Chrome Canary/Dev/Beta channel via > Finch. > > Experiment Risks > > There may be false positives (request that are captured as LNA requests > that are not) and false negatives (request that are LNA request that are > not captured). > > There is additional breakage risk with LNA request from non-secure > contexts, as well as mixed-content LNA requests. > > > Ongoing technical constraints > > None > > > 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. Android is separately adding a Local > Network permission which would apply to the app that embeds a 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 started working on building out a test suite but it is still a > work-in-progress. https://wpt.fyi/results/fetch/local-network-access > > > DevTrial instructions > > https://developer.chrome.com/blog/local-network-access > > Flag name on about://flags > > local-network-access-check > > Finch feature name > > LocalNetworkAccessChecks > > Requires code in //chrome? > > True > > Tracking bug > > https://crbug.com/394009026 > > Estimated milestones > > > > > DevTrial on desktop > > 138 > > > > > DevTrial on Android > > 139 > > > Link to entry on the Chrome Platform Status > > https://chromestatus.com/feature/5152728072060928 > > 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 > > Ready For Developer Testing: > > > https://groups.google.com/a/chromium.org/g/blink-dev/c/D4nqAa3FUN8/m/WFVmJYh0BAAJ > > -- > 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/CAHEiSH03XUPgcAkVmE25PpvDXMsx%3D16Kgeid_KJ8vRgyvueNuA%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHEiSH03XUPgcAkVmE25PpvDXMsx%3D16Kgeid_KJ8vRgyvueNuA%40mail.gmail.com?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 blink-dev+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9eF3RGQ65ov_peGHE__L9iCNutzVfckZYKwm0xzqzJkg%40mail.gmail.com.
