Why does the example user.js in the wiki use modified values?

Trying to wrap my head around how updating and maintaining one’s config works.

The example from the wiki that explains how to enable session restore lists user_pref("privacy.clearOnShutdown.cookies", true); even though it is set to false in user.js.

Is this just a wiki’s oversight/outdated entry, or am I actually supposed to manually modify things inside user.js and not just user-overrides.js? The wiki seems to strongly discourage that.

Question 2: I put the following lines in my user-overrides.js:

// user_pref("browser.safebrowsing.downloads.remote.enabled", false);
// user_pref("browser.safebrowsing.downloads.remote.url", "");

because one of the first pages in the wiki recommended to not use those settings, and ran the updater script, but all that seems to have done was append the two lines to the bottom of user.js. I thought it would reset the two settings to their default values. So then how do I undo the setting?

[Thorin-Oakenpants]

What’s the point of putting that in overrides if it has no effect?

because recipes include potential footgun prefs that arkenfox currently has, or has had in the past (active or inactive) but within reason (I’m not going to list items that were removed a year ago)

why are some prefs in user.js commented out

many are listed as optional or don’t bother: so by default they are inactive (commented out)

the personal section is nothing to do with privacy etc, so they are also all commented out. Your example is one of these. That said, we did make four active (i.e not commented out) because it seems everyone does that and it saves using overrides

Or do you simply list every single config in existence and comment out the irrelevant ones

please, show some respect 😃 We do not simply list preferences. What is added is researched, tested, references provided etc

and fuck no 😃 there are in excess of 3000 prefs off the top of my head (but I’m not going to count them) and they are constantly changing - 70 to 100 prefs per release. Over an ESR lifecycle that could be 700 or 800 prefs coming or going and changing values

---

Is this to signify that this is a pref that could be of interest

read the section headers: don’t bother, don’t bother fingerprinting, optional hardening, optional opsec, personal

That leaves 44 inactive (commented out) prefs up to and including section 4500. And that’s the idea, they are of interest: many have tags such as warning or setup

The current 44

• they are there because they are all relevant and provide FYI factor
  • some simply for the info
    • e.g. geo.provider.network.logging.enabled
    • e.g. a bunch of items in section 2800 to make a complete set
  • some as a warning to not use (and prefsCleaner will reset them)
    • e.g. three privacy.resistFingerprinting prefs
  • some in case you wanted to harden
    • e.g. 6 extra Safe Browsing prefs (for the record I do not consider this hardening, to me it’s more about the info factor)
    • e.g. 2 webrtc prefs (one if you use webrtc and it works for you, and one if you leak your public IP without allowing webrtc connections)
    • e.g. 2 proxy prefs (if you use a proxy and understand the potential risk) - how can arkenfox know if you use a proxy, the only safe default is to have them inactive
    • e.g. layout.css.visited_links_enabled - not the same as an optional opsec as that section is about hardening that causes breakage and issues
  • some because mozilla might flip it
    • e.g. browser.send_pings
  • some because they differ in nightly/beta vs stable
    • not sure which one(s) - telemetry related

Here those 44

• i could actually remove some of them, but not by much

   // user_pref("browser.crashReports.unsubmittedCheck.enabled", false); // [FF51+] [DEFAULT: false]
   // user_pref("browser.safebrowsing.allowOverride", false);
   // user_pref("browser.safebrowsing.downloads.enabled", false);
   // user_pref("browser.safebrowsing.downloads.remote.block_potentially_unwanted", false);
   // user_pref("browser.safebrowsing.downloads.remote.block_uncommon", false);
   // user_pref("browser.safebrowsing.malware.enabled", false);
   // user_pref("browser.safebrowsing.phishing.enabled", false);
   // user_pref("browser.search.region", "US"); // [HIDDEN PREF]
   // user_pref("browser.send_pings", false); // [DEFAULT: false]
   // user_pref("browser.urlbar.suggest.engines", false);
   // user_pref("dom.security.https_only_mode.upgrade_local", true);
   // user_pref("dom.security.https_only_mode_pbm", true); // [FF80+]
   // user_pref("extensions.getAddons.cache.enabled", false);
   // user_pref("extensions.update.autoUpdateDefault", false);
   // user_pref("extensions.update.enabled", false);
   // user_pref("extensions.webextensions.restrictedDomains", "");
   // user_pref("geo.provider.network.logging.enabled", true); // [HIDDEN PREF]
   // user_pref("layout.css.font-visibility.private", 1);
   // user_pref("layout.css.font-visibility.resistFingerprinting", 1);
   // user_pref("layout.css.font-visibility.standard", 1);
   // user_pref("layout.css.font-visibility.trackingprotection", 1);
   // user_pref("layout.css.visited_links_enabled", false);
   // user_pref("media.autoplay.default", 5);
   // user_pref("media.gmp-provider.enabled", false);
   // user_pref("media.gmp-widevinecdm.enabled", false);
   // user_pref("media.peerconnection.enabled", false);
   // user_pref("media.peerconnection.ice.no_host", true);
   // user_pref("network.dns.disablePrefetchFromHTTPS", true); // [DEFAULT: true]
   // user_pref("network.proxy.allow_bypass", false); // [HIDDEN PREF]
   // user_pref("network.proxy.failover_direct", false);
   // user_pref("network.trr.mode", 5);
   // user_pref("permissions.default.shortcuts", 2);
   // user_pref("privacy.antitracking.enableWebcompat", false);
   // user_pref("privacy.clearOnShutdown.openWindows", true);
   // user_pref("privacy.clearOnShutdown.siteSettings", false); // [DEFAULT: false]
   // user_pref("privacy.clearsitedata.cache.enabled", true);
   // user_pref("privacy.cpd.downloads", true); // not used, see note above
   // user_pref("privacy.cpd.openWindows", true);
   // user_pref("privacy.cpd.passwords", false); // [DEFAULT: false] not listed
   // user_pref("privacy.cpd.siteSettings", false); // [DEFAULT: false]
   // user_pref("privacy.resistFingerprinting.exemptedDomains", "*.example.invalid");
   // user_pref("privacy.resistFingerprinting.letterboxing.dimensions", ""); // [HIDDEN PREF]
   // user_pref("privacy.resistFingerprinting.testGranularityMask", 0);
   // user_pref("privacy.userContext.newTabContainerOnLeftClick.enabled", true);

[github-account1111]

Okay so it’s an outdated entry, got it. But in that same example, and even the recipes page, the following is listed under overrides:

// user_pref("privacy.clearOnShutdown.cookies", false);

What’s the point of putting that in overrides if it has no effect? I thought prior to opening this issue that it would remove the line that says user_pref("privacy.clearOnShutdown.cookies", false); in user.js and reset the pref in prefs.js using the prefsCleaner script.

One more question: why are some prefs in user.js commented out?

// user_pref("browser.tabs.closeWindowWithLastTab", false);

Is this to signify that this is a pref that could be of interest to the user, so even though it’s not used, it is something that could be worth changing? Or do you simply list every single config in existence and comment out the irrelevant ones? My guess is it’s the former because there are prefs that you don’t list at all.