User.js: adding an user-overrides.js template

[claustromaniac]

Apr 28, 2018

claustromaniac said: Giving the merge function new superpowers made me think that it might be a decent idea to add a user-overrides.js template to the repo, with examples and such. It may also make things slightly more intuitive to newcomers.

earthlng said: Damn mate, I swear I just had the same idea. I wonder if our periods are also synced-up already? :grin:

I could've written a simple short draft myself but, on second thought, adding a new template that merely provides examples on how to use the updater sounds like kind of a waste of space (and potential). The wiki already fulfills that purpose to an extent.

So... what the hell did I open this issue for, then?

Well, I looked around and it seems to me the idea of adding separate user.js' or separate branches with relaxed settings was never dropped entirely. Am I right on this, @Thorin-Oakenpants, @earthlng, @everyone? As you may have guessed, I'm asking because if that's the case, we could kill two (or more) birds with one bullet: the same template could fulfill the purpose of providing both usage examples and relaxed settings.

The prefs that would best fit the bill, in my opinion, are prefs that:

• ...change rarely, or never (to make this as easy as possible to maintain).
• ...are the most likely to vary from user to user (UI/UX-related, cache-related, shoulder surfing, etc).
• ...provide considerably circumstantial benefits at the cost of substantial breakage.

The intuitivity that this file would provide would come, naturally, from the users not having to create it from scratch, and it could even be a self-explanatory file.

Other _potential_ uses for this file would include:

• Encouraging users to define values for specific common prefs that would otherwise be wiped out by the cleaner scripts every time they run them.
• Removing some of the inactive preferences in user.js that would be better suited for a file like this one.
• Explaining some stuff in a more newbie-friendly manner.

I think it would be best if all overrides in said file were inactive by default, anyway. One-char switches would be good for this.

What do y'all think?

Got any observations, suggestions, objections, whatevstions?

Somewhat related topics: #338, #162, #151

[Thorin-Oakenpants]

add a user-overrides.js template to the repo, with examples and such

We have an example, in the wiki :) I mean how hard is it!

idea of adding separate user.js' or separate branches with relaxed settings was never dropped entirely

Correct. I've been planning on getting around to this for ages

Anyway, my thoughts have always been

• a branch (not keen on it, I only want to maintain diffs, not a whole branch)
• a locked sticky (maybe)
• an overrides [relaxed].js

I'm leaning towards a js file (because I might even do an overrides [mofo].js for those who want it]. Users can just copy/paste and add to overrides. It could have several sections - eg

• local disk/app/os restrictions, shoulder surfing stuff, urlbar etc even keep history (eg sole user of puter)
• a media/maps/gmail/googledocs one (so people can get their twitch and shit going)
• other

Big E's troubleshooter is already ordered in likely to break fashion as well, although I think breaking down like above would be better. I reckon at most we'd be looking at about 30 prefs to cover everything, if that.

provide considerably circumstantial benefits at the cost of substantial breakage

Absolutely. Otherwise we could theoretically end up adding them all. I'm talking about major website breakage (and all the shoulder surfer, app/os isolation, what to clear on close, urlbar etc stuff) - service workers & web notifications & sw cache, DRM/EME/CDM/GMP, FPI, RFP, cookies (set to 1st party), security.OCSP.require, XOriginPolicy, dom.event.clipboardevents.enabled - struggling to think of any more for WEB breakage

Removing some of the inactive preferences in user.js that would be better suited for a file like this one.

No way. the master user.js must have everything. Any other files are supplementary.

[claustromaniac]

We have an example, in the wiki :) I mean how hard is it!

The question is not how hard it is, the question is if it's worth it. Keeping overrides in a separate file and manually downloading the user.js and pasting the contents of my overrides file at the bottom of my new user.js is not hard either, but that didn't stop me from writing an updater script. My point being, this is convenience/user-friendliness we're talking about here. I'm nowhere nearly as knowledgeable as you or earthlng or other collaborators when it comes to Firefox prefs, so my way of contributing so far has been mostly about giving newcomers less and less reasons to shy away from this project :) The more we are, the better.

Big E's troubleshooter is already ordered in likely to break fashion as well

It crossed my mind, too. And I agree, dividing into sections sounds like a better approach for this.

No way. the master user.js must have everything. Any other files are supplementary.

Well, I did emphasize the _potential_ in _potential uses_ . That's one thing out of the way already :)

[earthlng]

Yes I had the same idea at the time but I'm not so sure about it anymore.

