[whatwg/fetch] Double-keyed connection pools (#917)

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**](https://fetch.spec.whatwg.org/#concept-connection) to false for third-party requests, for privacy reasons, and allows **credentials** to be defined based on the [**credentials mode**](https://fetch.spec.whatwg.org/#concept-request-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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/917