Proposal: Preflight + Public TLS as Permission Prompt Exemption for Local Network Access

[ChrisEdgington]

Summary

The LNA permission prompt is sound for the common case: unauthenticated HTTP requests to raw IPs where the browser cannot verify the target's identity or intent.

However, when a local network target serves a publicly-trusted TLS certificate and explicitly opts in via a CORS preflight, every security property the permission prompt provides is already established cryptographically — and more reliably than a user clicking "Allow." I propose exempting these requests from the prompt.

Use Case

I built ProxyBox Zero, a hardware device that acts as an HTTPS reverse proxy between cloud web applications and local network peripherals (printers, scales, barcode scanners). Our customers are small manufacturers, warehouses, and agricultural operations — no IT departments, no enterprise-managed devices.

How it works:

1. ProxyBox gets a local IP (e.g., 192.168.1.50)
2. DNS points {device-id}.pbxz.io → 192.168.1.50 via Cloudflare
3. Caddy uses the DNS-01 ACME challenge to obtain a publicly-trusted, CT-logged Let's Encrypt certificate
4. Cloud ERPs make fetch() calls to the device over browser-trusted HTTPS

The firmware is fully updatable — we can implement any preflight or handshake protocol the spec requires. Enterprise policies (LocalNetworkAccessAllowedForUrls) are not viable for our market; our users don't know what Chrome policies are.

The Core Argument

The LNA explainer states:

"Even if the local device has opted in to connections from a top level site, we believe there is value in user awareness and control over this exchange."

This was written about the original PNA preflight, where "opted in" meant an unauthenticated HTTP server at some IP returned a header — a weak signal. User awareness meaningfully adds security there.

But when the target serves a publicly-trusted certificate with CT logging, responds to a preflight with Access-Control-Allow-Private-Network: true, and communicates over HTTPS end-to-end, the prompt is confirming what's already been established cryptographically.

What attack does the permission prompt prevent that the TLS handshake + preflight does not?

Threat	How TLS + preflight addresses it
CSRF against local devices	Target explicitly opts in via preflight; attacker cannot forge opt-in without controlling the device
Drive-by exploitation of vulnerable services	Vulnerable devices don't serve publicly-trusted certs or respond to preflights; they remain protected by the prompt
Network fingerprinting / scanning	Attacker must guess a valid hostname with a matching publicly-trusted cert on a local IP — see timing discussion below
User unawareness	The user physically installed the device and configured their ERP to use it

Why Previous Preflight Concerns Don't Apply

"Legacy devices can't implement preflights"

This proposal doesn't change anything for legacy devices. They continue through the permission prompt. This is a strictly additive path for devices that can meet the security bar.

"Timing attacks could determine valid IP addresses"

