This approval was just for pre-stable experiments, so I was expecting the team to follow back up here to discuss the risks and mitigations prior to any stable experiments.
I agree though that having the reverse OT infra in place prior to any stable experiments would be wise in this case. But even with that mitigation there's still a challenge with outreach and reliable diagnosability (always a problem with web-exposed finch) so I think we'll need a broader discussion before any stable experiments. Rick On Sat, Jun 28, 2025 at 1:39 AM Erik Anderson <erik.ander...@microsoft.com> wrote: > Double checking: you will have the reverse OT infrastructure set up before > proceeding to a stable channel experiment, correct? > > > > *From:* Rick Byers <rby...@chromium.org> > *Sent:* Tuesday, June 24, 2025 1:40 PM > *To:* Hubert Chao <hc...@chromium.org> > *Cc:* blink-dev <blink-dev@chromium.org>; Chris Thompson < > cth...@chromium.org>; chrome-secure-web-and-...@chromium.org; David > Adrian <dadr...@google.com> > *Subject:* [EXTERNAL] Re: [blink-dev] Intent to Experiment: Local Network > Access > > > > LGTM to experiment via Finch in pre-stable channels. > > > > I love the strategy of automatically popping a permission prompt. I'm > optimistic we can get this tuned to minimize breakage while maximizing > developer predictability and user understandability, but I can totally > imagine that it'll take some tuning to get there. Please let us know when > you feel confident enough in the data to start experimenting in stable - > that'll be a key point in the rollout I believe and probably worthy of some > extra discussion on the tradeoffs. > > > > Ensuring users have transparency and control over local network access is > important for security and privacy, thank you for working on it! > > > > Rick > > > > > > On Tue, Jun 24, 2025 at 4:21 PM Hubert Chao <hc...@chromium.org> wrote: > > Note: this is for pre-stable experimentation through Finch, not for an > Origin Trial. > > > Contact emails > > cth...@chromium.org > > hc...@chromium.org > > > Explainer > > https://github.com/WICG/local-network-access > > > Specification > > > https://docs.google.com/document/d/1n0kKxt9pS9qDlu_9i5W8IXA594r4pUOKmN9H35cZ8j0/edit?tab=t.0 > > > Design docs > > > > https://github.com/explainers-by-googlers/local-network-access > > > https://docs.google.com/document/d/1n0kKxt9pS9qDlu_9i5W8IXA594r4pUOKmN9H35cZ8j0/edit?usp=sharing > > > 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>CORS>PrivateNetworkAccess > <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ESecurityFeature%3ECORS%3EPrivateNetworkAccess%22> > > > TAG review > > https://github.com/w3ctag/design-reviews/issues/1116 > > > TAG review status > > Pending > > > Origin Trial documentation link > > https://github.com/WICG/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, no formal request for > signals yet > > > > *WebKit*: No signal No request for signals yet > > > > *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?* > > None > > > Goals for experimentation > > We intend to evaluate implementation of Local Network Access (LNA) through > more widespread testing to ensure that we (a) do not capture any requests > that are not LNA requests, and (b) all request that are LNA are captured > and trigger a permissions check. > > > > Intending to turn on up to 100% in Chrome Canary/Dev/Beta channel via > Finch. > > > > *Experiment Risks* > > > > There may be false positives (request that are captured as LNA requests > that are not) and false negatives (request that are LNA request that are > not captured). > > > > There is additional breakage risk with LNA request from non-secure > contexts, as well as mixed-content LNA requests. > > > 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 > <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> > ? > > 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 > > > Estimated milestones > > DevTrial on desktop > > 138 > > DevTrial on Android > > 139 > > > Link to entry on the Chrome Platform Status > > https://chromestatus.com/feature/5152728072060928 > > > 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 > > Ready For Developer Testing: > > > https://groups.google.com/a/chromium.org/g/blink-dev/c/D4nqAa3FUN8/m/WFVmJYh0BAAJ > > > > -- > 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/CAHEiSH03XUPgcAkVmE25PpvDXMsx%3D16Kgeid_KJ8vRgyvueNuA%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHEiSH03XUPgcAkVmE25PpvDXMsx%3D16Kgeid_KJ8vRgyvueNuA%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/CAFUtAY9eF3RGQ65ov_peGHE__L9iCNutzVfckZYKwm0xzqzJkg%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9eF3RGQ65ov_peGHE__L9iCNutzVfckZYKwm0xzqzJkg%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/CAFUtAY-J%2B6-yZiqw6BHtdLbgt-NjAynK_d2sriE8KBY3ZQhs1g%40mail.gmail.com.
