Intent to Ship: Local Network Access restrictions on Service Worker WindowClient.navigate()

36 views
Skip to first unread message

Chromestatus

unread,
Feb 10, 2026, 1:52:23 PM (17 hours ago) Feb 10
to blin...@chromium.org, cth...@chromium.org, yyana...@chromium.org, hc...@chromium.org, jdeb...@chromium.org
Contact emails
hc...@chromium.org

Explainer
No information provided

Specification
No information provided

Summary
Local Network Access (LNA) restrictions have been recently added in the last few months to restrict web sites from unilaterally making requests to local networks and local devices (https://chromestatus.com/feature/5152728072060928). This was added for Service Worker-initiated fetch requests, but was not done for navigations done by service workers through WindowClient.navigate This launch closes this hole by adding LNA restrictions to WindowClient.navigate() calls, using the WindowClient as the initiator of the navigation to determine if the navigation is an LNA request. This only applies if the WindowClient being navigated is a subframe; Chrome does not currently enforce any LNA restrictions on main frame navigations.

Blink component
Blink > SecurityFeature > LocalNetworkAccess

Web Feature ID
local-network-access

Motivation
No information provided

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:

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

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


Flag name on about://flags
No information provided

Finch feature name
No information provided

Non-finch justification
No information provided

Rollout plan
Will ship enabled for all users

Requires code in //chrome?
False

Estimated milestones
Shipping on desktop147
Shipping on Android147


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).

The service worker spec dealing with the navigate() call will need to be modified to take into account the LNA checks (specifically, here https://www.w3.org/TR/service-workers/#client-navigate)

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5172375182245888?gate=6499217281515520

This intent message was generated by Chrome Platform Status.

Mike Taylor

unread,
Feb 10, 2026, 3:30:58 PM (16 hours ago) Feb 10
to Chromestatus, blin...@chromium.org, cth...@chromium.org, yyana...@chromium.org, hc...@chromium.org, jdeb...@chromium.org

Can you please request the various review bits in your chromestatus entry (i.e., privacy, security, enterprise...)?

--
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/698b7e59.050a0220.29f6fd.0634.GAE%40google.com.

Hubert Chao

unread,
Feb 10, 2026, 3:45:49 PM (15 hours ago) Feb 10
to blink-dev, Mike Taylor, Chris Thompson, Yoshisato Yanagisawa, Hubert Chao, Joe DeBlasio, Chromestatus
Done. Apologies, wasn't sure if this needed to be done for this change.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Mike Taylor

unread,
Feb 10, 2026, 4:16:33 PM (15 hours ago) Feb 10
to Hubert Chao, blink-dev, Chris Thompson, Yoshisato Yanagisawa, Joe DeBlasio, Chromestatus

On 2/10/26 3:45 p.m., Hubert Chao wrote:

Done. Apologies, wasn't sure if this needed to be done for this change.
Thanks Hubert.

Do we not have any official signals for LNA generally? I looked at https://chromestatus.com/feature/5152728072060928 and see an I2P for Mozilla, but nothing for WebKit. Can we file something if not?

Also, can we update this chromestatus entry with both, once we have them?


Web developers: No signals

Other signals:

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

Is this feature fully tested by web-platform-tests?
No 
Why not?

Hubert Chao

unread,
Feb 10, 2026, 5:08:17 PM (14 hours ago) Feb 10
to Mike Taylor, blink-dev, Chris Thompson, Yoshisato Yanagisawa, Joe DeBlasio, Chromestatus
On Tue, Feb 10, 2026 at 4:16 PM Mike Taylor <mike...@chromium.org> wrote:


Interoperability and Compatibility
No information provided

Gecko: No signal

WebKit: No signal

Do we not have any official signals for LNA generally? I looked at https://chromestatus.com/feature/5152728072060928 and see an I2P for Mozilla, but nothing for WebKit. Can we file something if not?

Also, can we update this chromestatus entry with both, once we have them?

Firefox is shipping their LNA implementation, first to their users with Enhanced Tracking Protection on.


We have heard nothing from webkit. We did a request for position with the first LNA launch


and annevk has posted some on the github spec repo about the permission names (https://github.com/WICG/local-network-access/issues/17), but we haven't heard anything else from them. Is this something where we should proactively ping them?
 

Web developers: No signals

Other signals:

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

Is this feature fully tested by web-platform-tests?
No 
Why not

For this specific fix, we tested with browser tests.

In general for LNA, we have some basic WPT's checked in (https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/fetch/local-network-access/), but we don't have everything tested in WPT that we do in chromium browser tests. Its something we've been meaning to do but haven't gotten around to due to other competing priorities around LNA (most notably the split permissions).

/hubert 

Dan Clark

unread,
Feb 10, 2026, 8:42:40 PM (10 hours ago) Feb 10
to blink-dev, hc...@chromium.org, blink-dev, cth...@chromium.org, yyana...@chromium.org, jdeb...@chromium.org, Chromestatus, mike...@chromium.org
Is any spec update (https://wicg.github.io/local-network-access) needed to reflect this change or is this behavior implied by what's already there?

-- Dan

Reply all
Reply to author
Forward
0 new messages