Intent to Prototype: Local network access restrictions

[Chris Thompson]

Contact emails

cth...@chromium.org

Explainer

https://github.com/explainers-by-googlers/local-network-access

Specification

Not yet

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>PrivateNetworkAccess

Motivation

Currently public websites can probe a user's local network, perform CSRF attacks against vulnerable local devices, and generally abuse the user's browser as a "confused deputy" that has access inside the user's local network or software on their local machine. Gating the ability for sites to make local network requests behind a permission prompt helps stop the exploitation of vulnerable devices and servers from the drive-by-web, and gives users control over which sites can probe their local network.

Initial public proposal

https://github.com/WICG/proposals/issues/198

TAG review

Not yet

TAG review status

Not yet requested

Risks

Interoperability and Compatibility

Restricting local network requests behind a permission should have low compatibility risks. Restricting this permission to secure contexts may have risks if different browsers handle mixed content differently.

Gecko: No signal (previously positive about PNA though https://github.com/mozilla/standards-positions/issues/143)

WebKit: No signal (previously positive about PNA though https://github.com/WebKit/standards-positions/issues/163)

Web developers: No signals, but switching to a permission-gated design is motivated by feedback from developers in response to the Private Network Access work

Other signals: 

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

Debuggability

We plan to create DevTools Issues entries when a site would be affected by these restrictions that includes guidance about how to meet the new restrictions. Blocked requests will also be visible in the DevTools Networking tab, with a distinct error.

Is this feature fully tested by web-platform-tests?

Not yet

Flag name on about://flags

None

Finch feature name

LocalNetworkAccessChecks

Requires code in //chrome?

True

Tracking bug

https://crbug.com/394009026

Estimated milestones

M136

Link to entry on the Chrome Platform Status

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

This intent message was generated by Chrome Platform Status.

[Torne (Richard Coles)]

For awkward historical API design reasons, WebView currently has no way to let apps grant any new permission types, so gating this behind a permission for WebView would just entirely remove this capability for all apps, which means this is definitely a significant compatibility risk.

I commented on the implementation CL - for the short term just granting this permission unconditionally in WebView should allow you to go ahead and experiment for other platforms, but applying this to WebView will need a bigger conversation with the team.

 

Debuggability

We plan to create DevTools Issues entries when a site would be affected by these restrictions that includes guidance about how to meet the new restrictions. Blocked requests will also be visible in the DevTools Networking tab, with a distinct error.

Is this feature fully tested by web-platform-tests?

Not yet

Flag name on about://flags

None

Finch feature name

LocalNetworkAccessChecks

Requires code in //chrome?

True

Tracking bug

https://crbug.com/394009026

Estimated milestones

M136

Link to entry on the Chrome Platform Status

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

This intent message was generated by Chrome Platform Status.

--
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+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALMy46SB%2Bv9dnp-wrJ4WH0R4UJmWuutq1st92%3D_zOyhnLJ_vkw%40mail.gmail.com.

[Chris Thompson]

Thank you for the pointers on crrev.com/c/6325710 -- adding any restrictions in WebView would be a separate launch and we will reach out before trying to pursue that. For now we will make sure that the restrictions do not apply / the permission is automatically granted in WebView.