It's investigation time! HTTP/2, AltSvc and SSL

[ghost]

TBB enabled both HTTP/2 and Alternative Services on the release channel in September, following two audits : HTTP/2 and AltSvc.
It is indicated that these protocols no longer pose a threat to privacy when FPI is enabled.
Therefore, I suggest we consider commenting the related prefs (0702, 0703) and add a warning that they need FPI enabled to be safe, privacy-wise.
However, @Thorin-Oakenpants 👖 raised a fair point in #107:

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)

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)

As the title states, it's investigation time!
Does anyone know who we could reach out to to get an answer?
Could some experts share their insights on the matter?

P.S.: Now THIS would be a perfect issue for your "NEEDS JESUS" label, @claustromaniac! 🐈
Also, can I add the "help wanted" label or that restricted to the big E and 👖 ?

[Thorin-Oakenpants]

When I say closely related, I mean that they may be required, either technically or for any speed improvement (which IMO is the only reason for this). While HTTP2 allows for HTTP in the spec, it is not supported by the browsers, so for all intents and purposes, SSL is always used

https://en.wikipedia.org/wiki/Http2#Encryption

Although the standard itself does not require usage of encryption,[30] all major client implementations have stated that they will only support HTTP/2 over TLS, which makes encryption de facto mandatory

[Thorin-Oakenpants]

Here is a discussion I had with Tom Ritter (Mozilla) and Arthur Edelstein (Tor)

[Thorin-Oakenpants]

Part 1: get an definitive answer if SSL session ids are required

Does anyone know who we could reach out to to get an answer

Tor's IRC channel (but be prepared to lurk in there, it's not like users watch/read it 24/7).

I also have a "direct line" to Arthur & Tom. They tolerate me, but I feel like I must be a bit of a pest to them at times. They seem to be generous and never ignore me, but I do limit my pestering, as I know they are super busy.

I guess we should inspect the technical documents, or ask on a reddit /networking thread or something. Even r/tor .

---

Part 2: ask Firefox to reduce the SSL session id time (see email pic in previous post)

The thing is Tor doesn't really care about the length of these ssl session ids. If they are required (and TBB flipped all three for a reason), then because Firefox doesn't protect from it via new identities/circuits/nodes/guards or whatever you want to call it (like tor does), then we would have to appeal to Mozilla

PS: it would be nice to know or confirm if temporary containers wipe ssl session ids

[Thorin-Oakenpants]

PS: it would be nice to know or confirm if temporary containers wipe ssl session ids

Ignore that. If using TC, then each (new) container (contextid) already isolates them. Still would be nice to know if the API also includes this

#395 (comment) ( @stoically )

Temporary Containers only uses one API to remove data, and that is contextualIdentities.remove - which removes all userContextId tagged storage (including IDB). And even if it'd fail to do so, new contextualIdentities couldn't access the same data, since the cookieStoreIds (that's how the attribute is called in the API - it however refers to the userContextId used to OA-tag) are unique as long as the container feature is active.

So does this API cover SSL session ids (edit: for those cases where you keep/re-use a container)

[ghost]

@Thorin-Oakenpants
Part 1 : I'm registering to OFTC to get some answers on #tor-dev, I'll keep you posted.

Part 2 : Tom Ritter mentioned we should be asking Mozilla, and I read you weren't keen on opening a ticket yourself. Would you like me to open one with our current questions and your suggestions from the mail?
(I'm unfamiliar with the tracker, I'm completely new to this, but I learn at an okay speed so I could do that.)

On the matter of your "direct line", I completely understand you'd rather use it as little as possible, no worries there, we'll find the solution(s ?) together!

[Thorin-Oakenpants]

OFTC

WTF is that?

Tom Ritter mentioned we should be asking Mozilla

He is Mozilla :) Ethan's team is the Tor Uplift team, and since my proposals go beyond that, then all he was saying is that we would have to appeal to the higher ups. I see no problem with any of my logic - reducing to 30 or 60 minutes as per other major browsers.

