demo · v143
XS-leak replay
The attack the feature defends against, in code. We simulate two browsers — fixed pool (pre-v143) and randomised pool (v143) — and run the xsleaks.dev connection-pool attack against each. The randomised one's signal collapses.
simulation parameters
pre-v143 (fixed pool = 6)
—%
attacker's accuracy at guessing victim state
v143 (pool = 6 ± random)
—%
attacker's accuracy at guessing victim state
Click Run attack to compare the two distributions.
the attack
// xsleaks.dev/connection-pool: saturate the TCP socket pool,
// open the victim site in a new tab, count how many of *your*
// requests queued (because the victim took some sockets).
// Pre-v143: pool size is constant (6). Attacker subtracts their
// observed concurrency from 6 to learn how many requests the
// victim issued → infers state (logged in / out).
// V143: each new pool gets a random adjustment, so the attacker's
// per-trial measurement is noisier than the per-state delta.
why this angle
The other concept animates the queueing behaviour. This one reproduces the actual cross-site leak (xsleaks.dev catalogue's connection-pool attack) and quantifies how much accuracy the attacker loses with randomisation. That's the security bar v143 has to clear.