So again, apologies for my confusion: does this OT cover *just* the opt-out behaviour? If so, LGTM. If not, we should discuss splitting other features out from this intent.
Best, Alex On Wednesday, January 28, 2026 at 10:05:36 AM UTC-8 Chris Thompson wrote: > 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/134b07bb-9c8f-4b0d-9f25-ea72d1424968n%40chromium.org.
