HTTP2 -- does disabling do more harm than good?

[RoxKilly]

Prefs 2614 and 2615 disable SPDY and HTTP2.

user_pref("network.http.spdy.enabled", false);
user_pref("network.http.spdy.enabled.deps", false);
user_pref("network.http.spdy.enabled.http2", false);

The link reference leads to a Tor project page that doesn't give much info about what's wrong with these protocols:

SPDY and HTTP/2 connections MUST be isolated to the URL bar domain. Furthermore, all associated means that could be used for cross-domain user tracking (alt-svc headers come to mind) MUST adhere to this design principle as well.

Does anyone understand (1) how exactly SPDY/HTTP2 expose users' privacy more than HTTP1 and (2) whether there is any evidence of harm in the wild?

I bring this up because disabling SPDY/HTTP2 has significant downsides. We may not care that these protocols drastically reduce overhead (header data sent back and forth) and speed up browsing, but we should care that they protect against a real ongoing threat to privacy.

I'm specifically talking about what ISPs call "Header Enrichment": the growing trend in altering customer traffic on the fly, tagging it with unique identifiers to make users easier for advertisers to track regardless of browser settings. In the US, AT&T, Verizon and Comcast have all be caught doing this. Here's a great article on the practice. Below I quote the last paragraph:

Google has proposed a new Internet protocol called SPDY that would prevent these types of header injections – much to the dismay of many telecom companies who are lobbying against it. In May, a Verizon executive made a presentation describing how Google's proposal could "limit value-add services that are based on access to header" information.

Here is evidence of telecom industry's displeasure with SPDY (scroll down to see the News section). So we have a growing privacy abuse that is actually becoming standard in the telecom industry, but one that SPDY/HTTP2 protect against. Not only that, but these protocols protect against a class of attacks that use header traffic analysis to unmask user activity. Here is an example of another privacy attack that wouldn't work with SPDY/HTTP2. From the article:

Note also that the recipes in here apply to HTTP/1.0 and HTTP/1.1 only, no HTTP/2.0.

So my basic question is: Are we disabling HTTP2/SPDY with a full understanding of the privacy implications of both sides of the coin? I think actual, ongoing threats outweigh theoretical ones, especially when the ongoing threats are becoming industry standard practice

EDIT - resources

• The HTTP/2 spec
• A simple explanation of the protocol
• A basic FAQ

[Thorin-Oakenpants]

I'm bundling both HTTP/2 and AltSvc

Not only that, but I think SSL session ticket ids is closely related. The thing is TBB is different - it uses tor and changes circuits (I'd have to check now, but it used to be every 10 minutes)

[ghost]

You're right, I didn't think of that. But I can't see any reference to it in both the HTTP/2 and AltSvc audits, perhaps I should ask someone in the TBB dev community for a quick explanation? Maybe the patches Mozilla applied to the protocols not only protect TBB but also Firefox releases. Any idea how to contact the devs about such a specific issue? Also should I continue discussing this here or in #491?

[Thorin-Oakenpants]

maybe start a new topic "Investigate: SSL + HTTP2 + AltSrv" - this thread is rather long, and 491 is for something else (I'll use it to do a TBB vs ghacks diff when TBB ever gets a final 8, it's still a huge mess IMO). It would be kinda cool to know if SSL session tickets are required for HTTP2 and AltSrv, because that's the overriding factor in even allowing them in the first place. Currently FF only wipes SSL sessions on FF (or last PB mode) close, otherwise it allows up to 2 days (and I'm not sure if it respects that, eg if a site says the id is valid for 5 days, what does FF do, and vice versa if the site says its shorter)