Rick is correct, we are planning on a reverse OT to be in place before we turn this on in stable channel.
On Mon, Jun 30, 2025 at 10:32 AM Rick Byers <rby...@chromium.org> wrote: > 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 > "chrome-secure-web-and-net" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to chrome-secure-web-and-net+unsubscr...@chromium.org. > To view this discussion visit > https://groups.google.com/a/chromium.org/d/msgid/chrome-secure-web-and-net/CAFUtAY-J%2B6-yZiqw6BHtdLbgt-NjAynK_d2sriE8KBY3ZQhs1g%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/chrome-secure-web-and-net/CAFUtAY-J%2B6-yZiqw6BHtdLbgt-NjAynK_d2sriE8KBY3ZQhs1g%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/a/chromium.org/d/optout. > -- 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/CAHEiSH38soty4pretkJ%2Bn44vmkjcnng-u0xt101Mp9g1wOSqCg%40mail.gmail.com.