The problem then becomes getting RFP or PB teams interested in reducing it to 10 minutes or even less (I want a pref and I can which I can set to 1 minute). And none of them are interested. PB mode because all data is destroyed on session end, and their mandate (despite the name) is not leaving persistent local data. And RFP because they have FPI. And Tor, because they are using a different protocol that changes nodes frequently and also have FPI. And all of them will say, but its a SSL session id, so closing the browser always clears it.

So having said all that, I don't think it's even worth my time to try and convince anyone. Reducing it to 30 or 60 minutes would be cool, but not enough to justify using it (for myself), and after that no one F cares

So it wasn't that I wasn't keen to open a ticket, but that by getting Tom to open it instead gives it more weight - but that didn't happen. As for you opening a ticket, I would rather you didn't. It needs to be worded correctly or it'll just get shut down. We don't need to ask questions, or mention RFP or PB mode - we aiming at a difference audience now. IF it was to happen, then after it lands, then we push for MOAR in RFP/PB mode. Let's chew on it for a while.

[ghost]

< Aeriem> Hello, I have a question on the handling of SSL tickets in regard to HTTP/2 and AltSvc, is this the right place to ask?

<+GeKo> Aeriem: not sure. maybe ask?
<+GeKo> those tickets are isolated to the url bar domain fwiw
<+GeKo> (not sure if that already answers your question :) )

< Aeriem> GeKo: In v8, TBB enabled both HTTP/2 and AltSvc (and SLL Tickets IDs) after audits that stated those protocols where safe (privacy-wise) when FPI was enabled. But 1) do these protocols requires SSL Tickets IDs to be enabled in order to work correctly and provide any speed improvement; 2) And did the TBB Team enabled those three techs because TBB doesn't really "care" about tickets IDs since they are wiped every 10 mins?
< Aeriem> GeKo: On vanilla Firefox, the SSL Tickets IDs are kept until browser closure or end of life of the ID, which could potentially be a privacy issue, and could require a ticket to FF bugtracker to ask for the possibility to wipe those every 10 mins via a pref
< Aeriem> GeKo: Also I assume you mean SSL Tickets IDs are affected by FPI when you say they are isolated to the url bar domain?

<+GeKo> Aeriem: yes, that's what i mean
<+GeKo> no, http/2 and altsvc don't require those tickets
<+GeKo> and, yes, http/2 in particular should give you speed improvements
<+GeKo> we noticed as well that some sites are even broken without having http/2 enabled
<+GeKo> i.e. they are alredy http/2-only
<+GeKo> regarding 2)
<+GeKo> those tickets are not necesssarily wiped every 10 minutes
<+GeKo> but their cross-domain tracking potential is neutered with first-party isolation
<+GeKo> we don't tackle possible tracking with session ids (or session resumption) by fist parties
<+GeKo> as a) there are plenty of things they can use which are much better tracking tools (like cookies)
<+GeKo> and more imortantly b) first parties are usually those parties the user wants to interact with
<+GeKo> against those we have the new identity feature that you could and should use once in a while
<+GeKo> to give you a new, clean tor browser state

< Aeriem> GeKo: Thank you for taking the time to answer, this was very helpful!
< Aeriem> GeKo: Just a precision: when I asked if HTTP/2 and AltSvc required SSL Tickets, I meant in the real world, not in the specs. I know they don't require it to work, but I read that many browser implemented the tech in a way that it only works over TLS connections, so is that something to consider?
< Aeriem> Also, I was asking if HTTP/2 would bring speed improvements without SSL tickets IDs enabled, not if it brought speed improvements in general, I worded my sentence poorly, sorry!

I'm waiting to get the answers to my last questions, feel free to suggest what I should ask if something bugs you.

From what I understand, those three protocols (HTTP/2, AltSvc, SSL Tickets IDs) are safe with FPI enabled, and even if first parties have access to the tickets, even TBB doesn't do anything against that (nothing is done every ten minutes when it comes to them, no deleting, no change of ID, even the change of node doesn't affect them), they just suggest to use the new identity feature once in a while, which would translate into closing FF sometimes for us.
All in all, the privacy issues rising from these doesn't seem very concerning, especially considering that even TBB finds it negligible, furthermore it is quite easy to counter by closing and reopening FF, what's your opinion?
At this (early) stage of the investigation, my suggestion is disabling the prefs relating to those techs, and add a comment like this:

