Intent to Ship: Local network access restrictions for WebTransport

[Chromestatus]

Contact emails

hc...@chromium.org

Explainer

https://github.com/WICG/local-network-access/blob/main/explainer.md

Specification

https://wicg.github.io/local-network-access/#integration-with-webtransport

Summary

Restricts the ability to make requests to the user's local network using WebTransport, gated behind a permission prompt. A local network request is any request from a public website to a local IP address or loopback, or from a local website (e.g. intranet) to loopback. Gating the ability for websites to perform these requests behind a permission reduces the ability of sites to use these requests to fingerprint the user's local network. This permission is restricted to secure contexts. This work is adding to the Local Network Access Restrictions work here: https://chromestatus.com/feature/5152728072060928

Blink component

Blink>SecurityFeature>LocalNetworkAccess

Web Feature ID

local-network-access

Motivation

Local WebTransport 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 WebTransport

Initial public proposal

No information provided

TAG review

No information provided

TAG review status

Pending

Risks

Interoperability and Compatibility

No information provided

Gecko: No signal

WebKit: No signal

Web developers: No signals

Other signals:

Activation

A new permission will be shown to users, which may be unexpected, and if users deny the permission functionality may break (potentially requiring additional support from site owners). As this is building off of the first Local Network Access launch, this should be a minimal risk, but has a chance of impacting those who are impacted by this launch but were not impacted by the original Local Network Access launch. This is slightly different from the other LNA launches as WebTransport is restricted to secure contexts, so we do not have any worries about mixed content blocking.

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

No information provided

Debuggability

No information provided

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

No
This is unsupported on WebView for the same reasons that Local Network Access is unsupported on WebView

Is this feature fully tested by web-platform-tests?

No

DevTrial instructions

https://docs.google.com/document/d/1GHbpRTCnfDXq9o8WKyrG7oPAiWC6Yozac-PvbfO3KoY/edit?usp=sharing

Flag name on about://flags

local-network-access-check-webtransport

Finch feature name

LocalNetworkAccessChecksWebTransport

Rollout plan

Will ship enabled for all users

Requires code in //chrome?

False

Tracking bug

https://issues.chromium.org/issues/421216834

Estimated milestones

Shipping on desktop	147
DevTrial on desktop	144
Shipping on Android	147
DevTrial on Android	144

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

No information provided

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5126430912544768?gate=5078007672864768

Links to previous Intent discussions

Intent to Prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/68cc4140.2b0a0220.28e063.0124.GAE%40google.com

This intent message was generated by Chrome Platform Status.

[Mike Taylor]

On 2/19/26 2:28 p.m., Chromestatus wrote:

Contact emails

hc...@chromium.org

Explainer

https://github.com/WICG/local-network-access/blob/main/explainer.md

Specification

https://wicg.github.io/local-network-access/#integration-with-webtransport

I'd be happier if we spent some time defining the actual integration with WebTransport - this doesn't really describe how or when LNA should be applied. i.e., does it happen in the constructor steps? Or when obtaining a connection? Somewhere else? Does it ever throw an error? etc

Why not? It seems like this should be possible.

--
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 blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6997646c.2b0a0220.19817b.07d2.GAE%40google.com.

[Hubert Chao]

On Fri, Feb 20, 2026 at 10:23 AM Mike Taylor <mike...@chromium.org> wrote:

On 2/19/26 2:28 p.m., Chromestatus wrote:

Contact emails

hc...@chromium.org

Explainer

https://github.com/WICG/local-network-access/blob/main/explainer.md

Specification

https://wicg.github.io/local-network-access/#integration-with-webtransport

I'd be happier if we spent some time defining the actual integration with WebTransport - this doesn't really describe how or when LNA should be applied. i.e., does it happen in the constructor steps? Or when obtaining a connection? Somewhere else? Does it ever throw an error? etc

The short answer is that this check happens in the constructor before a connection is attempted.  Re: more spec work, its something that is on our list of things to do, but we've chosen to prioritize other LNA landing work to ensure better user experiences (see the ongoing discussion in https://groups.google.com/a/chromium.org/g/blink-dev/c/8AK8V4fSZFU)

Looking briefly at the specs, I'm not 100% sure if we'd patch the fetch spec for "obtaining a connection" (https://fetch.spec.whatwg.org/#concept-connection-obtain) which is referenced in webtransport's "obtaining a connection" section (here). If its the former, than we wouldn't need to change the WebTransport spec at all.

 

Is this feature fully tested by web-platform-tests?

No 

Why not? It seems like this should be possible

Because we haven't prioritized WPTs for LNA up until recently; we've been using chromium browser tests and unit tests. This is on our priority list (again see the discussion ongoing in https://groups.google.com/a/chromium.org/g/blink-dev/c/8AK8V4fSZFU)

[Hubert Chao]

On Friday, February 20, 2026 at 11:35:59 AM UTC-5 Hubert Chao wrote:

On Fri, Feb 20, 2026 at 10:23 AM Mike Taylor <mike...@chromium.org> wrote:

On 2/19/26 2:28 p.m., Chromestatus wrote:

Contact emails

hc...@chromium.org

Explainer

https://github.com/WICG/local-network-access/blob/main/explainer.md

Specification

https://wicg.github.io/local-network-access/#integration-with-webtransport

I'd be happier if we spent some time defining the actual integration with WebTransport - this doesn't really describe how or when LNA should be applied. i.e., does it happen in the constructor steps? Or when obtaining a connection? Somewhere else? Does it ever throw an error? etc

The short answer is that this check happens in the constructor before a connection is attempted.  Re: more spec work, its something that is on our list of things to do, but we've chosen to prioritize other LNA landing work to ensure better user experiences (see the ongoing discussion in https://groups.google.com/a/chromium.org/g/blink-dev/c/8AK8V4fSZFU)

Looking briefly at the specs, I'm not 100% sure if we'd patch the fetch spec for "obtaining a connection" (https://fetch.spec.whatwg.org/#concept-connection-obtain) which is referenced in webtransport's "obtaining a connection" section (here). If its the former, than we wouldn't need to change the WebTransport spec at all.

I looked at this a bit more, I'm pretty convinced that we won't need to modify the webtransport spec, and documented this at https://wicg.github.io/local-network-access/#integration-with-webtransport

/hubert