By exploiting limits in the connection pool size on Chrome, knowledge can be gained about cross-site state which would otherwise be inaccessible. Specifically, it’s possible (with some statistical certainty) to evaluate the login state, visited history, or even something more specific like whether gmail has pending messages in the inbox. To mitigate this we are adding randomization to the way that TCP socket pools are limited so that an observing site cannot infer this information with high certainty.
Having a fixed pool of TCP sockets available to an entire profile allows attackers to effectively divinate the amount of network requests done by other tabs/frames, and learn things about them to the extent that any given site can be profiled. For example, if a site does X network requests if it’s logged in and Y if it’s logged out, by saturating the TCP socket pool and watching movement after calling window.open, the state of the other site can be gleaned. This sort of attack is outlined in more detail here: https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/ In order to address this sort of attack, we randomize the points at which a socket pool is considered to be full and the point at which it subsequently can be considered sufficiently drained to allow new allocations. We don’t want sites to be able to detect the point at which the pool becomes full without triggering a drain, and vice-versa. The probabilistic allocation of sockets when we are approaching the chosen upper bound and delaying allocations until the randomized lower bound ensures this, and even makes it difficult for a site to walk all the way up to a known maximum socket count on the assumption the final socket use will cause a drain.