If you disabled First Party Isolation (see 4001), consider disabling this protocol as it might leak some data without FPI.
special edit for HTTP/2: This protocol is progressively becoming more mainstream and some sites break without it because they are not available in HTTP/1 versions.

[ghost]

@Thorin-Oakenpants OFTC is the IRC to contact the Tor devs, at least that's what's written on their official contact page.
Also I understand better your current stance on the matter, thanks for the explanation!
Read my last comment and let's decide what we do about this in the user.js.

[Thorin-Oakenpants]

From what I understand, those three protocols (HTTP/2, AltSvc, SSL Tickets IDs) are safe with FPI enabled, and even if first parties have access to the tickets, even TBB doesn't do anything against that

Nope. If the session id hasn't expired, then you can be tracked by it. No one seems to give a F about repeat first party visits. Example:

• Am on VPN A: I do a google search
• Flip to VPN B: I do another google search

So seems even TBB don't give a sh^t unless you specifically request a new identity. I can't understand why there isn't a pref to set max lifetime to 1 or 10 minutes

[Thorin-Oakenpants]

I see no problem with making HTTP2 and AltSrv inactive, but session tickets remain a mess. We don't want half measures, we want proper solutions and expect worst case scenarios in our thinking. Seriously, I would have to close my FF and my 4 or 5 tabs, and lose my train of thought/work .. just to clear session ids. Bollocks. We need a better solution than "oh but FPI".

We have a better solution, just using a different OA: TC (temporary containers)

Would making those two inactive make a speed diff? Probably. Wait and see what Geko says. Or find me some sites and I'll do some bullshit perf testing

[Thorin-Oakenpants]

Ahh OK. I've always used a different one with Arthur - the Tor Uplift one

[ghost]

100% agreeing with you, I underestimated the tracking potential, also I get how having to close your browser all the time for privacy would be a pain in the bum, didn't think about it that way, sorry about that.
Then we could make the prefs for HTTP/2 and AltSvc inactive and let the SSL Tickets IDs prefs as they are until a pref to set their lifespan manually is created, that way we enable HTTP/2-only websites and keep the SSL Tickets mess at bay.
The only problem is: does HTTP/2 work without them in Firefox ?
We would need an HTTP/2-only website to test this, ideally HTTP/2 would work with SSL Tickets IDs disabled and we could close this issue and make a commit.
Also I don't think perf is an issue here. Only compatibility is a matter of importance, considering HTTP/2 is becoming the new standard and HTTP/1 will progressively be abandonned.

[Thorin-Oakenpants]

The only reasons to enable all this is for speed and compatibility. If there's no real speed diff (without session ids) then what's the point. As for HTTP2-only sites, IMO they would be super rare. Any site that did that would be shooting themselves in the foot. We could probably sit on this for a couple of years with no issues.

The only problem is: does HTTP/2 work without them in Firefox ?

GeKo said yes. Waiting on his answer re any speed improvements. Look, I'd read somewhere that the speed increases are quite good overall. A lot of 30%'s thrown around in some real world tests (nah, can't find the sources, it's all in my head). And, i think, now over 50% of the top x sites are HTTP2 compliant (see Scott Helme's Alexa 1M 6 monthly scrapes). So it's definitely something to consider.

[ghost]

He didn't send me anything since what I copied-pasted for you, so I sent him another message, I'm in wait of his answer. :)

As for HTTP2-only sites, IMO they would be super rare.

According to GeKo, they aren't anymore, seems like they're becoming a thing, but I still get your point.

We're left waiting for an answer regarding speed without SSL tickets, and then we'll be able to close this one! 🎉

[ghost]

P.S.: You mentionned TC, what do they bring that normal containers wouldn't?
I get that the automation is neat, but can't you do the same thing by just opening new tabs in new normal containers that you enabled in a recent commit?

[Thorin-Oakenpants]

OA = Origin Attributes. There are three types: FPI, PBmode, containers. Almost everything is tagged with these (not everything, but they're getting there). And they can be combined (except containers can't be used in PB mode)

If you open a PB window, everything in it and subsequent PB windows until all PB windows are closed, are the same OA. So this would allow cross-domain "contamination".

