It also disabled IPv6, form auto filling, and automatic updates of Firefox. Like 99% of these projects, lots of questionable choices here. I never understand why people would recommend applying hundreds of settings without understanding what they do. It’s registry cleaner-level of irresponsible (breaks tons of things for little to no benefit). To be fair, in the “Implementation” page (???) of the project wiki, the authors state “ULTRA UBER IMPORTANT. Do not just take the user.js and use it with your profile. There are some considerations to make first that concern your online security etc”, but nothing of the sorts is in the readme or even the overview wiki page.
The problem is that those comments are often speaking from a position of unwarranted authority - for example, the section on HTTP/2 is simply wrong but if you didn’t understand the technology the tone would make you think the author is making a reasoned trade-off.
I refer to you my earlier comments about my background (for your info: take it or leave it), and about HTTP2 in particular.
I agree with you that OFTEN the web is full of shit and bullsitters, but I would just like to say, that I am NOT one of them. I'm not always right, so please, if you can correct me in any way, I am more than willing to listen and correct my mistakes. Thanks
Yes, but the caveats are not properly explained for many of these things. Playing around with settings without fully understanding what they do can lead to nasty surprises. I find it questionable to promote such things without the necessary disclaimers.
I've taken great pains to try and provide as much info as possible, in as easy non-jargon terms as possible, for the layman. I have also gone to great lengths (days on a single item, weeks to follow up on research and contact with experts) in order to verify things, and provide relevant links. You can take me on my word, or not: but I've basically been living this stuff 24/7, 365 days a year, for 8 years.
I can still get things wrong, and I can always improve things, but please, don't label this as
- promoted: I have never promoted it, and internally it has always been labeled as a hardened setup and a template
- not understandable: there is a limit to how simple comments can be made. Some jargon is needed. At least I provide links to back up what I say and also for those interested in digging deeper. And at least I provide those comments in the first place.
- questionable: I know what I'm doing
I personally, know fully well what each and every setting does - well, at least the outcome and consequences of them being changed. It's hard to find a balance, but this is not a simple task. The user.js is primarily "fairly hardened" and as a result, breaks things. That cannot be helped. It is promoted internally as a TEMPLATE, not a cure-all.
Where am I lacking in disclaimers? Caveats? Do you mean I need to point out that things break with some prefs? We do already, and we're adding in [SETUP] tags that pinpoint items that can cause breakage e.g [SETUP-WEB] indicates that this pref might cause breakage, and we say what breaks or it should be painfully aware without saying (or at least that's the plan: the comments can always be improved for sure).
"but the caveats are not properly explained for many of these things" - can you enlighten me as to where. Feel free to contribute and improve it at the github repo (where it will be easier for me to deal with, since your criticism seems to indicate I have a lot of editing to do)
form auto-filling is disabled for a reason. It is trivial for third parties to steal form data. It's an inconvenience for some, but does not break anything - websites still work. This is a known bug/issue for at least 8 years - and yesterday I confirmed the leak can still happen in the latest Firefox Nightly - however, this is something I could possibly get addressed (or at least get some action on: I wasn't BS'ing in an earlier comment about what I do and where I have a voice: its a little voice, but it is a voice), maybe, with the Tor Uplift and apply first party isolation to (which also reduces the usefulness of it). IPv6 I addressed in an earlier comment.
I'll address automatic updates in another comment
I agree with you that 99% of these sorts of projects have questionable choices. But every single one of ours has solid reasons (and research, and validating that research, even creating our own Proof of Concepts, lots of testing, and more), and the user.js has only ever been billed as a TEMPLATE - never as a cure-all, grab it, set it & forget it. It was also started as a means to be comprehensive, and documented, and I've tried to make comments as easy for the layman to follow as possible.
I have also never recommended applying this without reading it and making changes etc. I even tell people to test it in a new profile first. And I have gone out of my way to make sure nothing is ever lost (the exception being that cookies and history are cleared: I can't bring those back) - i.e any pref can be changed back, and nothing is lost. I also encourage users to ask in the github issues. And I provide as much easy to follow comments as I can. This is not some irresponsible collection of prefs just thrown together with no thinking.
I have re-arranged the wiki page on implementation. The readme of github DOES tell everyone to read the implementation,. It's the second hyperlink. That readme is also kept very short so no-one misses anything. The readme in the user.js DOES point at the implementation and tell users to read it. And because I know human nature says a lot of people won't, I even ADDED the SAME info in super shorted form to the actual user.js - at the top, right after version, author etc. What more can I do?.
I have now added a link and message (almost at the very top) to the Overview page as even more fool-proofing. So thanks for that. Always happy to improve things.
I'm not liking the registry cleaner level of irresponsible comparison, at all. The user.js changes around 300 prefs from their default (that's not all the prefs listed, thats the ones that are actively changed if you applied it). Of these, at a rough estimate, there are only about 30 or so that people complain about. And they can change them. The vast bulk of them don't affect/break anything at all (or extremely rarely) - i.e site breakage, etc - they ONLY increase the prime objectives of increasing privacy, security, etc.
I have toyed with the idea of making the template much more relaxed & less breakage (i.e those 30 odd prefs that people complain about made inactive), and then tagging items as "harden", and/or supplying a hardened section, and or providing a hardened that users can tack on as their overrides. But that's doesn't quite fit with the original purpose of what I set out to do.
It has always been my aim, and intention, to make things as easy as possible. Hence setup tags etc. And part of that, a long time coming, has been to provide a relaxed.js or sticky issue at github, for people to apply to reduce most of the breakage. I've even taken a scientific approach and done polls on breakage, collated data from users about it, and so on. I have a basic list and should get that out, as soon as I kick myself in the backside to finish it. Once again, the user.js is a TEMPLATE, but more than happy to make things easier for end-users.
