Yes, this is just for the secure contexts opt-out behavior. We plan to continue to separately send out intents for other LNA rollouts.
On Mon, Feb 2, 2026 at 12:08 PM Alex Russell <[email protected]> wrote: > 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/CALMy46SGMuBzprEhsPq2mhz0fYVdGq6%2BJT-8y_TnS-24%2B1SOTw%40mail.gmail.com.