Each container you set up has a unique id (eg contextId=1). But you can re-use them, eg the default four that come shipped with FF. Each container is isolated - but allows cross-domain contamination: eg a google container that allows gmail+google+youtube+gstatic+googlefonts etc. You can combine this with FPI, but until FF is closed, SSL session ids would remain

If you use FPI, then everything is tied to the top domain

A TC is one where every new tab gets a brand new OA. i.e contextId=lastone+1. So every new tab is isolated from all other tabs.

note: SSL session ids are OA'ed (we should check that it isn't just FPI but also ContextId and PBmode!)

[ghost]

I wanted this extension to be useless, I really did, but it's not and now I'm going to have a new one, I hate great devs.
Thanks to your explanations, I understand its benefits way better.
You're a great teacher, thanks a lot, I feel like I'm getting helped more than I'm helping haha!

[ghost]

Just interfering to make sure I get your comments correctly.

So we'd have at this time,

Consider commenting 702

// 0702: disable HTTP2 (which was based on SPDY which is now deprecated)
// pref("network.http.spdy.enabled", false);
// pref("network.http.spdy.enabled.deps", false);
// pref("network.http.spdy.enabled.http2", false);

Consider commenting 703

// 0703: disable HTTP Alternative Services (FF37+)
// pref("network.http.altsvc.enabled", false);
// pref("network.http.altsvc.oe", false);

Keep disabling session ticket

// 1203: disable SSL session tracking (FF36+) -- aka session ticket
pref("security.ssl.disable_session_identifiers", true); // (hidden pref)

That's what I'm doing. Commenting 702 & 703 but not 1203.
Moreover if speed increase is likely with 702 & 703, not sure allowing session tickets improves speed when it is obvious it is a privacy issue.

[ghost]

@StanGets We should add the comment I suggested to push users to enable FPI when they use these protocols.
The speed increase from HTTP/2 is partially based on the fact that SSL tickets don't have to be created all the time, which is a quite heavy operation since it requires cryptography. That's why it could lessen HTTP/2's benefits if we disable them. @Thorin-Oakenpants Correct me if I'm wrong please!

[ghost]

@aeriem provided FPI is enabled, of course; that was mentioned at the very start. I have FPI enabled so I forgot to recall this correlated setting.

Concerning session tickets I do rely on @Thorin-Oakenpants comment above:

The only problem is: does HTTP/2 work without them [note: session IDs] in Firefox ?

GeKo said yes

Just trying to follow your expert comments. Thanks.

[ghost]

@StanGets No worries !

HTTP/2 will work without SSL tickets, this is in the specs of the tech, @Thorin-Oakenpants said so and linked some doc to prove it.

What we don't know is the actual speed benefits from HTTP/2 when they are disabled, because some of those benefits rely on keeping those tickets a long period of time to avoid doing complex mathematical calculus each time you reach a website.
I don't know if I'm being clear. T-T

[Thorin-Oakenpants]

We should add the comment I suggested to push users to enable FPI when they use these protocols.

We would create an FPI Alts section

partially based on the fact that SSL tickets don't have to be created all the time

In my head I've always thought that HTTP2 would involve less negotiation (multiplexing?) etc as that would be a bottleneck - IANAExpert

The speed increase from HTTP/2 is partially based on the fact that SSL tickets don't have to be created all the time

But HTTP1.1 also uses session ids, so that's not the point of difference. Q.E.D.

[ghost]

FPI is so powerful, it's one of those most valuable settings.
I learned all this here :=)

@aeriem ,

What we don't know is the actual speed benefits from HTTP/2 when they are disabled,

Which means disabling session IDs has no issue but could have an impact over time on the effectiveness of HTTP/2 enabled speed increase. This is complex.

[Thorin-Oakenpants]

Lets clarify this

HTTP/2 will work without SSL tickets, this is in the specs of the tech, @Thorin-Oakenpants said so and linked some doc to prove it.

I said the HTTP2 spec allowed for unsecure connections (i.e HTTP) but that the major browsers will only support it over secure connections (HTTPS) and what I linked to was wikipedia and it's sources.

