Was there an update here on plan to roll this out, other than a DevTrial? OT? Fractional rollout to stable over a longer time period?
Best, Alex On Friday, February 20, 2026 at 9:37:57 AM UTC-8 Hubert Chao wrote: > 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/9ee81edf-db19-4acc-9dfc-f5c2a22a6588n%40chromium.org.
