On Fri, Feb 20, 2026 at 10:30 AM Mike Taylor <[email protected]> wrote:
> On 2/19/26 2:29 p.m., Chromestatus wrote: > > *Contact emails* > [email protected] > > *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 > <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ESecurityFeature%3ELocalNetworkAccess%22> > > *Web Feature ID* > local-network-access <https://webstatus.dev/features/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 > 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 -- 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/CAHEiSH0Q9hKe3cypjhPTp_iyB-X%3Dwx5FWMtRQqUo3986jB%3DtPg%40mail.gmail.com.
