This experiment evaluates the impact of changing the per-profile TCP socket pool size from 256 (the current default), down to 255, and up to 257, 512, and 1024 (possibly at 1-2 numbers between those based on findings). We will study the performance impact of these changes in stages, starting with 255 and 257. If no ill effects are seen, 512 will be evaluated and then 1024 after that. We expect that some platforms (e.g., mobile or older OS versions) will have to drop off as we get to the 512/1024 experiments. We will study changes to both normal and websocket pool global limits, but will not touch the per-host or per-proxy limits. This experiment will not be rolled directly into a full launch, but rather evaluated for use in a future experiment that attempts to partition the TCP socket pool to mitigate a network traffic timing attack. See the motivation section for more.
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, 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. In order to address this sort of attack, some sort of partitioning of the TCP socket pool will be needed, but this means changing the amount of sockets available across a profile, to a given frame/tab/top-site, or both. This experiment seeks data on the feasibility of such changes so a followup experiment can be done that focuses on the impact of partitioning without also having to use it to evaluate the impact of global socket pool size changes. This sort of attack is outlined in more detail here: https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/