Hi Alex -- The OT we are requesting an extension for is just the ability for sites to temporarily opt-out of the secure contexts requirement, which was included as part of our original Intent-to-Ship for Local Network Access <https://groups.google.com/a/chromium.org/g/blink-dev/c/cwu_RUmBpzY/m/hk8YuZDWHgAJ>. The same opt-out applies to the followup work we are doing to apply LNA restrictions to WebSockets (planned for M147), so we want to extend the OT to serve as a temporary solution for mixed content issues that developers might run into during that rollout.
This bit from our original I2S might help clarify: > 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). Requests from insecure contexts will be silently rejected. Sites may temporarily opt-out of the secure contexts restriction using the reverse origin trial “Local Network Access from Non-Secure Contexts <https://developer.chrome.com/origintrials/#/view_trial/3826370833404657665>”, included in this launch. Sorry for any confusion from the automated email from ChromeStatus! I know there are a lot of different moving parts for our rollout of LNA. - Chris On Wed, Jan 28, 2026 at 8:20 AM Alex Russell <[email protected]> wrote: > Hey Chris, > > There was some confusion this morning about this Intent in API OWNERS. A > couple of things would be helpful to tease out (and apologies if they're > obvious to you; they weren't to us): > > - This is being phrased as an extension, however it seems that the API > shape is changing too (the new permission policy name). Ordinarily, we'd > just approve something like that because it would likely be a breaking > change, but it sounds like care is being taken not to break OT users here. > Why? > - Is it correct to say that this is both a deprecation (of the local > network connection behaviour) and a new feature (the new permissions)? If > so, how do you suggest the API OWNERS think about what sort of risk we're > taking on? > - What's the tlimeline for removal/ship (depending on answer to the > previous question)? > > Best, > > Alex > > On Tuesday, January 27, 2026 at 1:08:10 PM UTC-8 Chromestatus wrote: > >> *Contact emails* >> [email protected] >> >> *Explainer* >> https://github.com/WICG/local-network-access/blob/main/explainer.md >> >> *Specification* >> https://wicg.github.io/local-network-access >> >> *Design docs* >> >> https://github.com/explainers-by-googlers/local-network-access >> >> https://docs.google.com/document/d/1n0kKxt9pS9qDlu_9i5W8IXA594r4pUOKmN9H35cZ8j0/edit?usp=sharing >> >> *Summary* >> Chrome 142 restricted 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 (for example, 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]( >> https://chromestatus.com/feature/5737414355058688), which used preflight >> requests to have local devices opt-in. For more information on this >> feature, see [Adapting your website for new Local Network Access >> restrictions in Chrome]( >> https://docs.google.com/document/d/1QQkqehw8umtAgz5z0um7THx-aoU251p705FbIQjDuGs/edit?usp=sharing). >> <br> Chrome 145 introduces more granular permissions for websites >> requesting access to a user's local network. The previous single >> `local-network-access permission` is being split into two distinct >> permissions: * `local-network`: Grants access to IP addresses in the local >> network space (for example, intranets, internal devices). * >> `loopback-network`: Grants access to loopback IP addresses (for example., >> `localhost`, `127.0.0.1`). The old `local-network` permission will remain >> as an alias, ensuring existing configurations and Permissions Policies >> continue to function as expected. This change provides both users and >> Admins with more precise control over how websites interact with internal >> network resources. Current enterprise policies managing local network >> access will not be affected by this change. >> >> *Blink component* >> Blink>SecurityFeature>LocalNetworkAccess >> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ESecurityFeature%3ELocalNetworkAccess%22> >> >> *Web Feature ID* >> local-network-access >> <https://webstatus.dev/features/local-network-access> >> >> *TAG review* >> https://github.com/w3ctag/design-reviews/issues/1116 >> >> *TAG review status* >> Issues addressed >> >> *Origin Trial Name* >> Local Network Access from Non-Secure Contexts >> >> *Chromium Trial Name* >> LocalNetworkAccessNonSecureContextAllowed >> >> *Origin Trial documentation link* >> https://developer.chrome.com/blog/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. Request for signals: >> https://github.com/mozilla/standards-positions/issues/1260 >> >> *WebKit*: No signal Request for signals: >> https://github.com/WebKit/standards-positions/issues/520 >> >> *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? >> *No information provided* >> >> >> *Goals for experimentation* >> *No information provided* >> >> *Reason this experiment is being extended* >> Launch of Local Network Access restrictions for WebSockets has been >> delayed from M144 to M147 due to holidays and enterprise concerns. We'd >> like to push back the end date of this origin trial to allow for those >> running WebSockets on HTTP endpoints currently to opt out of the secure >> context restrictions for a period of time while they migrate to a secure >> context >> >> *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 >> >> *Launch bug* >> https://launch.corp.google.com/launch/4395658 >> >> *Estimated milestones* >> Shipping on desktop 142 >> Origin trial desktop first 141 >> Origin trial desktop last 146 >> Origin trial extension 1 end milestone 152 >> DevTrial on desktop 138 >> Shipping on Android 142 >> Origin trial Android first 141 >> Origin trial Android last 146 >> DevTrial on Android 139 >> Rollout step 1 152 >> Rollout step 2 147 >> Rollout step 3 145 >> >> *Link to entry on the Chrome Platform Status* >> https://chromestatus.com/feature/5152728072060928?gate=5186662093160448 >> >> *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 >> Intent to Experiment: >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHEiSH03XUPgcAkVmE25PpvDXMsx%3D16Kgeid_KJ8vRgyvueNuA%40mail.gmail.com >> Intent to Ship: >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALMy46R%3DBq1orEwZUxfXg71hpJfcgV%3DUtsFUC7AiiMjA8f6_5A%40mail.gmail.com >> >> >> 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 [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALMy46SdTjzd61D2PzasaHHg0KALjRuDNjivb_ZczsQvkmzZcw%40mail.gmail.com.
