It doesn't disable updates, it only disabled the auto-installing of updates. Bit of a difference. However, I was reminded/prompted to change our default on extension auto-installing their updates. APP updates you get repeated notifications from Firefox, in your face. So I do not consider this a risk, especially given our user base. I also updated the wiki to make all of this clear. Of course users should update - I've never said otherwise

Safe Browsing has never been disabled, except the real time binary checks with Google. And this has always been pointed out. And the user.js itself says not to mess with TP or SB any further - i.e at your own risk. And we even had Francois from Mozilla who worked on all of this, to give us the inside scoop and correct details on exactly how all of these work. The header says that there are no privacy or security issues (outside the real time binary checks). Given the user-base, this has never been an issue as far as I can see. But as a default, I can see it maybe putting someone at risk - but I'm not here to babysit the internet - the end user has to take some responsibility of where they get binaries and so on.

The user.js has NEVER ever disabled password saving.

IPv6, HTTP2 have been commented on elsewhere. There are reasons for them being disabled - 50/50 call on those really. The thing is, that they don't break anything.

Cache is a lot trickier. There are certainly tracking/privacy issues with cache, but usually you also need to disable memory cache - we only disable disk cache. It's also not really a speed factor - I've browsed like this for nigh on 8 years. Most content isn't pulled from cache: it's dynamic. Cache is almost a throwback to dial up days. What is pulled from cache, is usually tiny, the js libraries, css, nav sections, footers. The big content is media and images, and that's usually distinct per page. That's a pretty broad generalization. Yes, you will get a speed boost, and it may be worthwhile for you.

One of the reasons these very few issues all you guys have brought up (cache, http2 etc) have come up, is because, while this project is not trying to be the Tor Browser (we actively tell people to use that if it fits their needs), it does follow it's design: such as disk avoidance, app isolation (e.g not leaving MRUs in external places), and more, and even going as further with shoulder surfing issues - but I've relaxed that quite a bit in the default user.js, as I believe this should be in the hands of the end-user: e.g encrypt your device, don't allow shoulder surfers, and just basic safe OpSec. Otherwise all it does is reduce functionality.

I never just disable things because "I don't understand it therefore it must be bad", in fact I do the opposite. There must be a benefit: enhances security, privacy etc. And it's always weighed against breakage, how much the API is used, risk assessment, etc. There's almost always pros and cons. For example, we don't disable geo, because that's behind a prompt, and the user is already protected. But you'll find hundreds of other "lists" doing just that. I could name dozens more that we don't do - because while they sound good, actually achieve nothing and only create barriers for those who actually use them (gamepads, vr instantly spring to mind: default for permissions is another)

Anyway, thanks guys. Got to say what I needed to. And made changes thanks to your comments - 1 pref change (so far, maybe another) and a revamped cleaner wiki page. Hope you now see this project in a different light.