LGTM3 Thanks, Vlad
On Wed, Sep 3, 2025, 12:58 p.m. Chris Harrelson <chris...@chromium.org> wrote: > Thanks for all the detailed explanations. LGTM2. > > On Wed, Sep 3, 2025 at 8:48 AM Chris Thompson <cth...@chromium.org> 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 <bratel...@gmail.com> >> 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 >>>>>> >>>>>> cth...@chromium.org >>>>>> >>>>>> 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 blink-dev+unsubscr...@chromium.org. >>> 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 blink-dev+unsubscr...@chromium.org. >> 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 blink-dev+unsubscr...@chromium.org. > To view this discussion visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8SK69gpEaZ7GZcvb6nzAmd5sDKR3UzRHvtJ1MNexryxg%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8SK69gpEaZ7GZcvb6nzAmd5sDKR3UzRHvtJ1MNexryxg%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/CADsXd2M6ZxH6S996av2zfhipCTBP3DgjKg9BvhB1rSrxm_PgYw%40mail.gmail.com.
