LGTM. Thanks for your patience.
Best, Alex On Monday, February 2, 2026 at 12:23:34 PM UTC-8 Chris Thompson wrote: > 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/0b9d4b19-c190-4bf9-ae60-8e0b5ee73f69n%40chromium.org.
