Thanks for all the detailed explanations. LGTM2. On Wed, Sep 3, 2025 at 8:48 AM Chris Thompson <[email protected]> wrote:
> *To Vlad's questions:* > > > - I assume direct navigation to a local network is fine and remains > without permission? (like navigating to your router's settings page) > > Correct, main frame navigations are not currently in scope. > > > - By "secure context", you mean that the page which wants to access > local network has to be secure. Is that right? > > Yes, to be granted the permission the requesting page must be a secure > context. > > > - What's the behavior of local file (file://) accessing local network? > > This is somewhat weakly specified currently (file:// URLs are weird in > general), but Chromium's behavior is to treat them the same as > http://localhost/ and thus not subject to LNA restrictions. > > *To Daniel's question:* > > > 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? > > Certain requests would fail due to the combination of the LNA permission > requiring secure contexts and mixed content blocking. > > The main case that breaks is a public site making a request to > http://a.example, which *resolves* to a local IP address (or the loopback > address). Today, that site could be on HTTP to avoid having these requests > blocked as mixed content. With LNA, the site must be on HTTPS to request > the permission, *but* the browser can't know that these subresource > requests are until after we've resolved the hostname (which occurs *after* > mixed > content blocking). > > For fetch() calls, we have the `targetAddressSpace` option for > pre-specifying that requests like this are to the local network, and thus > we can exempt them from mixed content blocking. This may require some > slight modifications to existing sites to add the flag to any affected > fetch() calls to avoid breakage. > > The reverse OT helps give a temporary escape hatch here, to give sites > more time to adapt (such as adding `targetAddressSpace` flags, migrating to > HTTPS, etc.). We plan to follow up with any sites that enroll in the OT to > try to see if there are additional affordances we could add to the spec and > our implementation to help address why they can't migrate to HTTPS yet. > > On Wed, Sep 3, 2025 at 8:35 AM Daniel Bratell <[email protected]> wrote: > >> 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 >>>>> >>>>> 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/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/CALMy46SACi%2B3kGz_sQUfYxK9ucSjp0GMzKNyVgPip5mynf4nAg%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALMy46SACi%2B3kGz_sQUfYxK9ucSjp0GMzKNyVgPip5mynf4nAg%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 [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8SK69gpEaZ7GZcvb6nzAmd5sDKR3UzRHvtJ1MNexryxg%40mail.gmail.com.