1. I'm not sure adding even more files would necessarily be newbie-friendly. It could be the opposite.
2. I initially thought an override template would be nice to explain some of the merge capabilities but (a) we have no idea how many people actually use the updater scripts, let alone how many people use the merge function on Windows, and (b) it's all explained in the wiki for the few who are interested. I don't want to maintain even more stuff that nobody might end up using anyway.
3. I'd rather relax the default template and maybe provide a hardened override file or a couple of "modules" for shoulder-surfing etc. You said you don't disable disk-cache nor shoulder-surfing stuff and I don't either. Others have said the same, I think mainly about the shoulder-surfing stuff. So that's at least 2 things which I wouldn't mind seeing relaxed in the default user.js. Maybe we should open an issue to ask users to share some of their overrides, to see what most people here don't need/want in the default user.js template. If a majority relaxes or hardens the same stuff that's reason enough to change it IMO.

Removing some of the inactive preferences in user.js that would be better suited for a file like this one.

I totally agree with :jeans: on this one: "the master user.js must have everything. Any other files are supplementary." - It's a template and it should contain everything we consider important enough for people to know about, including inactive ones.

Just my 2 cents for now. I'm still open to the idea if we can all agree on what it should look like. Thanks for taking the time to write this all up and for sharing your thoughts and ideas :+1:

[Thorin-Oakenpants]

Whether we create a relaxed overrides, or we relax the main body & create a hardened overrides is one question (this approach actual means my idea below could work) - but the main question is where do we put them

Instead of a separate file, we could built it into the existing user.js. Instead of duplicating items, we MOVE them to the end under a couple of sections with one char switches. Now everything is still in the same file, and there should be no duplication (just those prefs where the default sucks in both relaxed & hardened, eg cookies)

[Thorin-Oakenpants]

^^ that's just an idea. It would break our current model of sticking everything in its sections, but would reduce complexity for the end user.

Although, we don't have to MOVE, we could just duplicate each setting - this add a little complexity for us, but its not a major eg (but behind a single char switch)

/* RELAX: local machine, non web content
   If you have unauthorized access to your computer covered ***/
user_pref("browser.urlbar.autocomplete.enabled", true); // 0850a
user_pref("browser.urlbar.suggest.history", true); // 0850a
user_pref("browser.urlbar.suggest.bookmark", true); // 0850a
user_pref("browser.urlbar.suggest.openpage", true); // 0850a
user_pref("browser.urlbar.autoFill", true); // 0850d
user_pref("browser.urlbar.autoFill.typed", true); // 0850d
user_pref("browser.urlbar.oneOffSearches", false); // 0850e
user_pref("browser.cache.disk.enable", true); // 1001
user_pref("browser.cache.disk.capacity", 200); // 1001

/* RELAX: web breakage: media

/* RELAX: web breakage: other
etc

Or the reverse, as a harden if we relax settings - which maybe does not make sense, because regardless we would STILL need a relax section. That is having relax and harden makes it too messy. We need to think this thru.

With what I would estimate to be about 30 to 40 prefs, this would be easy to manage

Edit: we would need to stipulate that only items for ESR60 and FF60+ branches apply in order to keep this clean and not mess with deprecated? If we compile a list (later) we should see how many are ESR52.x items, and quite frankly I'd like to NOT include them since ESR is EOL soon. I can only think of 1 item so far (dom.workers.enabled). Just food for thought. Also, where do we position this - IMO it would need to be after deprecated.

[earthlng]

The problem with single-char switches is that people will need to manually edit the user.js after every update which kind of goes against the idea of using the updater scripts (with overrides) for simplicity.

@claustromaniac wrote

I think it would be best if all overrides in said file were inactive by default, anyway. One-char switches would be good for this.

one-char switches in overrides are also problematic for people using the merge function

[claustromaniac]

@earthlng

I concede that whether an additional file would by itself make things more intuitive or not is arguable, and I agree that the lack of feedback is discouraging, especially when you assume that you will be expected to maintain it. Honestly, it even took me a while to convince myself that opening this issue was going to be worthwhile. However, I prefer to try not to sabotage my own initiatives thinking that way because a) even if we ask for feedback, only a very small subset of users will provide it, and b) I'm not trying to make this more intuitive and user-friendly for current users. Current users don't need that. As it happens with pretty much anything software-related, ease of use and learning curves end up working as filters that decide who stays and who goes looking for an easier alternative elsewhere. When it comes to protecting one's privacy, we know from experience that there are no shortcuts, but I reckon making things look as less daunting as possible is worth it. That's what I've been trying to address, and since I don't expect to get any feedback, so far I've trying to think mostly of what I can do to make things easier for me.

Anyway, I still don't think that asking for feedback would necessarily be a wasted effort. I think you two guys in special could use some more of it, since you're the ones investing the most time and effort in this.

Maybe we should open an issue to ask users to share some of their overrides, to see what most people here don't need/want in the default user.js template. If a majority relaxes or hardens the same stuff that's reason enough to change it IMO.

That might be a good approach. It could be a sticky, even (to keep it open for future feedback).

@:jeans:

Hmm. What happens if you pit the pros and cons of each method for you (the maintainers) against the pros and cons for the users? As an user, I would personally prefer to have them in a separate file, but I'm not too particular about it. I'm not too keen on moving stuff around in the user.js. What would be easier for you? I guess it would help to hear some feedback on this too.

[Thorin-Oakenpants]

What happens if you pit the pros and cons of each method for you (the maintainers) against the pros and cons for the users

The cons for the maintainers are immaterial. We can work around it.

Lets work from the premise of a simple user. One file, default relaxed mode. THAT's the most friendly shit ever. Now work out the next step.

Ultimate solution. A single user,js just for relaxed dudes, you know, like a branch.

Or ... build it into the current user.js .. One char switch for ESR users. One char switch to harden up some stuff. One char switch to harden up even more. (note we would have to work out how to deal with RFP relaxed off & RFP alts). I do get that the updater doesn't restore on-char switch states. That's the only drawback IMO. But we currently have that same situation for ESR and non RFP users. Not that we can't improve on it, somehow.

Format. One char switch formats suck in IDEs compared to the other sections, plus it would break up our "sections" over too many places. Hence I prefer this option

Edited to make it clear that sections B+C etc would be one char switches

/* SECTION A: EVERYTHING: RELAXED MODE ***/
   // and thats everything, active, inactive, descriptions
   // includes deprecated etc

