User.js: changelog: v60-beta

[earthlng]

• date: 15-May-2018
• foreword: These are all the changes since the last changelog (v59-alpha).

---

changelog: [[all changes](https://github.com/ghacksuserjs/ghacks-user.js/compare/457611f...e5d23f6)]

• all user.js updates for Firefox v60 are detailed in the ToDo: diffs FF59-FF60 issue
  
  
  
  • includes links to the commits made for each pref, links to bugzilla tickets, our discussions etc.
  
  
• spring cleaning - removed some prefs matching FF's default values
  
  
  
  • the values haven't changed in a long time and also match ESR52.x's default values
  
  
• revamped section 2600: MISCELLANEOUS (mostly just reordering and renumbering)
  
  
  
  • new subsections for DOWNLOADS, EXTENSIONS and SECURITY
  
  
• prefsCleaner.bat updated (download) - thanks @claustromaniac !
  
  
  
  • massive speed improvement! now takes less than a second instead of a few minutes !!
  
  
• @claustromaniac also ported the prefsCleaner to Bash, for Linux and Mac. Thanks!
  
  
  
  • prefsCleaner.sh (download)
  
  
  • No idea what this is? read the Wiki page Resetting Inactive Prefs
  
  
• ghacks-user.js updater for Mac/Linux v1.3 (download) - thanks @overdodactyl !
  
  
  
  • The script now compares its version number to the one online. If there is a newer version of updater.sh online it asks the user whether to download and run it.
  
  
  • 2 parameters are supported: -donotupdate to disable the update-check and -update to auto-download and run the new version without asking
  
  
  • Backup files are now saved to the directory userjs_backups
  
  
• ghacks-user.js updater for Windows v4.5 (download)
  
  
  
  • now supports commenting-out active user-prefs with the merge function
  
  
  • updated the wiki page with all the details
  
  
• updated the scratchpad cleanup scripts and the wiki page
• for all the rest see the full list of pref changes below

---

all pref changes:

• new active prefs:

user_pref("app.normandy.api_url", "");
user_pref("app.normandy.enabled", false);
user_pref("app.shield.optoutstudies.enabled", false);
user_pref("browser.cache.offline.insecure.enable", false);
user_pref("browser.chrome.errorReporter.enabled", false);
user_pref("browser.chrome.errorReporter.submitUrl", "");
user_pref("dom.disable_open_during_load", true);
user_pref("security.insecure_connection_text.enabled", true);
user_pref("xpinstall.whitelist.required", true);

• new in 60beta but commented out by default:

//user_pref("extensions.screenshots.upload-disabled", true);
//user_pref("extensions.webextensions.restrictedDomains", "");
//user_pref("network.cookie.same-site.enabled", true);
//user_pref("network.ftp.enabled", false);
//user_pref("network.trr.bootstrapAddress", "");
//user_pref("network.trr.mode", 0);
//user_pref("network.trr.uri", "");
//user_pref("security.insecure_connection_text.pbmode.enabled", true);
//user_pref("ui.key.menuAccessKey", 0);

• activated previously commented-out prefs:

user_pref("permissions.default.geo", 2);
user_pref("privacy.resistFingerprinting.block_mozAddonManager", true);

• commented out:

//user_pref("browser.cache.offline.enable", false);
//user_pref("browser.storageManager.enabled", false);
//user_pref("dom.storageManager.enabled", false);
//user_pref("geo.enabled", false);

• removed from the user.js:

user_pref("device.storage.enabled", false);
user_pref("general.useragent.compatMode.firefox", false);
user_pref("network.dns.blockDotOnion", true);
user_pref("network.stricttransportsecurity.preloadlist", true);
user_pref("security.block_script_with_wrong_mime", true);
user_pref("security.fileuri.strict_origin_policy", true);
user_pref("security.sri.enable", true);

• moved to 4600: RFP (4500) ALTERNATIVES:

user_pref("webgl.enable-debug-renderer-info", false);

• moved to 9999: DEPRECATED / REMOVED:

user_pref("browser.newtabpage.activity-stream.enabled", false);
user_pref("browser.newtabpage.directory.source", "data:text/plain,");
user_pref("browser.newtabpage.enhanced", false);
user_pref("browser.newtabpage.introShown", true);
user_pref("dom.workers.enabled", false);
user_pref("extensions.shield-recipe-client.api_url", "");
user_pref("extensions.shield-recipe-client.enabled", false);
//user_pref("view_source.tab", false);

---

Any and all help, suggestions, recommendations, links, tips and tricks, questions, thank you's or whathaveyou are welcome - signup/login and start typing - thanks

[claustromaniac]

Thanks guys. What would I do without you.

[Thorin-Oakenpants]

FYI: 1450448 about:preferences#privacy>Site Data doesn't work if browser.cache.offline.enable=false

Resolved fixed FF62+ (so far), 2730. Regardless, since it's deprecated (the tech, not the pref), and its behind a prompt, I doubt we'll ever make it active again. Might pay to keep an eye on it and amend the user.js info at some stage

[earthlng]

Might be worth adding to the "to keep an eye on" sticky. IMO we can disable it again for FF62 and wait until they remove appCache support for good.
Currently it sucks a bit for ESR52 to have appCache enabled but since it's rarely used and behind a prompt I think it's fine.

[Thorin-Oakenpants]

Added to the sticky under FF61-62, so when need be, we can fix the info for it being required true, although I do have other tracking mechanisms in place :)

Also, FYI: https://bugzilla.mozilla.org/show_bug.cgi?id=1428459 - this should solve the system addon updates (different story for the removing ability to disable updates in stable though). That said, I haven't ever seen a system addon update outside of FF releases

[earthlng]

I haven't ever seen a system addon update outside of FF releases

probably because you have auto-install disabled

[Okamoi]

@earthlng Talking about changelogs, is there anything to come for Firefox 59 Release to Firefox 60 Release here ?

I'm using these any time Firefox updates, so I'm currently waiting on Firefox 59 for the repo to update :)

