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.