I did not link to anything that said HTTP2 in FF works without SSL session tickets. Only Geko said that.

[ghost]

<+GeKo> Aeriem: yes, they bring speed improvments without ssl session tickets
<+GeKo> and, no, they don't require it in the "real world" either
<+GeKo> sessions tickets and http/2 are at different levels in the network stack
<+GeKo> thus, they are not related/bound to each other

@Thorin-Oakenpants There you go! 😄
@StanGets Me too. O.O

[ghost]

@Thorin-Oakenpants ,

AltSrv uses DataStorage. This DataStorage_Persistent, DataStorage_Temporary, DataStorage_Private I'm almost certain relates to IDB (but I could be wrong), go look in your profile\storage\ directory

Nothing new in my IDB storage. I have an application set to react on user chosen modified folders/files (Folder Monitor) and it's set by me to yell when my FF IDB / default gets new visitors. Quiet until now, unless the IDB would get impacted in the temporary section ....

Polar bears, ok. As long as my ignorance was only related to something I hadn't read then it's not problematic :=)

[ghost]

Should I stay or should I go ... (nice song).

As I said, only testing 702 & 703 as commented (disabled). Not sure I keep on testing, no need to be an expert to understand that there is too much uncertainty to consider at this time http/2 and AltSrv as more likely to be viable than not.

[ghost]

Think about PRISM's environmental impact!
Mass surveillance is so destructive for the planet, both state and corporate. Maybe corporate even more.
Scary...

As I said, only testing 702 & 703 as commented (disabled). Not sure I keep on testing, no need to be an expert to understand that there is too much uncertainty to consider at this time http/2 and AltSrv as more likely to be viable than not.

I disagree! 😮
Both HTTP/2 and AltSvc work perfectly fine and are totally sanitized by FPI.
The real mess is SSL Tickets IDs, which we all agreed to keep disabled.
I strongly believe we should enable 702 and 703, both for speed and compatibilty, especially given that it is safe, security and privacy-wise.

[ghost]

As a side note, know that I'm stating my ideas because I want to discuss them with you but I am in no way saying I'm absolutely right and trying to force a change onto the user.js! Don't interpret my "strongly believe" as me telling you what to do, I'm just passionately discussing the matter with you! 🤣

This is a template we are trying to design with a particular audience in mind, but I can adapt it to my needs through an override and as such would never try to impose my will onto this super great project!

[ghost]

@aeriem I'm continuing the testing (702 & 703 commented) but if the price is IDB invasion then i'll know where to revert. Uncertainty doesn't mean I've chosen but only that I'm not as convinced as I was a few lines above. I understand you disagree. I'm practical moreover because i ignore : if i notice speed enhancement and no side-effect such as an impact on my IDB or localStorage then I'll carry on!

[claustromaniac]

I feel fulfilled now.

[ghost]

@StanGets Keep us posted about iDB invasion, it's very interesting!

@claustromaniac Finally! 😄

@Thorin-Oakenpants Don't worry, I'll only feed him more code to crunch.

[ghost]

Not sure if I'm half-on or half-off topic but I have a question regarding TLS settings involving 3 settings available in user.js but not a fourth.

We mentioned above the Session Identifiers complexity. I was searching on this topic and found an article posted Nov 14, 2018, SuperCooKey - A SuperCookie Built Into TLS 1.2 and 1.3

The author describes his research around the impact of TLS 1.3 for Private Internet Access and proposes 4 Firefox settings:

security.ssl.disable_session_identifiers (hidden feature) : we have it at 1203
security.ssl.enable_false_start : we don't have it
security.tls.enable_0rtt_data : we have it at 1205
privacy.firstparty.isolate : we have it at 4001

security.ssl.enable_false_start by default is true on FF63 at least. I have it true as well.

The author mentions,

[...]we have to disable False Start. This is because it does not allow the client to fully complete its handshake before starting the actual session. There is more info here from the IETF: https://tools.ietf.org/html/rfc7918#section-4 (See section 5. Security Considerations)

Simple question : Should this setting be included and set to false accordingly?

[Thorin-Oakenpants]

@StanGets - see #536

[ghost]

Thanks, @Thorin-Oakenpants

