This is something Google pushed, so that Google can have as many tracking cookies as they like when you browse the internet, without the cookies causing a noticeable performance degradation because a http request might exceed the American DSLs MTU size.
This was one of the primary engineering criterias. No really.
I've only begun to study the protocol, but some things in the privacy section do concern me. Particularly:
HTTP/2's preference for using a single TCP connection allows correlation of a user's activity on a site. Reusing connections for different origins allows tracking across those origins.
Imagine a home or business where devices are configured for some privacy (cookies and various other things generally blocked) and the machines are communicating through a NAT or Gateway/Proxy. Wouldn't reused connections represent a unique threat in terms of allowing (third-party) websites to discern the behavior of individual machines and users?
Perhaps my understanding is way off, but I don't think it's possible to reuse a connection across different origins (unless perhaps the IP address of the server was the same for those origins)
Clients SHOULD NOT open more than one HTTP/2 connection to a given host and port pair, where the host is derived from a URI, a selected alternative service [ALT-SVC], or a configured proxy.
suggests to me that if you have TopLevelOrigin1 open and TopLevelOrigin2 open, and they both embed content from ThirdPartyOriginA, you'd (likely) have only ONE connection to ThirdPartyOriginA. I thought that would be an example of "reusing connections for different origins", and there would seem to be a correlation risk.
I was thinking that the "one connection per host:port" would (normally) be based on host NAME. However, your comment and the fourth paragraph in 9.1 Connection Management leaves me thinking that it could (optionally) be based on resolved IP Address.
To further complicate things, Alt-Svc can redirect requests to a different host. So HTTPS requests to TopLevelOrigin1 and TopLevelOrigin2 could all go to example.com and its IP Address.
Maybe a (welcomed!) reply will help clarify the correlation risk scenarios. I'll also search for prior discussions about it.
That doesn't increase the correlation risk, since the same could be done today with TLS session IDs or session tickets: even if you open more than one connection to the third party, your browser will attempt to reuse the same TLS session for performance reasons (it shortens the handshake and avoids expensive public key calculations).
On the flip side, the use of TLS means that connections to different origins must be kept separate, even with Alt-Svc. If I'm reading https://tools.ietf.org/html/draft-ietf-httpbis-alt-svc-06 correctly, "example.com" MUST present the certificate for TopLevelOrigin1 or TopLevelOrigin2, which obviously requires a separate TLS handshake and thus a separate TLS session for each one.
I appreciate you mentioning the Session ID and Session Ticket scenarios. Those can be disabled though, correct? HTTP/2 over cleartext TCP is also possible? Maybe still some increase in correlation risk due to those?
Do you think the Alt-Svc scenario we are talking about would guarantee two separate HTTP/2 connections?
> I appreciate you mentioning the Session ID and Session Ticket scenarios. Those can be disabled though, correct?
Yes, the server can ignore both and always start a new session. And you could modify a client to never send either, but if you are already modifying the client code you could also modify it to always use a separate connection.
> HTTP/2 over cleartext TCP is also possible?
In theory yes, in practice most will only implement it over TLS, to avoid middleboxes breaking it. TLS-intercepting middleboxes won't negotiate HTTP/2, so it'll fallback cleanly in that case.
> Do you think the Alt-Svc scenario we are talking about would guarantee two separate HTTP/2 connections?
Alt-Svc to a different hostname will always use TLS. From the draft: "Clients MUST NOT use alternative services with a host that is different than the origin's without strong server authentication; this mitigates the attack described in Section 9.2. One way to achieve this is for the alternative to use TLS with a certificate that is valid for that origin."
And with current TLS, the hostname is sent on the handshake (SNI), so it can't use the same session for different hostnames.
I think the security.ssl.disable_session_identifiers pref in Gecko browsers is meant to allow for it without modifying the code, and I haven't spotted a similarly easy way of controlling HTTP/2 connections. Otherwise, point taken.
Is there anything we haven't discussed that would fall within the HTTP/2 spec's "Reusing connections for different origins allows tracking across those origins." warning?
The HTTP protocol will have nothing to do with making UI/UX better. People will continue to write ones that are unintuitive, resource intensive, unnecessarily complex, and utterly stupid because they can.
This is something Google pushed, so that Google can have as many tracking cookies as they like when you browse the internet, without the cookies causing a noticeable performance degradation because a http request might exceed the American DSLs MTU size.
This was one of the primary engineering criterias. No really.
There's no features in it for the user.