LGTM to run an experiment in 139
/Daniel
On 2025-06-18 17:18, Ari Chivukula wrote:
Contact emails
aric...@chromium.org <mailto:aric...@chromium.org>,
awil...@chromium.org <mailto:awil...@chromium.org>, a...@google.com
<mailto:a...@google.com>, miketa...@chromium.org
<mailto:miketa...@chromium.org>
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
<https://source.chromium.org/chromium/chromium/src/+/main:net/socket/client_socket_pool_manager.cc;drc=8b81608b6457dfef865f46e509c79dc60fe3c69b;l=35>),
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
<https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ENetwork%22>
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/
<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
<https://github.com/mozilla-firefox/firefox/blob/4bd4e4c595499ee51c2e6f4c9f780fe720f454e8/modules/libpref/init/all.js#L1138>(as
allowed by OS)
WebKit:Currently 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
kTcpConnectionPoolSizeTrial, 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
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 <https://crbug.com/415691664>
Estimated milestones
139
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5182293874049024
<https://chromestatus.com/feature/5182293874049024>
--
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/CAGpy5DJuOcukaf_t9L7v3P8R8BpOe%3D2xY-vna369yj2gAEkgAw%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGpy5DJuOcukaf_t9L7v3P8R8BpOe%3D2xY-vna369yj2gAEkgAw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
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/65d517a0-6384-4885-ad20-02351704e662%40gmail.com.