The original PNA preflight was sent to arbitrary IPs over HTTP, enabling topology discovery via timing (crbug.com/40051437, WICG/private-network-access#41). Under this proposal, the target must complete a TLS handshake with a publicly-trusted certificate matching the requested hostname. An attacker scanning local IPs sees:

• No TLS listener → connection refused (no new information vs. any closed port)
• Wrong/self-signed cert → handshake fails (no preflight sent)
• Valid cert, wrong hostname → verification fails (no preflight sent)

Reaching the preflight stage requires knowing a valid hostname that resolves locally and is served by a device with a matching public cert. At that point, the attacker already knows more than preflight timing would reveal.

"User awareness has value even with device opt-in"

The spec authors compare LNA to iOS/Android local network permissions. But those OS-level permissions are per-application, persistent, and one-time — they aren't reset by OS updates or profile changes. The browser permission prompt's persistence is implementation-defined and in practice fragile (browser updates, profile resets, switching browsers all re-trigger it). A TLS+preflight exemption would actually be closer to the OS model: durable authorization established by a strong signal.

Proposal

Exempt local network requests from the permission prompt when all conditions are met:

1. HTTPS end-to-end (no mixed content)
2. Target serves a certificate from a publicly-trusted CA (in the browser's root store)
3. Target responds to CORS preflight with Access-Control-Allow-Private-Network: true
4. Standard CORS requirements satisfied

If any condition isn't met, fall back to the current permission prompt.

if (isLocalNetworkRequest(request)) {
  if (connection.isHTTPS &&
      connection.certificate.isPubliclyTrusted &&
      preflightResponse.has("Access-Control-Allow-Private-Network: true") &&
      corsRequirementsMet(preflightResponse)) {
    return null; // Allow — security properties already satisfied
  } else {
    // Existing permission prompt flow
  }
}

This changes nothing for unauthenticated requests, legacy devices, or the spec's core security model. Users can still block local network access via Permissions Policy and browser settings.

Questions for Discussion

1. Are there attack scenarios where a valid publicly-trusted cert + preflight opt-in should still be blocked?
2. Should the browser surface exempted connections in a settings panel (e.g., "Connected local devices") for transparency without friction?
3. Would Private-Network-Access-ID / Private-Network-Access-Name headers be useful for that UI?

Related Issues & Specs

• WICG/private-network-access — Original preflight-based spec (superseded by LNA)
• WICG/private-network-access#41 — Timing attack concerns with preflights
• WICG/private-network-access#117 — Preflight origin trial feedback
• LNA Explainer — Rationale for permission-based approach (see "Considered Alternatives")
• Chrome Intent to Ship — Shipping details
• LNA Spec §1.2 — "This spec does not attempt to make it easier to use HTTPS connections on local network devices" (we solved this independently)

[christhompson]

I don't understand how this holds:

User unawareness | The user physically installed the device and configured their ERP to use it

What signal does the browser have that the user actually consents to this communication? This is the fundamental problem with the various proposals around allowlisting, etc. and was a lingering concern that the original PNA proposal had.

But those OS-level permissions are per-application, persistent, and one-time — they aren't reset by OS updates or profile changes.

Could you expand on the issues you have with browser permissions? Even Firefox has the ability to persist a permission decision (they just choose to make it not the default, unlike Chrome).

[ChrisEdgington]

---

Thanks for the quick response.

On user awareness:

What signal does the browser have that the user actually consents to this communication?

The browser doesn't have a direct signal — but I'm not sure it needs one. The user bought the device, plugged it into their network, and configured their ERP to talk to it. The device proves its identity with a publicly-trusted cert and explicitly opts in via preflight.

The preflight is the key part: the device decides which origins it will talk to. A malicious site can try to connect, but the device won't return Access-Control-Allow-Private-Network: true for origins it doesn't recognize. The user configured the trust relationship in the ERP; the device enforces it in the protocol. What's left for the browser to confirm?

On permission persistence:

Even Firefox has the ability to persist a permission decision

Fair point — Chrome persists, Firefox can. The problem isn't that persistence is impossible, it's that it's fragile for my users: switching browsers, work vs. personal profiles, clearing site data, IT pushing new profiles.

I get that these might seem like edge cases, but in environments with no IT support, even occasional friction creates real support burden. Enterprise policy exists as an escape hatch for managed environments. There's no equivalent for the small businesses I work with — and that's the gap I'm trying to address.

TLS+preflight sidesteps this because the authorization is in the protocol itself, not in browser storage that can get wiped or fragmented.

[ChrisEdgington]

---

To give you a concrete example of the support burden:

User clears their cache or gets a new browser. They try to print from their ERP, the permission prompt pops up, they're in a hurry clicking around, and they accidentally hit "deny." Now printing is broken and they have no idea why.

A non-technical user isn't going to know to click the icon in the address bar and reset permissions for that origin. They're going to call me and say "ProxyBox stopped working, I can't print anymore."

That's the kind of thing enterprise policy solves for managed environments. There's no equivalent for the small businesses I work with.

[chen970701]

This use case is very similar to one I previously reported in #61 .

We also have a web app + desktop companion app communicating over localhost, and after LNA shipped we saw massive user confusion and complaints that “it suddenly stopped working.” Many non-technical users instinctively click “Deny” and then have no idea how to recover.

[tresf]

Related:

• Next steps for local HTTPS #83

What signal does the browser have that the user actually consents to this communication? This is the fundamental problem with the various proposals around allowlisting, etc. and was a lingering concern that the original PNA proposal had.

Smells a lot like this discussion:

• Use case for WebSocket communications #16 (comment)

The TL;DR of it is -- from what I can understand -- SSL certs are (perceivably) too easy to obtain now to make this trustworthy. I'm in the exact same boat as @ChrisEdgington on this one because I've expressed exhaustively that it's not the browser's duty to determine one form of SSL is "more secure" than another. #83 linked above does offer some solace, but from what I can tell it's an adjacent task and one that's not yet clear enough to make any sort of technical decision on.

rant: Browsers asked for SSL everywhere, good apps complied, good apps are punished. 😰

[ChrisEdgington]

With SSL cert lifetimes dropping to 47 days by 2029 - nobody will be manually generating and installing certs anymore. Anything using SSL will have to be automatic.

[ylemkimon]

I don't think a trusted certificate would add any value over a self-signed cert; e.g., in the case of OP, the attacker can just extract the certificate from their installation. However, since it's easy to get one and verify one, I don’t see why not.

[ChrisEdgington]

I don't think a trusted certificate would add any value over a self-signed cert; e.g., in the case of OP, the attacker can just extract the certificate from their installation. However, since it's easy to get one and verify one, I don’t see why not.

Can you help me understand the attack you're envisioning?

The certificate is public by design — that's how TLS works. You can extract it from any HTTPS server just by connecting to it. The critical piece is the private key, which never leaves the device. The device itself is secured by its own SSH keypair for administrative access.
Each device gets its own hostname and cert, so extracting a cert from one device doesn't help attack another. And without the private key, you can't impersonate the device or MITM traffic to it.

Are you thinking about a supply chain attack where someone extracts the private key from hardware? Or a scenario where the attacker owns the device themselves?

[tresf]

Can you help me understand the attack you're envisioning?

The certificate is public by design

Perhaps @ylemkimon meant "private key", not "certificate" in this context?

I don't think a trusted certificate would add any value over a self-signed cert;

Can you expand on this please? Do you just mean in regards to local HTTPS in general (e.g. #83 ?)

you can't impersonate the device or MITM traffic to it.

Hmm... To be fair, it's rather trivial to impersonate a local IP address however I agree that MITM is much less likely to occur / achieve as it generally requires a compromise on the root level, which isn't what we're talking about here.

[tresf]

Thinking out loud here... I wonder if what this spec needs is origin-side whitelisting... That way the website itself can mark LNA as safe... e.g. Amazon knows it wants to talk to QZ Tray, let Amazon say that in the headers (in some ways, similar to the old PNA spec, but from the origin too). Heck, we can even raise the dialog, but instead of interrupting at time of connection, raise when the header comes through, like a website that wants to show notifications. That way we can get the prompt out of the way early. Would WICG be receptive to a request from origin? I'm really trying to think outside of the box here... (because the current solution is pretty detrimental to the end users) :/

[ylemkimon]

Sorry, I was just thinking strictly in terms of local network access. I think the requirement spec can just be valid HTTPS + preflight, not publicly trusted cert + preflight.

[christhompson]

The browser doesn't have a direct signal — but I'm not sure it needs one. The user bought the device, plugged it into their network, and configured their ERP to talk to it. The device proves its identity with a publicly-trusted cert and explicitly opts in via preflight.

The preflight is the key part: the device decides which origins it will talk to. A malicious site can try to connect, but the device won't return Access-Control-Allow-Private-Network: true for origins it doesn't recognize. The user configured the trust relationship in the ERP; the device enforces it in the protocol. What's left for the browser to confirm?

"Configured their ERP" is not a trustable signal and there's no way for the browser to know this, unfortunately. Ultimately, there must be a step of getting user consent (either at the point of use via the permission prompt, or ahead of time configuration such as via chrome://settings/content/localNetwork in Chrome).

[christhompson]

User clears their cache or gets a new browser. They try to print from their ERP, the permission prompt pops up, they're in a hurry clicking around, and they accidentally hit "deny." Now printing is broken and they have no idea why.

If I'm understanding you correctly, the problem here is that you don't control the ERP in this scenario, which means you can't update it to correctly check for the LNA permission status, show remediation UI, etc. Have you filed bug reports with these ERP vendors?

[tresf]

correctly check for the LNA permission status

Can we all agree that detection is rubbish?

• Detect permission state #69 (comment)

Unusable and no sign of changing, quoting:

If prompt were reported accurately, we could simply query this! Currently prompt is an unreliable placeholder since there are scenarios that it won't ever prompt and just succeed. This is a major bug in the implementation if developers are ever expected to rely on this.

[...] the state of this policy must influence the behavior of the permission check if we wish ever wish to offer sane detection around this.

I can't find a way to detect the difference between a failed connection and a blocked connection, making it impossible to support in the field.

This is a feature!

This mindset of calling a bug a feature is senseless and immoral because it causes countless developers to spin their wheels for hours in search of something that's deliberately broken. prompt is NOT the state. Maybe unknown is the state, but it's DEFINITELY NOT prompt.

[tresf]

the problem here is that you don't control the ERP in this scenario

As an aside, I find this so condescending and presumptuous. Who said we can't control anything on the origin?

To answer this, NO, we CAN control the "ERP" by asking the website devs to make changes. Since these comms are initiated by JS APIs (some even updated via npm) the companies that support these websites/LNA coms are VERY receptive to changes, but there's just no way to gracefully handle this. I'm really not sure how to better explain this... In my case, millions of PCs will get a prompt for something that the websites deliberately chose and the end-users deliberately installed and there's no way to prepare for this other than creating PSAs like @christhompson has done here for a very similar use-case.

I know there are technological hurdles for these asks, but there's also some presumptuous hurdles (such as the above comment) and if the WICG has any interest in keeping the rich ecosystem -- that the browsers have created -- thriving, it would be a good start to stop being talked down upon. I understand that we're all here to complain... but we're also here to help test and provide useful ideas to make this experience better.