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/9865d0da-7c85-43c3-b21b-115e8bb8d47a%40gmail.com.
