Intent to Extend Experiment: Local network access restrictions

[Chromestatus]

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

Design docs

https://github.com/explainers-by-googlers/local-network-access
https://docs.google.com/document/d/1n0kKxt9pS9qDlu_9i5W8IXA594r4pUOKmN9H35cZ8j0/edit?usp=sharing

Summary

Chrome 142 restricted 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 (for example, 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](https://chromestatus.com/feature/5737414355058688), which used preflight requests to have local devices opt-in. For more information on this feature, see [Adapting your website for new Local Network Access restrictions in Chrome](https://docs.google.com/document/d/1QQkqehw8umtAgz5z0um7THx-aoU251p705FbIQjDuGs/edit?usp=sharing). <br> Chrome 145 introduces more granular permissions for websites requesting access to a user's local network. The previous single `local-network-access permission` is being split into two distinct permissions: * `local-network`: Grants access to IP addresses in the local network space (for example, intranets, internal devices). * `loopback-network`: Grants access to loopback IP addresses (for example., `localhost`, `127.0.0.1`). The old `local-network` permission will remain as an alias, ensuring existing configurations and Permissions Policies continue to function as expected. This change provides both users and Admins with more precise control over how websites interact with internal network resources. Current enterprise policies managing local network access will not be affected by this change.

Blink component

Blink>SecurityFeature>LocalNetworkAccess

Web Feature ID

local-network-access

TAG review

https://github.com/w3ctag/design-reviews/issues/1116

TAG review status

Issues addressed

Origin Trial Name

Local Network Access from Non-Secure Contexts

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 (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. 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, 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?

No information provided

Goals for experimentation

No information provided

Reason this experiment is being extended

Launch of Local Network Access restrictions for WebSockets has been delayed from M144 to M147 due to holidays and enterprise concerns. We'd like to push back the end date of this origin trial to allow for those running WebSockets on HTTP endpoints currently to opt out of the secure context restrictions for a period of time while they migrate to a secure context

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?

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

Launch bug

https://launch.corp.google.com/launch/4395658

Estimated milestones

Shipping on desktop	142
Origin trial desktop first	141
Origin trial desktop last	146
Origin trial extension 1 end milestone	152
DevTrial on desktop	138
Shipping on Android	142
Origin trial Android first	141
Origin trial Android last	146
DevTrial on Android	139
Rollout step 1	152
Rollout step 2	147
Rollout step 3	145

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5152728072060928?gate=5186662093160448

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
Intent to Ship: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALMy46R%3DBq1orEwZUxfXg71hpJfcgV%3DUtsFUC7AiiMjA8f6_5A%40mail.gmail.com

This intent message was generated by Chrome Platform Status.