#1151: Other Spec Review: TCP Socket Pool Limit Randomization
Discussions
Log in to see TAG-private discussions.
Comment by @jyasskin Sep 15, 2025 (See Github)
Are you going to try to specify or standardize this? At first glance, this looks like a change to one implementation's implementation-defined behavior, and we don't normally review those.
Comment by @arichiv Sep 16, 2025 (See Github)
Ah, fair enough. I'm not sure this fits in existing specs, but it's a privacy/security issue cross-browser so I thought there might be interest. If this is the wrong venue this can be closed out.
Discussed
Oct 13, 2025 (See Github)
Lola: We closed this as too early earlier this week.
Comment by @ylafon Oct 13, 2025 (See Github)
We support the goal of limiting timing attacks as outlined in the explainer. We also noted in the discussions with other vendors that the issue is shared but solutions might differ, so we think it is too early to provide a review.
Comment by @arichiv Oct 15, 2025 (See Github)
Note that this was updated to reflect a change in approach to randomization instead of partitioning
OpenedSep 15, 2025
Where and by whom is the work is being done?
Feedback so far
You should also know that...
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.
<!-- Content below this is maintained by @w3c-tag-bot -->Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1151