/* SECTION B: HARDEN UP MODE  (one char switch to enable the lot) ***/
user_pref("blah1", true);
user_pref("blah2", "goats");
// if a pref here is ESR, who cares, it just means we write a deprecated pref

/* SECTION C: MOFO MODE (one char switch to enable the lot) ***/
user_pref("blah8", "llamas");
user_pref("life.universe.everything", 42);

/* SECTION D: YOUR OVERRIDES ***/

[Thorin-Oakenpants]

^^ this keeps all of section A which is currently everything, in the same format, everything in its place. sections B & C would be like 40 lines

[earthlng]

So, by default everyone would be in MOFO mode (whatever that means) and they'd have to override the 40 or so lines in B & C if they want the relaxed version? How is that making things easier??

Here's how I see it: we already encourage people to use the updater + overrides and IMO we should build everything around that and make that as easy as possible.

I think the best solution would be a sticky with code blocks for hardened/relaxed/mofo/whatever-mode that people can just copy into their overrides. It gives them an idea about what we think can be relaxed or hardened but nobody needs to edit anything if they don't want. = no additional shit in the user.js; no duplicates; relaxed template by default (=current master but with 0850a + 0850d inactive) - easy peasy

[Thorin-Oakenpants]

So, by default everyone would be in MOFO mode

mofo is slang for mother f^^ker

