TCP Socket Pool Limit Randomization

[arichiv]

Title of the proposal

TCP Socket Pool Limit Randomization

Issue Tracker URL

https://crbug.com/415691664

TAG Design Review URL

w3ctag/design-reviews#1151

Mozilla standards-positions issue URL

mozilla/standards-positions#1299

Chromium Position

https://chromestatus.com/feature/6496757559197696

Description

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.

[annevk]

What about UDP?

Specification-wise it seems the most straightforward thing to do would be to partition the connection pool concept in https://fetch.spec.whatwg.org/#connections which would then allow us to remove the partitioning on individual connections.

(Also gives rise to the question of what a map of connection pools is called. A connection pool complex? A connection natatorium?)

[arichiv]

UDP is an interesting question, is that just for WebRTC (when it comes to renderer initiated connections)?

As for a pool of pools, maybe reservoir?

[annevk]

It's for HTTP/3 as well (by way of QUIC).

[arichiv]

Note that this was updated to reflect a change in approach to randomization instead of partitioning