The problem with GitHub is that it's not possible to search terms within the issues, only code.
I searched for SuperCooKey in this repository's homepage and was answered:

We couldn’t find any code matching 'SuperCooKey' in ghacksuserjs/ghacks-user.js

Bothers me as much as it may bother you or anyone giving the direction.
I do try to find the best topic for posting but impossible to know where a given comment, subject has been handled. Bothers me on every GitHub repository.

Thanks, #536, noted.

[Thorin-Oakenpants]

searching works fine for me. It says it can't find any CODE ... you just need to look on the left and you will see it has a counter for Issues

[ghost]

Got it, thanks again @Thorin-Oakenpants
To be noted nevertheless that it doesn't find SuperCooKey if the query is cookey, but at least there's an echo for issues. The whole place is really intended for coders, not really user-friendly. Anyway no doubt I should have spotted this.

[earthlng]

@aeriem thank you very much for getting us some quality answers from GeKo!

I strongly believe we should enable 702 and 703, both for speed and compatibilty, especially given that it is safe, security and privacy-wise.

• speed is not a priority
• compat: I have never encountered a single page that didn't work without H2. Facebook apparently broke for a while but maybe they fixed/relaxed that again IDK and I don't care about Facebook anyway. Fuck FB! #deletefacebook
  Yes it's only gonna get worse but atm compat is not really an issue.
• safe: it's probably safe security-wise but I'm not so sure about privacy. There are still things nobody really looked at in detail AFAIK, not just here but in general.
  fe TB disabled server push when they enabled H2 and Arthur also wrote

PING or SETTINGS updates timing side-channels are something I am not addressing here. I think they could do with further investigation.

and then there's multiplexing which AFAIK can also mean potentially using the same connection for different domains.
fe. let's take our good friend Cloudflare and let's say VPN user A accesses foo.bar which is CF-protected and happens to have the same CF cert as example.com. When A accesses both these domains (or any number of other domains with the same cert), CF will now know (thanks to H2) that VPN user A is accessing both foo.bar and example.com because it's using the same connection to the same middlebox at CF.
But again, that's AFAIK and just based on my very limited knowledge of things. I could be totally wrong!

[earthlng]

somewhat related: the risk for replay attacks with 0-RTT is also pretty low because FF only uses it for GET, HEAD and OPTIONS requests and the performance benefits are probably higher than H1 vs H2.
The only risk is with badly designed sites which send sensitive data like payments or whatnot with GET instead of POST.
Yes it also breaks perfect-forward-secrecy but obviously nobody at mozilla, google, etc thinks that's bad enough to warrant disabling it by default. We'll see what TB does when they enable TLS1.3.
Should we also enable 0-RTT? Same reasons: low risk, performance, hide in the crowd

[ghost]

I know it's up to everyone to make and assume his choices and I'm no exception. Nevertheless may I ask you, @earthlng , if you will keep 702 & 703 as they are now (disabled, that is not commented) or if you'll dive whatever the multiplexing which is behind and which has all my attention? Just to know, I won't go around saying, writing "earthlng this, earthlng that' :=)

[earthlng]

FYI: Remember those annoying JS-enforcing captchas when trying to access one of the couple millions of CF-protected pages over Tor? They're now gone (for the most part) because tor implemented something that lets CF (and everyone else) identify tor clients by a channel-id. Plus, thanks to H2+AltSvc, CF customers can enable an option (default is enabled if I remember correctly) to redirect tor users to an onion address for their site (hosted by CF of course). But the captchas are gone regardless of whether H2+AltSvc are enabled or not

[earthlng]

@StanGets I'll keep H2+AltSvc disabled, at least for now.

I dislike H2 in general. It didn't solve anything that couldn't have been done in a better way with just H1 and without all the unnecessary shit. Instead it introduced new problems and in some aspects is just straight up worse. see fe http://blog.gfader.com/2017/05/5-things-i-learned-about-http2-in.html

and also this again: https://queue.acm.org/detail.cfm?id=2716278

