Intent to Ship: Local network access restrictions for WebSockets

[Chromestatus]

Contact emails

hc...@chromium.org

Explainer

https://github.com/WICG/local-network-access/blob/main/explainer.md#websockets

Specification

https://wicg.github.io/local-network-access/#integration-with-websockets

Summary

Local Network Access(LNA) restrictions are being expanded to include WebSockets. WebSockets connections to local address will now start triggering permission prompts. All of the current LNA enterprise policies will still apply to the LNA WebSockets restrictions (LocalNetworkAccessAllowedForUrls, LocalNetworkAccessBlockedForUrls, and LocalNetworkAccessRestrictionsTemporaryOptOut). More information about LNA can be found at https://developer.chrome.com/blog/local-network-access

Blink component

Blink>SecurityFeature>LocalNetworkAccess

Web Feature ID

local-network-access

Motivation

Local WebSockets connections are subject to many of the same attacks that the original LNA proposal are designed to solve. This would add the same controls that were implemented in the original LNA proposal to WebSockets

Initial public proposal

No information provided

TAG review

No information provided

TAG review status

Pending

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, and `.local` domains are exempted from mixed content checks, but we do not have an equivalent to the `targetAddressSpace` fetch() option for WebSockets We hope that our Dev Trial will help identify compatibility issues. The LNA reverse origin trial will provide a temporary opt-out for those that are not able to bypass the mixed content checks currently

Gecko: No signal

WebKit: No signal

Web developers: No signals

Other signals:

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). As this is building off of the first Local Network Access launch, this should be a minimal risk, but has a chance of impacting those who are impacted by this launch but were not impacted by the original Local Network Access launch.

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

Debuggability

No information provided

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

No
This is unsupported on WebView for the same reasons that Local Network Access is unsupported on WebView

Is this feature fully tested by web-platform-tests?

No

DevTrial instructions

https://docs.google.com/document/d/1GHbpRTCnfDXq9o8WKyrG7oPAiWC6Yozac-PvbfO3KoY/edit?usp=sharing

Flag name on about://flags

local-network-access-check-websockets

Finch feature name

LocalNetworkAccessChecksWebSockets

Rollout plan

Will ship enabled for all users

Requires code in //chrome?

False

Tracking bug

https://crbug.com/421156866

Measurement

Use counters: - PrivateNetworkAccessWebSocketConnected counts the number of LNA WebSockets request we see - LocalNetworkAccessWebSocketResourceNotKnownPrivate - counts cases in which a `targetAddressSpace` option could have helped bypass mixed content checks

Estimated milestones

Shipping on desktop	147
DevTrial on desktop	142
Shipping on Android	147
DevTrial on Android	142

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

No information provided

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5197681148428288?gate=5077674561241088

Links to previous Intent discussions

Intent to Prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/68b9e717.050a0220.3291f8.09fe.GAE%40google.com
Intent to Experiment: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHEiSH2ujeQQ0jJw1eYb-WfS1Ozw%2Bc4%2BX%2BrSxTD%2B524wMYbknQ%40mail.gmail.com

This intent message was generated by Chrome Platform Status.

[Mike Taylor]

On 2/19/26 2:29 p.m., Chromestatus wrote:

Contact emails

hc...@chromium.org

Explainer

https://github.com/WICG/local-network-access/blob/main/explainer.md#websockets

Specification

https://wicg.github.io/local-network-access/#integration-with-websockets

Summary

Local Network Access(LNA) restrictions are being expanded to include WebSockets. WebSockets connections to local address will now start triggering permission prompts. All of the current LNA enterprise policies will still apply to the LNA WebSockets restrictions (LocalNetworkAccessAllowedForUrls, LocalNetworkAccessBlockedForUrls, and LocalNetworkAccessRestrictionsTemporaryOptOut). More information about LNA can be found at https://developer.chrome.com/blog/local-network-access

Blink component

Blink>SecurityFeature>LocalNetworkAccess

Web Feature ID

local-network-access

Motivation

Local WebSockets connections are subject to many of the same attacks that the original LNA proposal are designed to solve. This would add the same controls that were implemented in the original LNA proposal to WebSockets

Initial public proposal

No information provided

TAG review

No information provided

TAG review status

Pending

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, and `.local` domains are exempted from mixed content checks, but we do not have an equivalent to the `targetAddressSpace` fetch() option for WebSockets We hope that our Dev Trial will help identify compatibility issues. The LNA reverse origin trial will provide a temporary opt-out for those that are not able to bypass the mixed content checks currently 

Do you have an update here? DevTrial isn't the best way to assess actual compatibility (because it relies on people finding your blog post / blink-dev email). Is it not possible to add metrics to understand the potential impact?

--
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+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69976492.2b0a0220.19817b.07d3.GAE%40google.com.

[Hubert Chao]

We have 2 use counters:

* PrivateNetworkAccessWebSocketConnected - logged when there's a site that runs a websocket connection to an IP address that is considered local or loopback. https://chromestatus.com/metrics/feature/timeline/popularity/4883 shows this at roughly 0.1% and steady over the last several months.

This # just indicates that a permission prompt will need to be shown and does not imply that there will be breakage  (assuming the user grants the permission). Cases in which there may be breakage would be if the websocket is being connected to in an iframe, in a shared worker, or in a service worker. It is worth noting here that there has been evidence of web sites using WebSocket connection requests as fraud/abuse detection (https://dl.acm.org/doi/abs/10.1145/3487552.3487857 ; Firefox also mentions this in a recent talk at https://fosdem.org/2026/schedule/event/QCSKWL-firefox-local-network-access/) which probably inflates the usage numbers.

* LocalNetworkAccessWebSocketResourceNotKnownPrivate -  logged when a site tries to connect to an IP address that is considered local or loopback, but would be blocked by mixed content checks because we cannot infer from the URL that this will be an LNA request. (e.g. they would break and have no targetAddressSpace option like we do for fetch()). https://chromestatus.com/metrics/feature/timeline/popularity/5660 shows this at 0.0001 or lower.

As this is also coming after the initial LNA launch, there is a lot of knowledge about LNA out there, and we have had some extensive communication with folks on WebSockets, delaying the launch of these restrictions several times (see https://github.com/WICG/local-network-access/issues/46). In addition, there are many more enterprise controls available now that were not present with LNA's original launch, so this should be even lower risk of breakage.

 /hubert