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.
On Tue, Mar 11, 2025 at 12:39 PM Torne (Richard Coles) <to...@chromium.org> wrote: > > > 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/CALMy46QM%3DSUddR7i2BW8vhT%2Bi3evdvhaY7LQbKscJvJkFAwomg%40mail.gmail.com.
