Contact emailscth...@chromium.org Explainerhttps://github.com/explainers-by-googlers/local-network-access
SpecificationNot 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 componentBlink>SecurityFeature>PrivateNetworkAccess <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ESecurityFeature%3EPrivateNetworkAccess%22> 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 proposalhttps://github.com/WICG/proposals/issues/198 TAG reviewNot yet TAG review statusNot 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 <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> ?Not yet Flag name on about://flagsNone Finch feature nameLocalNetworkAccessChecks Requires code in //chrome?True Tracking bughttps://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 <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/CALMy46SB%2Bv9dnp-wrJ4WH0R4UJmWuutq1st92%3D_zOyhnLJ_vkw%40mail.gmail.com.