so in my example just above, I was building on what I already said (https://github.com/ghacksuserjs/ghacks-user.js/issues/435#issuecomment-391904961), but left out the bit about them being one-char switches

that is section A is a relaxed mode, sections b + c would be one char switches

[Thorin-Oakenpants]

I'm OK with a locked sticky. Probably 2 lists of about 20 prefs each with instructions to cut copy and paste into their overrides, and add a link in the readme at the top. Still, it would have been just as effective in the user.js itself - not copy/paste, not need to keep checking the sticky, just do a one-char switch

[Thorin-Oakenpants]

I meant "copy" and paste, sorry. Unless you thought I said "instruction how to cut and paste" - I'm confused

[earthlng]

I'm OK with a locked sticky.

doesn't have to be locked IMO. Users could share their own ideas/prefs for relaxed/hardened mode.

Or instead of a locked sticky we could create a new .MD file. It would be included in the download zip (unless you don't want that, then we can exclude it), changes show up in the repo's commit history and the file also has its own Blame and History (re: "not need to keep checking the sticky"). And linking to it displays it in parsed markdown view, fe like the README

[crssi]

162 is kind of old... will update soon, if anyone care.

Anyone care to share your overrides?

[Thorin-Oakenpants]

A sticky sounds like the best idea. The first sticky can be unlocked so we can build a workable version - then I'll close that and create a new clean but LOCKED one. People can just open a new issue to suggest stuff. - I'm not getting into this situation where we end up with 100's of comments like the stickies for extensions.

After that we can look at where it permanently lives - links in the user.js readme and in the wiki implementation. But for sure, a sticky for starters.

[Thorin-Oakenpants]

It would be included in the download zip

That appeals, but a sticky is also good (higher profile for visitors). In the user.js is maybe even better in the sense that those who just grab the raw user.js don't miss the data. ¯\_(ツ)_/¯ pros and cons for every solution

[earthlng]

Anyone care to share your overrides?

I haven't finished moving all my direct edits to overrides yet, fe disabling SB+TP, enabling disk-cache (+ clear on shutdown), and a couple of 5000's.

most of my overrides

user_pref("browser.slowStartup.notificationDisabled", false); // 0101
user_pref("browser.startup.homepage", "about:blank");         // 0103

user_pref("geo.enabled", false);     // 0201
user_pref("geo.wifi.uri", "data:,"); // 0210

user_pref("app.update.enabled", false);        // 0301a
user_pref("extensions.update.enabled", false); // 0301b

user_pref("services.blocklist.plugins.collection", ""); // 0403
user_pref("services.blocklist.gfx.collection", "");     // 0403

user_pref("extensions.systemAddon.update.enabled", false); // 0505
user_pref("extensions.systemAddon.update.url", "");        // 0505
user_pref("extensions.screenshots.disabled", true);        // 0515

user_pref("network.dns.disableIPv6", true); // 0701
user_pref("network.ftp.enabled", false);    // 0708

user_pref("browser.urlbar.autocomplete.enabled", true); // 0850a
user_pref("browser.urlbar.suggest.history", true);      // 0850a
user_pref("browser.urlbar.suggest.bookmark", true);     // 0850a
user_pref("browser.urlbar.suggest.openpage", true);     // 0850a
user_pref("browser.urlbar.autoFill", true);             // 0850d
user_pref("browser.urlbar.autoFill.typed", true);       // 0850d

user_pref("signon.rememberSignons", false); // 0901

user_pref("permissions.memory_only", true); // 1006

user_pref("security.ssl.require_safe_negotiation", true); // 1201
user_pref("security.nocertdb", true);                     // 1221

user_pref("font.name.serif.x-unicode", "Constantia");         // 1402
user_pref("font.name.serif.x-western", "Constantia");         // 1402
user_pref("font.name.monospace.x-unicode", "Lucida Console"); // 1402
user_pref("font.name.monospace.x-western", "Lucida Console"); // 1402

user_pref("network.http.referer.XOriginPolicy", 2);         // 1603
user_pref("network.http.referer.XOriginTrimmingPolicy", 2); // 1604
user_pref("privacy.donottrackheader.enabled", true);        // 1610

user_pref("dom.event.contextmenu.enabled", false); // 2401

user_pref("pdfjs.disabled", true);                           // 26xx
user_pref("svg.disabled", true);                             // 2610
user_pref("browser.download.folderList", 0);                 // 2650
user_pref("extensions.webextensions.restrictedDomains", ""); // 2662
user_pref("security.csp.experimentalEnabled", false);        // 2682

user_pref("network.cookie.cookieBehavior", 1); // 2701

user_pref("privacy.clearOnShutdown.cookies", true);      // 2803
user_pref("privacy.cpd.cookies", true);                  // 2804
user_pref("privacy.clearOnShutdown.openWindows", false); // 2805
user_pref("privacy.cpd.openWindows", false);             // 2805

[Thorin-Oakenpants]

Well if someone wants to collect overrides see issue 438

[Thorin-Oakenpants]

@earthlng - I know you haven't finished it, but privacy.cpd.openWindows & privacy.clearOnShutdown.openWindows have been inactive for ages, reset em and remove from your overrides (I can't imagine they're true by default in ESR52.x?)

[Thorin-Oakenpants]

closing this. I think we have a consensus for now for the next things to do

paste overrides in issue #438

• analyse the data
• change some prefs based on analysis (knowing that we have relaxed and override sections coming)
• open a new unlocked sticky and build some relaxed and hardened overrides
• once the overrides are worked out - put em in a clean new locked sticky if necessary and add links to it (wiki & user.js)
• down the track: decide if want to make it into an md file, or add to the user.js directly and/or create some extra js files - whatever (not worth getting into that right now)

[claustromaniac]

I'm liking your ideas so far.

Pants, do you use any tools for comparing user.js/prefs.js/overrides? I've been considering writing one for myself in my spare time, but it might not be necessary if you know of one just for doing that.

[Thorin-Oakenpants]

Pants, do you use any tools for comparing user.js/prefs.js/overrides?

Nope. I just use a compare application (I like Araxis Merge) and/or go old school in an IDE e.g.

• take copy of GH user js
• remove parts not needed (eg deprecated before FF52)
• sort by column 0
• remove all non user_pref and // user_pref lines
• do same to PK user.js
• compare

It does nothing for knowing what is a default value, or take into account eg ESR52 vs ESR60. Or when prefs were added. etc

Earthlng normally does these, and I think he has some cool scripts/tools

[claustromaniac]

Yeah, that's similar to what I've been doing.