On Thu, 6 Mar 2025 at 19:38, Chris Thompson <cth...@chromium.org> wrote:
> 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 > 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 > <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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALMy46SB%2Bv9dnp-wrJ4WH0R4UJmWuutq1st92%3D_zOyhnLJ_vkw%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/CAEV-rjeQkPREqStFevWBmyhFo5xvYPUiW0xcPKYj44D4Cms3LQ%40mail.gmail.com.
