Intent to Experiment: Re-Sizing TCP Connection Pool

Contact emails

[email protected], [email protected], [email protected], [email protected]

Explainer

None

Specification

Not yet

Summary

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.

Blink component

Blink>Network

TAG review

None

TAG review status

Not applicable at this stage, will ask for review when we have a partitioning scheme to solicit feedback on.

Motivation

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/

Risks

Interoperability and Compatibility

While other user agents may wish to follow the results, we only anticipate compatibility issues with local machines or remote servers when the amount of available TCP sockets in the browser fluctuates up in a way Chrome did not allow before. This will be monitored carefully, and any experiment yielding significant negative impact on browsing experience will be terminated early.

Gecko: Currently 128-900 (as allowed by OS)

WebKit: Currently 256

Debuggability

This will be gated behind the base::feature kTcpConnectionPoolSizeTrial, so if breakage is suspected that flag could be turned off to detect impact. For how to control feature flags, see this.

Measurement

Net.TcpConnectAttempt.Latency.{Result} will be used to detect increases in overall connection failure rates.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

No, not WebView. That will have to be studied independently due to the differing constraints.

Is this feature fully tested by web-platform-tests?

No, as this is a blink networking focused change browser tests or unit tests are more likely.

Flag name on about://flags

None

Finch feature name

kTcpConnectionPoolSizeTrial

Rollout plan

We will never test more than 1% in each group on stable, and will stay on canary/dev/beta for a while to detect issues before testing stable.

Requires code in //chrome?

No

Tracking bug

https://crbug.com/415691664

Estimated milestones

139

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5182293874049024