v144 · security · demo

Attack Scenario

See the concrete threat that LNA WebTransport restrictions mitigate: a public webpage silently probing your home router or IoT devices via WebTransport. Then compare the blocked attack to a legitimate same-network use case where the permission prompt makes the connection safe.

simulation The attack and legitimate flows below are interactive simulations. The "Try it live" panel at the bottom actually calls new WebTransport() against a private address so you can observe Chrome 144’s real error response.
Requester: attacker.example (public) Target: 192.168.1.1:8080 (private) Result: blocked
attacker.example  →  new WebTransport("https://192.168.1.1:8080")
                    ↓ LNA check: public → private → BLOCKED
                    Chrome  rejects — no packet reaches router
    Step 0 of 5
    Connection Blocked — Attack Mitigated
    Requester: 192.168.1.100 (private) Target: 192.168.1.50:8080 (private) Result: prompt shown, connection proceeds
    192.168.1.100 (local app)  →  new WebTransport("https://192.168.1.50:8080")
                                      ↓ LNA check: private → private → same space
                                      Chrome  proceeds with QUIC handshake
      Step 0 of 4
      Connection Established — Printer Connected

      Try it live

      This panel actually calls new WebTransport() against a private-network address in your browser. In Chrome 144+ with LNA enforced, the connection is blocked with a SecurityError or NotAllowedError before any packet leaves. Try different addresses to observe the classifier in action.

      Click “Attempt WebTransport” to run the live test — the error Chrome returns is displayed here.

      Attack surface without LNA restrictions

      Without Local Network Access restrictions, any public webpage could silently probe and exfiltrate data from devices on your home or office network via WebTransport. Chrome 144 blocks all four of these vectors from public origins.

      Device type Typical private address Attack via WebTransport LNA blocks
      Home router / gateway 192.168.1.1, 192.168.0.1 Read admin config, inject routes, exfiltrate SSID / passwords Blocked (public → private)
      IoT device (camera, thermostat) 192.168.1.x, 10.0.0.x Send commands, stream sensor data to attacker, pivot to other devices Blocked (public → private)
      Network printer 192.168.1.50, printer.local Read print queue contents, dump config including credentials, trigger prints Blocked (public → private)
      Local dev server / intranet 127.0.0.1, localhost, 10.0.x.x Access internal APIs, read source code served on localhost, bypass auth Blocked (public → loopback / private)

      what Chrome does at the network layer

      The LNA check happens before the QUIC handshake begins. Chrome classifies both the requesting origin’s address space and the target address space. If the target is in a more private address space than the requester, the connection is rejected immediately — no DNS lookup, no TCP/UDP packet, no TLS ClientHello reaches the device. The attacker gets an exception; the target never knows it was probed.

      // What attacker code looks like
const wt = new WebTransport("https://192.168.1.1:8080");
try {
  await wt.ready;  // never resolves for public -> private
} catch (err) {
  // err.name === "SecurityError"  (or NotAllowedError)
  // err.message contains "Local Network Access"
  // The router received zero packets.
  console.error(err.name, err.message);
}

      see also