If it is not to be updated any more because it's too much hassle or whatever, I'll pull back to this one again, as I used to in the past. It's less good because it updates from Beta X to Release X+1, but no worries if you don't want to be burdened with this any more there's at least an alternative :)

[earthlng]

@Okamoi

I'm using these any time Firefox updates, so I'm currently waiting on Firefox 59 for the repo to update :)

We're always going over those lists in our ToDo: diffs issues and instead of you looking at the lists for yourself, you'd be more than welcome to provide your input in those issues.

But anyway, I've updated the repo with the FF60 diff. A couple of prefs were not included in any of the previous or current diffs but I've listed them here. From now on Release diffs will list changes to those prefs as well.

[Thorin-Oakenpants]

FYI: https://bugzilla.mozilla.org/show_bug.cgi?id=1450448 (site data) uplifted to 61 ..still waiting to see if they push it to ESR60

[Thorin-Oakenpants]

FF38: 2449 prefs -> FF60: 3261 prefs .. I think this is a good thing, I'm not sure. A lot of prefs are built in so they can be studied, and then removed later... (and it keeps earthlng gainfully employed) or maybe it's indicative of so many changes (eg Quantum, stylo, webrender, etc) or the growing web tech standards.

[Thorin-Oakenpants]

@overdodactyl : reddit - that's you, right? The answer is

// user_pref("extensions.webextensions.restrictedDomains", "");

which was added in FF60

[overdodactyl]

Thanks Pants! Not a huge fan of that change 👎. Just now seeing this....I've got lots of emails from this repo to catch up on!

[Thorin-Oakenpants]

https://bugzilla.mozilla.org/show_bug.cgi?id=1450448 - looks like they'll push this to ESR

[Thorin-Oakenpants]

@overdodactyl This is the ticket to read: 1453988 (it links to other tickets) .. basically the privacy.resistFingerprinting.block_mozAddonManager pref meant AMO was no longer protected, it raised q's about malicious extensions shenanigans (see 1406795 ) and was WONTFIX (but clearly they did care), hence the access denied (still denied) for 1415644 which the patch is clearly visible if you look it up. Essentially, they took the approach of protecting a bunch of their domains - because it is not a good look if said domains are infested with adverts or hijacked etc when it is not Mozilla's fault, but rather an extension. So it's a good move, especially with the sync and account ones. Imagine a rogue extension (or existing one gone rogue for a day or two) stealing account details

Meanwhile, those of us who want to, we can disable that, so all websites are treated equal. Mozilla have every right, IMO, to protect their domains this way, since they are the conduit for these services (addons, sync, etc)

[earthlng]

Maybe it's time to think about enabling DNT by default.

pros:

1. we don't clear extensions.webextensions.restrictedDomains by default and some mozilla domains use GA but do honor the DNT flag
2. mozilla does not set DNT by default because it was spec-ed as user-opt-in. But IMHO using something like the privacy and security enhancing ghacks user.js qualifies as saying "do-not-track me!"
3. with the new law in Europe, explicitly telling sites to DNT might even be useful in courts
4. DNT might not do much but it does something

cons:

1. because it's opt-in, it puts us in smaller group FP-ing-wise (at least until more people start using it)
   BUT the same can be said about blocking cookies (which probably even fewer people do) for example.
   RFP is easily detectable too and the large majority of FF users don't use it but that didn't stop us from enabling it either.

:+1: or :-1: ?

[overdodactyl]

I can certainly appreciate that view point, there's just something that doesn't sit right with me about Mozilla giving their own websites special treatment. It would look bad for any site to be infested with adverts or to be hijacked when it's not the website owner's fault - Mozilla doesn't have the Monopoly on that.

To me, this sounds like an issue where there's gaps in the Addon review system or the ability to notify users of malicious addons, and they are trying to solve that larger problem with a little band-aid.

But given there's about:config setting, I guess it's not that big of a deal

[Thorin-Oakenpants]

I'm not saying yes or no, I'm just throwing some thoughts/notes at you

RFP is easily detectable too and the large majority of FF users don't use it