Some will expect a major update to the world's most popular protocol to be a technical masterpiece and textbook example for future students of protocol design. Some will expect that a protocol designed during the Snowden revelations will improve their privacy. Others will more cynically suspect the opposite. There may be a general assumption of "faster." Many will probably also assume it is "greener." And some of us are jaded enough to see the "2.0" and mutter "Uh-oh, Second Systems Syndrome."

The cheat sheet answers are: no, no, probably not, maybe, no and yes.

If that sounds underwhelming, it's because it is.

HTTP/2.0 is not a technical masterpiece. It has layering violations, inconsistencies, needless complexity, bad compromises, misses a lot of ripe opportunities, etc.

[ghost]

I've just read the two articles you mentioned, @earthlng . Impressive.

As many of us but certainly not as all I favor security, then privacy (though both are often tied), and speed only after.

If disabling HTTP2 and AltSrv has no impact on security & privacy (and from what I've read in those articles as well as here and elsewhere it'd rather be the opposite) but only on a slight speed improvement (and yet, depending on the servers) then I couln't consider an intellectual/psychological addiction to modernism as a valid reason to honor http2 and AltSrv blindly.

Unfortunately I'm far from knowing enough in this networks area to take some decisions fully aware of their implications, so I guess I'll rely on the opinion of those who obviously have a stronger background than mine, staying tuned to read their opinions throughout time. All this is so complex.

Thanks for sharing and of course thanks for your user.js (which started it all) and its continuation within this repository. Some of us don't see the iceberg, some see it and believe it's all in what they see, and once you dig (or dive) you realize the immensity of what is below.

[ghost]

@earthlng You're most welcome, I'm really glad I got to help out a bit! Never hesitate to ask me when I can do such simple things. It's really a time issue, which you both lack, with @Thorin-Oakenpants.
After reading the articles you linked, I understand that the complexity of it all doesn't allow us to enable those protocols until further auditing is done.
Let's hope HTTP/3 learns from these mistakes and brings us all a new standard on security, privacy and performance.
Also, when I mentionned speed, I did say it was an absolute NON-priority! (Just a bit further up the issue.) This user.js is about security and privacy, not perf enhancements, I'm not losing sight of things, don't worry! :)

[Thorin-Oakenpants]

Earthlng

compat: I have never encountered a single page that didn't work without H2. Facebook apparently broke for a while but maybe they fixed/relaxed that again IDK and I don't care about Facebook anyway.

Yes it's only gonna get worse but atm compat is not really an issue.

Me

As for HTTP2-only sites, IMO they would be super rare. Any site that did that would be shooting themselves in the foot. We could probably sit on this for a couple of years with no issues.

and just for good measure, hackerfactor

Really? HTTP/1.0 was replaced by HTTP/1.1 back in January 1997. (That's nearly 22 years ago, for people who need more fingers and toes.) Every web server out there still supports HTTP/1.0.

While HTTP/3 will be widely adopted someday, it's certainly not going to drop support for HTTP/1.1 in the next few years.

Newer HTTP/1.1 server supports spdy. spdy was replaced by http2, and http2 is being replaced by HTTP/3. But even servers that support spdy or http2 still support plain old HTTP/1.1.

I really don't think compat is an issue, not for years, if not a decade

[Thorin-Oakenpants]

@aeriem - thanks for digging into this and chatting with GeKo. It certainly enlightened me as to how Tor Browser model the threat - I never knew they didn't auto-New Identity after x time, but I did know that they have relaxed "standards" over session data. From lots of previous reading etc, I know that FPI is their holy grail and they want to enable third party cookies, etc - because they are relying on the Tor protocol and that in itself, that is anonymized web traffic.

Still ... they don't seemed concerned about session data.

I'll close this: As said elsewhere, I have my own mechanism to chase up on and try to affect a SSL session id expiry better than 24 hours. The problem is they have no API/ internal call for it (from reading open bugzillas from 5-10 years ago). NFI how they expire it after 24 hrs then!

The info & discussion gained from here will be input into #571

Thanks creepy stalker guy 💋

[Atavic]

I could be totally wrong!

For me, you're mostly right @earthlng

Regarding speed, the improvement is minimal, here are some real numbers, scroll down to Performance Compared to TLS 1.2

Regarding multiplexing, any group with many data-centers will do that. M0zilla included.