#1116: TAG review for Local Network Access(LNA)

Visit on Github.

Opened Jun 24, 2025

こんにちは TAG-さん!

I'm requesting a TAG review of Local Network Access (LNA).

Currently public websites can probe a user's local network, perform CSRF attacks against vulnerable local devices, and generally abuse the user's browser as a "confused deputy" that has access inside the user's local network or software on their local machine. For example, if you visit evil.com it can use your browser as a springboard to attack your printer (given an HTTP accessible printer exploit).

Local Network Access aims to prevent these undesired requests to insecure devices on the local network. This is achieved by deprecating direct access to private IP addresses from public websites, and instead requiring that the user grants permission to the initiating website to make connections to their local network.

Further details:

You should also know that...

Note: This proposal builds on top of Chrome's previously paused Private Network Access (PNA) work, but differs by gating access on a permission rather than via preflight requests. This increases the level of user control (at the expense of new permissions that have to be explained to the user) but removes the explicit "device opt-in" that the preflight design achieved. We believe this simpler design will be easier to ship, in order to mitigate the real risks of local network access today. Unlike the previous Private Network Access proposal, which required changes to devices on local networks, this approach should only require changes to sites that need to access the local network. Sites are much easier to update than devices, and so this approach should be much more straightforward to roll out.

This work is important for preventing future occurrences of the Meta/Yandex tracking recently discovered in https://localmess.github.io/

Discussions

Log in to see TAG-private discussions.

Discussed Jun 30, 2025 (See Github)

Martin: Consent/permission is bad.

Yves: People will click through without understanding, for sure.

Martin: for localmess, that's probably OK

Yves: Not convinced of that.

Yoav: There are legitimate use cases for local network access (tv streaming, etc...) There is also a ton of abuse. We need some way to draw a line.

Martin: Best we can do for now. Even if we don't settle. PNA failed badly.

Martin can draft something.

Discussed Jul 7, 2025 (See Github)

Yves: Martin made a proposal last week that demonstrates the concerns with the user prompt. Comment is perfect, we should close satisfied with concerns as proposed by Martin.

Martin: Will do, just processing Jeffrey's comment.

Lola: Inclined to defer to the both of you, or do you want to wait until Jeffrey is back?

Yves: Don't think Jeffrey would mind, but we could wait.

Martin: Think Jeffrey was fine with posting.

Yves: Think it is more an experiment at this stage.

Comment by @martinthomson Jul 10, 2025 (See Github)

Thanks for sharing this. We agree that it is necessary to do something more about malicious sites connecting to local services, including the localmess problem. There are use cases that depend on public sites talking to private servers and those are both common and basically impossible to distinguish from attacks. Previous attempts to address this - with Private Network Access in particular - failed, so we realize that a permissions prompt is probably the only option we have available, given the urgent need for a response to the attacks.

However, we do think that a permission prompt is not a great solution. Or rather, it's almost exactly the wrong thing to be asking people to decide. These sorts of questions only work if consent is "freely given, specific, and informed", where this basically fails on all three tests. This is not something that people are naturally able to understand very well. The permission is also necessarily very broad. And the alternative is generally that the site breaks, so it cannot reasonably claim to be "freely given" either.

So we encourage you to continue to look for better options, while recognizing the unfortunate necessity of this in the short term.

Not ALL the TAG agree with this viewpoint; some of us believe that it might be possible to construct a prompt that makes it possible to obtain meaningful consent. Shipping the feature might help answer that.

Finally, a few clerical things:

Comment by @christhompson Jul 10, 2025 (See Github)

We agree that a permission prompt is somewhat non-ideal, but we feel that any speed bump and user notice here is better than what the status quo has been for a long time now. Longer term I hope we are able to move towards something more like a Discovery API that can use chooser patterns (although this may need us to solve the local HTTPS problem first). There may also be some medium term opportunities for improving the permission, how we apply it, and how we might be able to iterate to improve user understanding.

However, we do think that a permission prompt is not a great solution. Or rather, it's almost exactly the wrong thing to be asking people to decide. These sorts of questions only work if consent is "freely given, specific, and informed", where this basically fails on all three tests. This is not something that people are naturally able to understand very well. The permission is also necessarily very broad. And the alternative is generally that the site breaks, so it cannot reasonably claim to be "freely given" either.

In the case of things like the localmess tracking vector, our hope is that this is (1) substantially unexpected by end users, and (2) makes such behavior extremely visible and thus disincentivized. We already saw evidence that such tracking vectors moved away from prior techniques (such as direct fetch() requests) towards less visible techniques (i.e., WebRTC which doesn't show up directly in Chrome's DevTools' Network tab).

As with any permission-gated powerful capability, we hope that sites that have positive use cases adequately explain to their users what they are doing and why they need access to this capability. In the absence of such explanations, we hope that the permission prompt is sufficient speed bump to prevent drive-by exploitation on the web.

Not ALL the TAG agree with this viewpoint; some of us believe that it might be possible to construct a prompt that makes it possible to obtain meaningful consent. Shipping the feature might help answer that.

This is also our hope. We are already seeing Firefox take a slightly different approach to their permission prompts (separate prompts for "connect to loopback" and "connect to local network") -- this natural variation in implementations combined with seeing how this works in the real world (e.g., monitoring grant/deny rates for our permissions, among other metrics) will hopefully help guide future improvements.

To the clerical points:

Comment by @martinthomson Jul 11, 2025 (See Github)

To be clear, the somewhat urgent need for some speedbump is why we are "satisfied". The concerns all centre around the tough questions about prompting, which were enough for us to say that we weren't completely satisfied. That said, we don't see any better alternative, other than to keep trying. Hopefully we'll be smarter or better informed in the future, or something might change (I hold little hope for the local HTTPS situation, but that's still non-zero).