Exciting experiment! LGTM. Do you have plans to publish your results?
On Monday, September 15, 2025 at 9:45:35 AM UTC-7 Ari Chivukula wrote: > Contact emails > > aric...@chromium.org, awil...@chromium.org, a...@google.com, > miketa...@chromium.org > Explainer/Specification > > None > > Summary > > This experiment evaluates the impact of changing the per-profile TCP > socket pool size from 256 (the current default > <https://source.chromium.org/chromium/chromium/src/+/main:net/socket/client_socket_pool_manager.cc;drc=8b81608b6457dfef865f46e509c79dc60fe3c69b;l=35>) > > to 513 while adding a per-top-level-site cap of 256 (to ensure no two tabs > can exhaust the pool). The feasibility of raising the per-profile limit > to 512 was already studied > <https://groups.google.com/a/chromium.org/g/blink-dev/c/1r-i4Koc5nM?e=48417069> > > and did not yield negative results, and the per-top-level-site cap of 256 > is equal to the current per-profile limit so should not cause negative > impact. These new limits will be imposed independently for the WebSocket > pool and the normal (HTTP) socket pool. > > > The intent is to roll this experiment directly into a full launch if no > ill effects are seen. See the motivation section for more. > > > Blink component > > Blink>Network > <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ENetwork%22> > > TAG review > > https://github.com/w3ctag/design-reviews/issues/1151 > > > 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. 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 will cap the max sockets > per-top-level-site while raising the per-profile limit. That means no > single tab can max out the socket pool on its own. While this mitigation > does not fully block the attack (it could still be performed by > orchestrating three attacking tabs on different sites) it raises the > difficulty by preventing it from being performed by just one tab. > Widespread adoption of this attack is already made difficult as multiple > attackers all acting at once would step on each other and prevent pool > monopolization. > > 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 (256 -> 513) > 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: https://github.com/mozilla/standards-positions/issues/1299; > current global cap of 128-900 > <https://github.com/mozilla-firefox/firefox/blob/4bd4e4c595499ee51c2e6f4c9f780fe720f454e8/modules/libpref/init/all.js#L1138> > > (as allowed by OS) > > WebKit: https://github.com/WebKit/standards-positions/issues/550; current > global cap of 256 > <https://github.com/WebKit/WebKit/blob/d323b2fc4cd2686c828bd8976fae6ec2d2b6311c/Source/WebCore/platform/network/soup/SoupNetworkSession.cpp#L104> > > Debuggability > > This will be gated behind the base::feature > kTcpConnectionPoolSizePerTopLevelSiteTrial, so if breakage is suspected > that flag could be turned off to detect impact. For how to control feature > flags, see this > <https://source.chromium.org/chromium/chromium/src/+/main:base/feature_list.h;drc=159a65729cf8fca4d9f453d12d97ab6515360491;l=259> > . > > Measurement > > A new net log event type > SOCKET_POOL_STALLED_MAX_SOCKETS_PER_TOP_LEVEL_SITE will be added to track > when we hit this new limit as opposed to the existing > SOCKET_POOL_STALLED_MAX_SOCKETS event. > > An existing metric 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 > > TcpConnectionPoolSizePerTopLevelSiteTrial > > Rollout plan > > We will never test more than 5% 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 > > 142 > > Link to entry on the Chrome Platform Status > > https://chromestatus.com/feature/6496757559197696 > > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5b44a370-bfd7-4a9b-9f2e-7f2b7fb74f94n%40chromium.org.
