demo · v139 · network

Connection Pool Monitor

Model the Chrome 139 experiment that changes the per-profile TCP socket pool from the 256 default to nearby and larger caps. The experiment is internal to networking code, so this page pairs a safe simulation with live Resource Timing evidence from same-origin fetches.

There is no JavaScript setter for Chrome's TCP socket pool. The controls below simulate the global pool sizes named by ChromeStatus, keep per-host and per-proxy limits unchanged, and show why a fixed shared pool can leak cross-tab request timing when an attacker saturates the pool.

observable contracts

pool experiment controls

pool model

current result

256 global cap
14 victim requests
0ms attacker probe delay
idle leak verdict
0 queued sockets
6 per-host limit unchanged

socket pool slots

The visual caps at 96 rendered slots for readability; values above that are summarized in the metrics and readout.

attacker-held victim requests attacker probe available or elided

shared pool vs partitioned outcome

Shared profile pool

This mirrors the XS-Leak shape: an attacker fills the profile-wide pool, opens the victim, then times whether a probe socket waits for the victim to release a slot.

probe delay 0ms
leak signal 0%

Partitioned future model

Partitioning is the follow-up direction ChromeStatus calls out. The attacker's sockets no longer share the victim's partition, so the probe delay stops encoding victim request count.

probe delay 0ms
leak signal 0%

timing history

Each attack run appends the simulated shared-pool delay, partitioned delay, and same-origin Resource Timing duration when a live probe has been run.

safe Resource Timing probe

The feature is internal, but Resource Timing is the web-exposed way to inspect connection reuse and connect timing. This probe fetches this site's favicon with a cache buster, then reports the browser's resource timing fields.

No Resource Timing probe run yet.

simulation readout

No attack run yet.

references