demo · v141

IoT Discovery

A common but legitimate-looking pattern: scan the /24 subnet for IoT devices (printers, smart speakers, NAS units). Same pattern as the network-fingerprinting attack the spec calls out — sites mapping your local network without consent. Run the scan and watch every probe land in the same "needs LNA permission" bucket.

Heads up Requires Chrome 141+. The fingerprint attack the spec warns about works exactly like this: send probes, time the failures, infer which addresses are live. The mitigation is the same permission gate as the CSRF case — sites can't even tell what's on your network without prompting first.
checking support…
no scan yet

the (now-failing) fingerprint

// Pre-141 fingerprinting trick: time how fast each address rejects
const addrs = Array.from({length: 256}, (_, i) => `http://192.168.1.${i}/`);
const results = await Promise.all(addrs.map(async (url) => {
  const t0 = performance.now();
  try { await fetch(url, { mode: "no-cors", signal: AbortSignal.timeout(500) }); }
  catch {}
  return [url, performance.now() - t0];
}));
// On 141+, every probe fails with the same TypeError shape before
// the request leaves the browser. No timing oracle.

why this angle

The WICG explainer lists "network fingerprinting prevention" as a goal alongside CSRF prevention. They are different attacks: CSRF needs one specific live address to compromise; fingerprinting just needs to know which addresses are live so the attacker can match the user to a household, a device set, or a corporate network they've seen before. Without the LNA gate, both attacks share the same primitive — fire requests, observe responses (or response timing). With the gate, neither completes silently. This concept fires the fingerprint pattern explicitly so you can see Chrome refuse uniformly.

see also