Thanks, Chris. LGTM3
On Wednesday, March 18, 2026 at 7:10:39 AM UTC-7 Daniel Bratell wrote: > LGTM2 > > /Daniel > On 2026-03-13 20:24, Mike Taylor wrote: > > LGTM1 - thanks for updating the WebSockets part of the spec to call into > the Fetch monkey patch, and other general spec and WPT work in the past few > weeks. > > Good luck with the roll out! > On 3/11/26 5:56 p.m., Chris Thompson wrote: > > This has been in DevTrial and enabled at 50% Beta for a while now to try > to suss out any compatibility issues. Our planned next step to be to enable > by default on trunk (after we get LGTMs) and let this go through the > waterfall (targeting M147), with a kill switch available just in case. > > On Mon, Mar 9, 2026 at 11:41 AM Alex Russell <[email protected]> > wrote: > >> 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/29e79d06-2922-4b65-9019-e7408637bd55%40chromium.org > > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/29e79d06-2922-4b65-9019-e7408637bd55%40chromium.org?utm_medium=email&utm_source=footer> > . > > -- 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/474e0bfa-d16a-4692-8841-72e9bf471065n%40chromium.org.