I don't buy this comparison. You can't compare RFP with DNT. RFP specifically lowers entropy, including unique values (canvas, yes I get that there are extensions) or very-near unique values (screen/usable-screen/browser/inner-window measurements), and the set of 20 or 30 items it standardizes for users drastically reduces FP'ing. It's a no-brainer. Also, all RFP users would still ALL be identified as RFP users, which is the whole point - that the RFP set is uniform, so being ID'ed as a RFP user doesn't add any real world entropy. DNT is not aimed at FP at all (but it's value adds bits).

because it's opt-in, it puts us in smaller group FP-ing-wise

FP'ng is a worst case scenario. Most of us limit the vast bulk of FP'ing capability already, so the downside is sweet F all, IMO. If you do get FP'ed, there are so many other mechanisms no one has bothered with really: scrollbar width can identify specific linux platforms, cipher suites (we are at default), media capabilities (nothing has to play, see the HTML5 youtube test page - we're at defaults), etc. A DNT value with three options (not specified, true, false) is hardly going to make a difference - although it's sent with the header, and thus not a JS/3rd party item.

GA on Moz*

A couple of sites don't dictate our decisions. That the pref fixes AMO's GA is incidental.

with the new law in Europe, explicitly telling sites to DNT might even be useful in courts

Courts? Who cares. I think it might actually (now) influence what some EU sites do, IDK.

at least until more people start using it

Well, only FF has it (AFAIK, @fmarier ), and they're at ~6% (desktop + mobile). But we're already ID'ed as FF, so it's what % of FF users use DNT. PB mode bumps this up, as does users who have TP on in all windows. It's not 50/50 .. but whatever it is, it's not as bad as everyone thinks.

tl;dr: I don't see any cons. It's always been a line call. With the new TP lists coming, I can see DNT growing.

---

@overdodactyl Harden up bro... Mozilla have every right to protect their services from being exploited - imagine the bad press if a rogue extension stole people's account details - etc.

Logistically, as for the AMO signing, it's probably not feasible to catch everything automatically when submitted - extensions on AMO itself can be policed (public, reviews), but not those which aren't published on AMO. And Mozilla probably don't keep copies lying around. Not sure how they could add them to extension revocations. It's EASIER and makes sense to protect the domains concerned.

[overdodactyl]

Of course they have the right to do it...doesn't mean I have to like the decision. We will just have to agree to disagree on this one

[Thorin-Oakenpants]

Do you want a hug bro? They gave you a pref to control it :)

[overdodactyl]

given there's about:config setting, I guess it's not that big of a deal

https://github.com/ghacksuserjs/ghacks-user.js/issues/422#issuecomment-392810137

[earthlng]

@overdodactyl

I don't like it either but I understand why they did it. If a malicious addon would manage to steal millions of user's sync account and copy all their synced private data, it could be the end of mozilla.
IMO it's fine as long as they don't remove the about:config pref.

You're probably right about the review system but I think they had to change the review process, at least temporarily, because of the switch from legacy to webextensions.
Hopefully they'll change it back to review-first-publish-later at some point, but even then it's not guaranteed that they catch every malicious addon.
It's also possible that they plan to eventually support WE's from the Chrome store and if that's the case they need to protect themselves and the users from what's at that point completely outside of their control.

[earthlng]

DNT vs RFP ("I don't buy this comparison") - I only compared it in terms of putting us in smaller groups

Courts? Who cares.

Companies care. Why do you think they try to comply with the new law? It's because users could sue them. Doesn't mean someone actually has to go to court - the threat of it is enough.

[Thorin-Oakenpants]

DNT vs RFP ("I don't buy this comparison") - I only compared it in terms of putting us in smaller groups

Ahh, OK. RFP+DNT vs RFP+noDNT. I actually think RFP users would be more likely to use DNT ¯\_(ツ)_/¯

Companies care.

Ahh OK. I meant I don't care about courts. But's it law, so companies must comply, I thought that was a given. What I meant was that DNT may now influence what a site does. DNT is voluntary, but could be taken as a sign that the consumer said "no" (in the EU). IDK, IANAL :) ¯\_(ツ)_/¯

anyway

I'm fine with it being flipped. We'll need to clean up 1610 - drop the NS line etc

/* 1610: ALL: enable the DNT (Do Not Track) HTTP header
 * [SETTING] Privacy & Security>Tracking Protecting>Send websites a "Do Not Track"...
 * [SETTING-ESR52] Privacy>Use Tracking Protecting>manage your Do Not Track settings
 * [NOTE] DNT is enforced with TP (see 0420) regardless of this pref (e.g. in default PB Mode) ***/
user_pref("privacy.donottrackheader.enabled", true);

If you like it, do a commit

[Thorin-Oakenpants]

hey .. FYI ... https://bugzilla.mozilla.org/show_bug.cgi?id=1415644 was opened up

[overdodactyl]

Thanks! An interesting read for sure...glad they opened it up

[Thorin-Oakenpants]

With the new TP lists coming, I can see DNT growing.

And in FF62... TP gets more prominence 1462468