Double-keyed connection pools

[sleevi]

Related to #904, the idea here is that user agents make connections conditionally based upon not just the destination origin, but on the initiating/'top level' origin.

For UAs that implement #904 for privacy-preserving reasons, failed to also implement the same for connection pools allows for the easy re-establishment of identifying information.

Consider a UA that sets credentials to false for third-party requests, for privacy reasons, and allows credentials to be defined based on the credentials mode otherwise.

• When the UA visits https://a.example, and https://a.example attempts to load https://b.example/tracker, the parameters for the connection to b.example are { "https://b.example", false}.
• When the UA visits https://b.example as a navigation, the parameters for the connection to b.example are {"https://b.example", true}.
• However, b.example can use the local storage it has (e.g. LocalStorage, cookies, etc) and can initiate a request with the fetch() credentials mode of omit, for https://b.example/setUserId?id={some identifier}. This connection will be initiated as {"https://b.example", false}.

If the connection is reused between the fetch in the context of a.example and b.example, then the information from b.example may be linkable on the server to the request in a.example, and may even be used to set responses or storage in the context of a.example (e.g. a response that a.example then uses to set an a.example cookie for b.example's ID)

Broadly speaking, partitioning the HTTP cache, as described in #904, can not be reasoned to have any privacy-enhancing properties in the absence of also partitioning the connection pool on the same key. Any collapsing of key or state between the fetch and the connection, from something finer grained to something coarser, ensures that the finer-grained separation cannot be reasoned to actually work.

[annevk]

I think it makes sense to do this for anti-tracking purposes and Firefox will likely do this. This should be relatively straightforward to add once #904 is fixed.

Note that the partitioning of the HTTP cache has another motivation, namely thwarting XSLeaks-style of attacks (except for those through popups, sites will need to use COOP to thwart those). Those seem slightly less applicable here, though perhaps timing attacks on connection setup are feasible? (There is also a connection exhaustion attack, due to there being a global limit.)

[sleevi]

Correct. We are aware that you can use resource exhaustion - including at the OS level - to mount XSLeaks-style attacks. This does not mitigate such attacks.

[shivanigithub]

/cc @MattMenke2

[MattMenke2]

Worth noting that in addition to socket pools (including proxy connections), other things that need to be double-keyed:
SSL/QUIC session caches, H2/QUIC sessions, reporting (Need to key information on where to report, and reports to upload, and then use the key when uploading the reports), everything that feeds into reporting (expect-CT, for instance), and alternative service info.

Also related network stuff at a slightly higher layer: CORS requests and CORS cache (Chrome has a separate cache above the network stack for CORS responses, at least), and origin policy cache/fetches.

[MattMenke2]

Also, auth credentials and client certs. Sure I'm still forgetting stuff.

Edit: We'll presumably share credentials for proxy auth.

[sleevi]

@MattMenke2 It's unclear if we should use this bug for that, or treat them separate. When I suggested making #904 the bug for this, @annevk requested I split this out, to keep it narrowly focused. I appreciate that, and I wonder if it might make sense to similarly treat that separate here. At least within the Fetch mechanics today, we don't necessarily have infrastructure for all these other bits, or the implications that might be specific to each one.

@annevk Would you rather this be a catch-all bug for (double, triple)-keying for privacy, or keep this narrowly focused? Should we be creating a meta-bug for each of the keyed caches?

[annevk]

I'm okay trying to capture all the connection-related bits at once, but also fine with splitting them. Alt-Svc is another.