I don't think we need a 4 yr old article to explain the concept of `.min` (or `.max`), it's pretty self explanatory (and SSL 3 is obsolete). Three lines of text culled, and one of the remaining http links eliminated as a bonus. Enjoy the saved bytes and mouse-scrolling.
De-duplicates many lines because the -ESR and -RFPalts options require too much boilerplate garbage. The script was unreadable enough without repeating code.
I don't think these changes deserve opening yet another PR, but please let me know if you disagree.
- no need to enforce defaults (except the second cross-origin) = less items in prefs and about:support
- simplify header info
- add in that you need an extension for real control: i.e for most people, e.g I use uMatrix and have never can to whitelist anything. Kolanich has been on settings of 2 for years and only found one broken site: these are anecdotal and don;t reflect the real world: which is why the settings are pretty relaxed
- move the broken info out of header and onto the pref in a setup tag
- reference: https://github.com/ghacksuserjs/ghacks-user.js/issues/716#issuecomment-488527274
- thanks Kolanich and 🐈
- the two reportURLs required the user to actively opt to send a report
- the other five reporting URLs use Mozilla domains, which is not a problem. Not entirely sure if they get used or how, don't care
- the dataSharingURL is not needed, the corresponding .enabled pref is sufficent
- 0910 same as default for desktop. Android is the opposite, must be for a reason. Android is not really my concern.
- 1005: always been inactive: one less warning to deal with
- 1008: always been inactive. defaults are 60, 60
All of these are the same as default, checked back to ESR60 and Ff60. Except 2211 which is not considered an issue by TB for example, and it doesn't enhance anything IMO
Lets be consistent, we don't make min active as it alters your FP, and the risk is super low (updated the telemetry stat: down from 2% to 0.5%). Default max is now 4 anyway (don't care about ESR - they should be using the v60 archive).
Instead of being inactive, remove this. WebRTC is already blocked. And it can also be controlled by 1820. Redundant and does nothing extra for privacy, security etc
At best disabling the background update of gmp means not only an extra item for those who wish to use it (e.g widevine, netflix) to have to deal with, but also a time delay in getting the actual download. At worst, it could cause users to use an old dll (security risk).
I will leave it in, for now, but am seriously considering removing it, so don't cry if I do.
- SB: disabling it nothing to enhance privacy/security etc if changed from default
- SB: I will not provide the prefs or encourage users to disable these, especially given that there is a UI
- SB: the urls are redundant
- SB: note: the binary checks stays
- TP section is out of date (or soon will be), I'm not maintaining it, it has a UI and is best handled there
- explain pitfalls, add keyword tip, add setup tag
- given the searchbar is hidden by default in new FF installs, a lot of people could find this incredibly annoying (not being able to hit enter), including users who have changed their search engine - hence the setup tag
- these are not needed, you can view your cache in about:cache, or look at your `profile/cache2` folder (at least for portable Firefox), the remaining pref is enough to achieve the desired result
- browser.cache.disk.smart_size.first_run is set internally (for me it got automatically reset to modified false)
- the other two prefs are just more things for users to have deal with if they want to use disk cache
- Used setup-web since it relates to actual web pages, even though it doesn't break them
- Added the tag because it's an item that is likely to get attention / troubleshooting
- Added a warning tag to make the risk more apparent.
- Slight edit to the 2803 references
- to avoid confusion with the setting tag, split the prefs into separate numbers, thus shove 2031->2031, reuse 2031
- remove the default value notation as Mozilla will roll out default change gradually to users
TAAR is extension recommendations in the "Add-ons Manager" (not sure how it's displayed)
CFR is extension recommendations as you browse the web, via a drop down panel
- description needs to stay changed from just cookies since it also clears site data
- keep the info about n days out of it, it's just messy (ESR users should be on version 60)
- get the values correct (I mixed them up earlier)
- fixup [setting] path
- leave in one (of two) extra [notes] I previously added
whatever we thought it may have done in the past, it doesn't do that now as far as we know. And it's not an issue since we allow extension update-CHECKs anyway.
regardless of this pref setting: the permissions.sqlite file will still be abused to store a flag for this for every single site you connect to (as third party?) - fun.
* clean up "Firefox Data Collection & Use"
- telemetry prefs to 330's
- Firefox Data Collection & Use prefs to 340's (but leave crash reports in 350s)
- move `app.shield.optoutstudies.enabled` to 330's - this is an internal pref which controls if you get the system addon
- make notes that `datareporting.healthreport.uploadEnabled` controls studies and ext recommendations
- split crash reports better to reflex the UI setting
`browser.urlbar.maxHistoricalSearchSuggestions` is default 0 is FF60 thru to FF66. It is also default 0 in ESR60.1 thru 60.5. (at least on Windows)
IDK if this has ever been used, maybe android, in which case it's probably useful?
The location bar dropdown cannot be disabled via prefs except with css, in which case the whole thing is hidden regardless of he above prefs. So there is no point in making any of them active. This is also in line with what we can achieve with relaxed and hardened tags / sticky issues - that is we can find a better balance, Shoulder surfers is a low risk, not even Tor Browser disables this stuff. People need to take responsibility and/or use common sense. Sure, we can leave em in for users to know about and enable if they want. End of story.
userChrome.css code is
```css
/* locationbar dropdown FF65+ */
#PopupAutoCompleteRichResult {display: none!important;}
```
might as well add it: needs t be taken into consideration when looking at the whole http2 thing. Will be interesting to see what Tor Browser does with it in ESR68
it's too hard to follow AS changes, and work out if disabling showing items (basic toggling of show/hide sections etc) actually stops downloading a localized local copy etc. For items we actually want to block, let the endpoint slaughter begin.
let's just coverage-our-ass on this one
While I don't mind telemetry (development needs meaningful feedback to better the product), and I trust the data is not PII, and/or anonymized into buckets etc (you can check this you know), and I understand this one needs to be outside the Telemetry pref in order to gather the one-time ping ... and I trust Mozilla's motives ... I'm starting to get a little annoyed at the non-stop incessant increasing telemetry bullshittery and ass-fuckery around sending data home, and the lengths some Mozilla devs will go to, to hide this info (hidden prefs, access denied tickets to hide discussion of what should be public, and even **not even adhering to their own documentation**).
I will also be killing as many Activity Stream endpoints as well - as long as they are in line with our js - pocket, snippets, onboarding etc. And I will add those from personal as inactive for end-users - eg cfr
remember the new Coverage Telemetry shit? with a **hidden** opt-out pref? guess what, they are already collecting for 3 months ...
https://bugzilla.mozilla.org/show_bug.cgi?id=1487578 - **3 months ago**: "I see data coming in that looks reasonable"
guess what else ...
"It has also replaced the previous version that was there (from bug 1480194)" and oh, surprise surprise, 1480194 is ACCESS DENIED!
they're not just using private tickets to hide security critical information from potential hackers and blackhats, no they also use it to hide shady AF things. Things that they fully know are shady as fuck and that they absolutely know a lot of people would not like. There's simply no other reason why they'd do that
but wait, that's not all. If you think an opt-out pref that 99% of people wouldn't know about even if it showed up in about:config BUT ALSO HAPPENS TO BE HIDDEN is kind of questionable, well ... the system addon that they use for this shit apparently looked or still looks for `toolkit.telemetry.coverage.opt-out` [1] instead of `toolkit.coverage.opt-out` as their documentation [2] claims
[1] https://github.com/mozilla/one-off-system-add-ons/pull/131/files#diff-6e0cbf76986d04383ccb32a29ef27a7aR25
[2] https://hg.mozilla.org/mozilla-central/file/tip/toolkit/components/telemetry/docs/data/coverage-ping.rst#l32
It's time to opt out of all that shit for good. Disable system addon updates and kill it at the root
> In FF61 and lower, you will not get any System Add-on updates except when you update Firefox
on its own that's not true. You will get SA updates unless you disable app update checks + auto install. Let's just remove that as well.
* move 1260 to 122x
"disable or limit SHA-1 certificates" is about certs, not ciphers.
Because CERTS is 1st in the title I moved it to the 1st item there because it's arguably also the most important of the lot (and renumbered the rest)
We can also drop HSTS from the subgroup title because there's nothing HSTS left atm.
FYI, the https://www.privacytools.io/webrtc.html test in our wiki is 404, so I gave it a strikethru and added this one. This is also handy for 2001, but do we need to double up on it? We're only disabling WebRTC because of IP leaks, so I don't see the point in testing if WebRTC is disabled.
Session Restore cannot be disabled in Normal mode, it is also used internally. FYI: PB Mode does not use Session Restore. The description is still not 100%, as it refers to what is restored, not what is kept in the recovery.jsonlz4 (at least for tabs)
flipped true in FF54: https://bugzilla.mozilla.org/show_bug.cgi?id=1026804 but unsure when the pref itself was introduced. note: other timing prefs were always in 2400's see 4602: [2411] disable resource/navigation timing / 4603: [2412] disable timing attacks
it has zero to do with privacy etc, and in fact most users will only ever encounter it once (and check the box) when they first go to about:config, so it's not even useful as an override or a new profile IMO. This removes one of three numbers that don't have a section
when argument `-l` is used, parse profiles.ini instead of just listing folders in the default profiles dir.
This allows to select profiles located outside of the default profiles directory and makes selection easier because it also shows the profile name (and selection is by number instead of having to copy-paste a path)
* Uses `perl` as a last resort if `curl` and `wget` are not available (fixes#537)
* Aborts and notifies user if none of the above are installed
* Better use of functions
* When version numbers are checked, the contents are immediately saved to a temp dir. This allows us to skip using wget/curl/perl a second time
* Improved messages for users
* Added various font colors for ease of use and aesthetics
TLS 1.0 and 1.1 are still secure. Sure, later versions are more secure, but 98% of the web is already upgraded - less than 2% of sites use < v1.2. So it's not very likely you would come across a site that requires it, but if you did, what's the point in breaking it. Mozilla and Chrome already have plans to deprecate TLS 1.0 & 1.1, and force that last 2% of sites.
TLS settings can be FP'ed without JS. By sticking with the defaults, I do not see any security issues, but an increase in potential anti-FPing. TBH, the chances of either (i.e being FP'ed with TLS as a entropy point, or being compromised due to TLS<1.2) are slim to non anyway.
Any arguments, please see @earthlng
Pants said "We do not need to keep anything for ESR users. ESR users are on v60, and we have an archived 60 for them."
This isn't even affecting ESR60 but only older versions.
* removed, renamed or hidden in v63.0
- 0301a - do you want to add the `[NOTE] Firefox currently checks every 12 hrs ...` to `0302a` ? The problem is it also checks for updates every time you open/reload about:preferences and in Menu>Help>About Firefox regardless of when the last check was.
- 0513 - removed because follow-on-search is no longer a deletable system addon
- 2703 - do we just remove `3=for n days` or add a [NOTE] that value 3 was remove in FF63 or something?
- `browser.ctrlTab.recentlyUsedOrder` replaces `browser.ctrlTab.previews` but it now defaults to true. No need to list the new one under 5000 IMO
* Update user.js
* 1031 add more info
https://bugzilla.mozilla.org/show_bug.cgi?id=1453751#c28
* 0301a: remove update-check timing info
* 2703: add version deprecation for value 3
- pref removed in FF63 (https://bugzilla.mozilla.org/1476879)
- when we added it the default was false
- default is true since FF57
- it's only an UI thing
ergo we don't need to move it to 9999
* more infos
* add colons
not all EOL comments for defaults start with `// default` (23). The common string is `default:` (27 incl. these ones) with or without preceding or trailing spaces
* replace /V with global VERIFY ON
* change working dir to script dir
The working dir doesn't necessarily match the script's path, depending on how the script is called. All relative paths and conditional statements using EXIST will fail whenever the working dir is not the script's own location. This fixes that.
* minimal stuff, mostly cosmetic
* prompt to run prefsCleaner under very specific circumstances
* improve -updatebatch option
* add version variable + display new script version on update
I think there's no way to get rid of ^M but hopefully with `*.bat -text` in `.gitattributes` it shouldn't be a problem because git won't do any line conversion on check-in/out.
This way the raw link as well as the file within the zip download should be in proper MSDOS CRLF format, and git status shouldn't report the file as modified either. ***fingerscrossed!!***
FF61 introduced quite a few changes, including removing the ability to set a blank startpage in the UI, and a new Home options tab with unified Activity Stream (AS) defaults and dropdown options. Because the only way to stop AS on startup is to enforce a blank page (pref 0102), and setting this auto changes `home+newwindow` (0103) and `newtab` (0104) to a blank page, then we're just going to go ahead and enforce that on all of them.
For more info see the discussion in #426
Both deprecated in FF61, but we'll remove them from the user.js
- `services.blocklist.signing.enforced` is default true since FF50
- `browser.storageManager.enabled` only controls "Site Data" UI visibility
2732 was just enforcing default since at least FF52, and 2733 has never been used, was only there for info. Offline Cache or appCache (2730) is already behind a prompt (2731), and is already limited (in FF60+) to HTTPS (2730b).
Note: I am not 100% sure what happens with an app update. If this is divorced from that check now, you should be able to get FF updated without any system addons. We'll have to wait until 62 needs an update to test it. In the meantime I've edited the [NOTE]. I've also left this inactive (eg imagine if they pushed a critical update for formfill), so this is an end-user decision. Added to sticky to revisit this pref
I see no point in keeping this to enforce a default that FF itself doesn't use - see https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent/Firefox
- "... is an optional compatibility token that some Gecko-based browsers may choose to incorporate, to achieve maximum compatibility with websites that expect Firefox"
The last one-off ESR cycle of 8 releases is now behind us, new algorithm for FF60+ is back to 7 releases per ESR numbering, starting at 60... 67... etc. Note: This does not do anything for Aurora or Nightly spoofing the next ESR early (but we have until Nightly 67 before this becomes a problem). The ticket 1418162 was meant to cover this but instead was just used for the new algorithm. There is currently no ticket for the Aurora/Nightly issue - but never fear, Pants is here!! It is not forgotten, and I have emails with Tom Ritter et al on it
* updated shebang
* The script now compares its version number to the one online. If there is a newer version of `updater.sh` online it ask the user if he wants 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` instead of causing more bloat in the profile directory.
- massive speed improvement !! m-a-s-s-i-v-e !
- small fix to the time format used in backup filenames (replace space with zeros)
- better tolerance for special characters within preference names (which counters [the one downside that v1.2 brought along](https://github.com/ghacksuserjs/ghacks-user.js/pull/321#issuecomment-354394222)).
- other minor things, mostly to do with Delayed Expansion and the removal of it
known issue (but not really an issue):
- it skips instances of `user_pref` that have any quote or double-quote before `user_pref` (like `// "this" user_pref`)
AS is out of control. No master switch in FF60+, and in order to 100% sure nothing is collected locally (or external connections made), there are now some 28 prefs (including those coming in FF61). This is re-DICK-ulous. We're not going to bother tracking all that, let alone the labyrinth of code. All users are advised to just make sure they remove the XPI every time they update FF.
2711 is about web extension data and does not fit in the 2700s is all about websites' persistent data, i.e items that sanitizing and Storage Manager deal with. Dumping in 2600's which is getting a revamp later
* Options> and [settings]
While I'm at it, I'm changing the 21 instances of
- `[SETTING-56+]` to just `[SETTING]`
- `[SETTING-ESR]` to `[SETTING-ESR52]` because we'll leave those in until 62 (yes I know they may apply to earlier ESRs, but people should be upgraded). Thus no ambiguity with ESR60 vs ESR52 users for the overlap
This is so wrong: It is better to inform users that 3 **must** be used than rely on zero info as well as removing useful info on what the values do. All future issues with this will be directed to earthlng. Remove RFP info as RFP users should know this stuff if they turned it on. Non RFP users, who we told they can bypass it, will not have a reference to RFP now. Enforce will now be banned as a word because, "reasons".
add `browser.storageManager.enabled` back but enforce it as true - otherwise people may never pick up on the fact we dropped it and may never reset it, and never see their shiny new UI section. When it's deprecated, *then* we can remove it
pref will be removed, 99% sure it was just a pref used internally to hide it from stable during testing in beta/nightly - see https://bugzilla.mozilla.org/show_bug.cgi?id=1428306. Makes zero sense to hide this new UI section since we will be turning SM on anyway (the section is important for end users to exist and be working esp thru QuotaManager and Storage v2 changes etc).
note: picked up a leading space on 2206. Please double check for any errors or missed opportunities (I scanned it three times), 1221 is about the only one that's a bit messy I think
Note: I moved the (part`x`) bit to the end of the bugzilla from previous commit as I like the https* bit to all be in line = visually easier to parse IMO
This is a start to reducing section 2600 (which I renamed it to just miscellaneous). We can always revisit this new section and add to it down the track if required. Note: added a second ref [2] under 0703. Note: re-numbered & re-positioned deprecated prefs for SPDY
These are all at default values, no need to enforce. As for removing them, we're de-cluttering the section and these just aren't that important. Anyone who wants to play with tab ordering/focus/etc could probably use an extension (API's?) and/or easily find these and look them up
geolocation blocking via RFP will be removed (see https://bugzilla.mozilla.org/show_bug.cgi?id=1441295), and since either way you look at it (those who use RFP or not) the user.js blocks geo, so we might as well move this stuff back to section 0200
1376865 was back ported to 59, so canvas prompt fatigue will be reduced. Note: the default for non-prompts is the same as if you clicked "Don't Allow" - i.e it serves up a 10x10px white square
Cleaning up the UA spoof stuff in the sticky, as a ticket was just closed (52 is now a temporary hard-coded value: 1418672 - I guess they're running out of time), so also cleaning up the info, and consistent layout
Two issues: The code to determine the ESR number is out of whack (by one) since the next ESR is 60. 59 stable is almost here. So they have decided to hard-code the value as 52, for now. The second issue is that Aurora/Nightly are ahead of stable/ESR and can thus unmask themselves as Aurora/Nightly. The hard-coded value for now also solves this.
If you follow the sticky for RFP, you will see there is a ticket for using the update channel information (eg stable, beta, dev, nightly etc) to determine when and how calculate the version spoof in future, and they'll also rejig the numbering algorithm to account for ESR being out by one. These are tickets https://bugzilla.mozilla.org/show_bug.cgi?id=1418162 and https://bugzilla.mozilla.org/show_bug.cgi?id=1428111
These default values are the same in all OSes and all current Firefox versions (ESR, Release, Beta, Nightly).
Apart from alerts.showFavicons these defaults are most likely never gonna change
data: works perfectly fine here. No need to use https and no need to connect to localhost because something could be listening there.
data is the fastest and best solution.
Note: I tested the value of 1 when changing from 2-block to make sure that it actually changed to allow in the panel. Am keeping my eye on the delete and backspace keys and will remove the line when it is fixed
Changes:
- The script doesn't touch the `user.js` file until it really has to.
- The merge function is a bit smarter parsing files, at no significant cost.
- Fixed a minor issue with the version check.
- Minor syntactic changes here and there.
- creates timestamped backup files rather than always overwriting user.js.bak.
(use -singlebackup if you prefer a single backup file)
Changes:
-The script doesn't touch the user.js file until it really has to.
-The merge function is a bit smarter parsing files, at no significant cost. See examples below.
-Minor syntactic changes here and there.
Additions:
-New -multiBackups argument. I personally intend to use it to compare files and quickly review changes.
- Search string made case-sensitive, because Firefox preferences are.
- The script now uses regex, which allows it to understand `user.js` files formatted using single quotes, spaces and/or tabs in `user_pref` lines.
Trade-off: it can no longer reset preferences that include some special characters in their names. Not an issue for now, just something to remember.
See full discussion [here](https://github.com/ghacksuserjs/ghacks-user.js/pull/321).
- Search string made case-sensitive, because Firefox preferences are.
- The script now uses regex, which allows it to understand user.js files formatted using single quotes, spaces, or tabs.
Trade-off: it can no longer reset preferences that include some special characters in their names. Not an issue for now, just something to remember.
Fixes:
- Merge function:
*no longer has the potential to truncate super long lines. (8KB per line still IS the max!)
*no more issues with exclamation marks in user_pref lines.
Improvements:
- Overall better performance due to ECHO syntax changes.
- Merge function on steroids! Faster than ever
Changes, Additions, Substractions:
- Leading spaces are no longer ignored by the merge function. Lines to be merged must begin with user_pref.
- Added header with name, author, version.
- Added help sub-menu.
- Added special message when no override files are found when using -multiOverrides.
- Formatting changes.
Fixes:
- Merge function:
*no longer has the potential to truncate super long lines.
*no more issues with exclamation marks in user_pref lines.
Improvements:
- Overall better performance due to ECHO syntax changes.
- Merge function on steroids! Faster than ever, and no longer generates temporary files at all. As it always should have been.
Changes, Additions, Substractions:
- Leading spaces are no longer ignored by the merge function. Lines to be merged must begin with user_pref.
- Added header with name, author, version.
- Added help sub-menu.
- Added special message when no override files are found when using -multiOverrides.
- Formatting changes.
-updatebatch now will (or at least should):
*Download new batch and name it [updater]*.bat
*Open that script in a new CMD window.
*Exit
The [updated]*.bat script should:
*Copy itself overwriting the original batch (without renaming).
*Start that script in a new CMD instance.
*Exit.
The new script, with the original name, should:
*Delete the [updated]*.bat script
*Begin the normal script routine.
@earthing do you think I should still rename the scripts to .old or something before overwriting/deleting?
It ended up being a mixture of the previous commit and the fix. It writes a temporary file on the go that only holds preferences, and generates the target file at once at the end. It's slower than before, but it works.
While I figure out a fix for the missing characters...
Enclosing the whole merging loop in parentheses and replacing the source file with the entire output at once is more efficient than appending individual lines with >>%~2. The script doesn't have to wait for the HD to continue processing.
Everything in a line after a powershell call is considered as being called from PowerShell.
>nul didn't work because of that. Enclosing the line in brackets should fix it.
To account for the possibility of the user running the script silently in the background. PAUSE would leave an instance in memory doing nothing indefinitely.
I was going to use TIMEOUT but PING performs better.
- keeps all user.js.parrot lines intact
- keeps empty lines intact
- fix for keeping `!` and `^` in non-"user_pref" lines intact
+ some other minor changes + streamlining
You had it right the first time earthlng. Eg Start commits for 55-beta date shown is 9-July. 55-alpha release is dated 18-Aug and we drop the "-beta" part (look inside the release downloads). Start commits for 56-beta date shown is 12-Sept. 56-alpha release is dated 2-Oct and we drop the "-beta" part. And because you created the 57-alpha release before you reversed the date+version, that too is all good.
Controls the visibility of the "Options>Privacy & Security>Site Data" section.
I'd prefer to remove this completely because it only adds to the confusion about all the different storage types.
This is just an extension for localStorage (2705) with 3 methods: estimate(), persist() and persisted(). A site can ask for permission (?) to persist data which when granted basically just means that "Storage will not be cleared except by explicit user action" whereas otherwise when not persisted "Storage may be cleared by the UA under storage pressure." - I don't see a problem with that.
We'll keep 2706 inactive for now but might remove it in a future commit.
https://github.com/ghacksuserjs/ghacks-user.js/issues/264#issuecomment-345462158
- It can now handle read-only files.
- it is somewhat more explicit regarding what it's doing in some circumstances. For example, it now informs the user when no changes are made.
- It now accepts two parameters: `-unattended` and `-log`
- Minor improvements here and there.
Sorry, but AFAIK, with this enabled it clears web extension storage when clear "offsite website data" is checked on close or manually (which we do in the user.js). Note also that even with this enabled, the UI settings are disabled, and the data-on-disk calculation never finishes, so at this point, its a bit useless to enable it until we figure that out. Will be back in 7 days
this should now work no matter how the script is called (including symlinks) on both Mac and Linux.
+ Storing and restoring the original working directory to prevent problems in certain circumstances.
"Push and web notifications require service workers, which in turn require workers." - this is clearly not (or no longer) true. See #256 where workers are disabled, but service workers enabled, and service workers create IDB entries on Youtube
this is a linux only pref, does nothing in Windows or Mac, as per tagging convention => [LINUX]. Here's a 15 year old ticket - https://bugzilla.mozilla.org/show_bug.cgi?id=160200 .. enjoy! PS: Trying to find an autocopy text (excluding form fields) that auto trims, auto removes multi-spaces, auto trims, and auto removes double blank lines .. I had one, but its legacy. Best I can find is https://addons.mozilla.org/en-US/firefox/addon/autocopy-webextension/ - a wee timer in options lets you control when you copy (that's ok), but it gives a notification every time which is annoying as f - anyone got any ideas
- In FF55 (windows) this no longer changes both prefs, only `layers.acceleration.disabled`
- `gfx.direct2d.disabled` => inactive (I do not think it is used much if at all anymore - do a DXR search)
Inactive as this actually can cause problems on Linux with tofu (I think arial on debian causes tofu - ask nodiscc) . Also incomplete with non-Western settings
Inactive: 1: currently only three sites (hard-coded) can access this, all run by Mozilla 2: it is likely to be used on the new AMO site to determine your Firefox version
Sidenote: Not sure if this is true anymore. Since I ditched CTR and I have the hamburger menu back, it loves to annoy me with a doorhanger ALL THE F**kng TIME - certainly not 8 days grace. Seems more like 12 hours (but I swear it also comes up soon after a restart as well)
it's most likely covered by disabling extensions.formautofill but is nice to know for people who want to enable form-autofill but may want to disable creditCards autofill
The bulk of 2507 with `dom.keyboardevent.code.enabled` (links, description etc) is now deprecated in section 9999 under FF55+. This leaves `dom.keyboardevent.dispatch_during_composition` as a valid pref. It's default is false, so rather than leave it hanging out on it's own with no info, lets remove it. [If it ever becomes true we will pick up in diffs]
- should check if 0360 `user_pref("browser.newtabpage.directory.source", "data:text/plain,");` is still around since the ping pref is gone.
- A bit iffy about 2507 - this spilts two prefs and there's a lot of text. Not sure if FF38+ refers to the second one. We should investigate the still active 2507 and fix that up with some info and version
the default value in 54 is true. It's not in my OS diff for 54 either so it's true on Linux and Mac as well. I don't think anyone would want to disable this anyway, and we have it as "enable APZ". It's only wasting space, let's remove it. class discuss xD
moved screenshots up to 0515 and added the FF54 pref. I know I said we can remove that pref but the item needs to be for FF54+ regardless. To make it less confusing I added the pref back in.
The default is false in FF54 (and also in FF55 beta), so there should be no downsides. Not sure how this will affect AutoFormFill system addon, and don't care since we'll disable that as well
Non e10s and non WebExtension = out the door. NoRedirect & Disable IndexedDB were not e10s, and Cookie Controller is not WE (and besides, there are lots of cookie alternatives). I think that's all of them. In fact I think the only extensions left mentioned are uBlock Origin and NoScript
Also `addon-ons` typo not picked up by Just-me-ghacks - I am bitterly disappointed.
Add missing parrot for 1100s, replace parrot for 1700 with a unique euphemism, a readme tweak (so it's technically correct), and deprecated pocket number change in prep for new system add-on section
I removed the "(hidden pref)" info when we revamped 2699, as it will no longer be hidden. In hindsight, that info needs to stay (we haven't archived off end-of-life 54, and it's good information for backwards compatibility).
Nits, review syntax etc. Note: 2 items missing deprecation bugzilla tickets, we can get those in time. Note if each section number is made active, the prefs are also - except those which either match the current js (eg TP/SB not active but we do block reporting) or they make no sense or were inactive originally (eg personal 3000 settings etc) - might want to review those choices as well. Also, a few numbers etc changed to match current numbers (eg replaced by items etc, new sections)
See comment https://github.com/ghacksuserjs/ghacks-user.js/issues/103#issuecomment-300911966 - `*safebrowsing.provider.mozilla.*` is for Flash & TP ONLY (original article by francois had a *slight!!* error since fixed)
This means that 0410d was not shared by TP and SB and to clear it all up .. 0410d is moved to 0420's. 0420's also gets the flash pref 0440 moved into the 0420's.
Now it's all tidy: 0410's = google and SB, 0420's = mozilla & TP+Flash
Exception: I am enforcing TP in ALL windows (default is PB Mode only). I have also added the info for which block list to use in TP. Also clarified that 0440 (flash blocklist) uses prefs in 0410d. Also made flash tracking blocklist pref (0440) inactive. Now all TP and SB is allowed, only real time google binary checks and reporting is disabled.
Instead of `geo.wifi.uri` using 127.0.0.1, for those who do use geo (`geo.enabled` is the master switch), enforce Mozilla's service over Google's.
- Default in stable, beta: https://www.googleapis.com/geolocation/v1/geolocate?key=%GOOGLE_API_KEY%
- Nightly defaults to mozilla (not usre of the exact string)
- I do not know if this is a telemetry thing for mozilla for non-stable or if this will roll down from nightly
default is false anyway. We can readdress this if it ever gets turned on, or used for purposes other than ad networks - I suspect there's nothing really out there using it right now, and the fact 53 is false, I bet there's no big hurry to turn it on due to stability and real world usage.
its added as default false, but looks like we'll need to check out what options the two prefs (dom from 51 and browser from 53) when true show in the options UI
The blog entry [2] and subsequent ticket [3] are new.
Francois mentioned the older ticket [4].
FYI: `device.sensors.enabled` was introduced in FF15 (don't think I need to add that in)
Because PB mode still allows the key-commands/menus/context menus/buttons to do both "new window" and "new private window", and because in this mode the PB mode purple mask icon is never shown, this is not clear. See issue #73
We value feedback in general, but we value feedback from informed users more. There is no need for you to be an expert to participate (most of us aren't), but we hope that you at least understand our decisions before questioning them. We discuss all changes openly, and we do not make changes lightly. So, if you don't understand why we decided to add/remove/change a certain pref, search the repo. The answer is most certainly here.
If some change we made took you by surprise (in the wrong way), remember that keeping track of changes is your responsibility. Watch the repo, read the changelogs, compare revisions as you update your copy of user.js, or use any other method you prefer.
A `user.js` is a configuration file that can control hundreds of Firefox settings. For a more technical breakdown and explanation, you can read more on the [overview](https://github.com/ghacksuserjs/ghacks-user.js/wiki/1.1-Overview) wiki page.
- This is a rough draft, please read the old intro currently at the start of the user.js in the meantime.
### ![][b] ghacks user.js
- Paragraph here about not jumping in without reading first, and backing up, and understanding the changes
The `ghacks user.js` is a **template** which aims to provide as much privacy and enhanced security as possible, and to reduce tracking and fingerprinting as much as possible - while minimizing any loss of functionality and breakage (but it will happen).
### Origins
Everyone, experts included, should at least read the [implementation](https://github.com/ghacksuserjs/ghacks-user.js/wiki/1.3-Implementation) wiki page, as it contains important information regarding a few `ghacks user.js` settings.
- yada yada
### Purpose
Note that we do *not* recommend connecting over Tor on Firefox. Use the [Tor Browser](https://www.torproject.org/projects/torbrowser.html.en) if your [threat model](https://www.torproject.org/about/torusers.html.en) calls for it, or for accessing hidden services.
- discuss why use a js (enforcement on startup, migration)
- outline trade-offs between security vs privacy etc
- explain expectations and site breakage
- explain this version is a "compromise" or balance that aims (with addons eg you WILL need uBlock Origin or turn safe browsing and tracking protection back on) to provide as much privacy and enhanced security as possible, and to reduce the fingerpritning attack surface as much as possible - while putting up with some incoveniences and as little site breakage as possible (but it will happen). It's only a starting point.
- provide troubleshooting: site breakage will happen. 90=% of the preferences cause no issues. It is only a small core of settings that people may or may not need to look at, depending on their objective.
- no one size fits all, this is a template, fork it! Customize it! (see goals, we won't set you wrong)
Also be aware that this `user.js` is made specifically for Firefox. Using it as-is in other Gecko-based browsers can be counterproductive, especially in the Tor Browser.
To be **THE** template and resource all other user.js' come to for news, links, information and more, which means it needs to be:
- comprehensive (eg some prefs are included at default for completeness/enforcement, a lot are included and changed for future-proofing, etc)
### ![][b] acknowledgments
- current and available and change-trackable (hey, we're on github now)
Literally thousands of sources, references and suggestions. That said...
- easy to understand (good, simple, less-technincal descriptions)
- accountable and a resource (lots of links to authorative authors and tech papers, also repo wiki)
- correct and to dispell myths and bad advise (see accountable)
- eassy to follow and report and discuss (logical and numbered structure)
- give good advise (see trade-offs)
- expanded on with more information, such as FF version numbering for introduction and deprecation of preferences, hidden pref tags etc
- archived for each stable release (starting with 51)
- to provide illustrated wiki topics to help (help wanted please!)
- to make it as easy as possible for anyone to use a user.js and get it right for them
- to provide two or three future forks with differnent settings from "painless no-breakage no-addons" thru to a "super-hardened" version: for use with multiple profiles
### Implementation
* Martin Brinkmann at [ghacks](https://www.ghacks.net/) <sup>1</sup>
- expectations of the user
* The ghacks community and commentators
-link to wiki on testing and tweaking in a portable FF first
- backup first: link to wiki article on backup & restore methods
* The 12bytes article now uses this user.js and supplements it with an additional JS hosted at [GitLab](https://gitlab.com/labwrat/Firefox-user.js/tree/master)
- changing, resetting preferences: user.js and about:config
### Troubleshooting
<sup>1</sup> The ghacks user.js was an independent project by [Thorin-Oakenpants](https://github.com/Thorin-Oakenpants) started in early 2015 and was [first published](https://www.ghacks.net/2015/08/18/a-comprehensive-list-of-firefox-privacy-and-security-settings/) at ghacks in August 2015. With Martin Brinkmann's blessing, it will keep the ghacks name.
mv prefs.js "${bakfile}"|| fQuit 1"Operation aborted.\nReason: Could not create backup file $bakfile"
echo -e "\nprefs.js backed up: $bakfile"
echo"Cleaning prefs.js..."
fClean "$bakfile"
fQuit 0"All done!"
;;
Help)
echo -e "\nThis script creates a backup of your prefs.js file before doing anything."
echo -e "It should be safe, but you can follow these steps if something goes wrong:\n"
echo"1. Make sure Firefox is closed."
echo"2. Delete prefs.js in your profile folder."
echo"3. Delete Invalidprefs.js if you have one in the same folder."
echo"4. Rename or copy your latest backup to prefs.js."
echo"5. Run Firefox and see if you notice anything wrong with it."
echo"6. If you do notice something wrong, especially with your extensions, and/or with the UI, go to about:support, and restart Firefox with add-ons disabled. Then, restart it again normally, and see if the problems were solved."
echo -e "If you are able to identify the cause of your issues, please bring it up on ghacks-user.js GitHub repository.\n"
// reset prefs that set the same value as FFs default value
letaTEMP=getMyList(ops);
myreset(aTEMP);
reapply(aTEMP);
constaBACKUP=getMyList(ops);
//console.log(aBACKUP.length, "user-set prefs from our list detected and their values stored.");
letmyArr=aBACKUP;
letfound=false;
letaDbg=[];
focus();
myreset(aBACKUP);// reset all detected prefs
if(confirm("all detected prefs reset.\n\n!! KEEP THIS PROMPT OPEN AND TEST THE SITE IN ANOTHER TAB !!\n\nIF the problem still exists, this script can't help you - click cancel to re-apply your values and exit.\n\nClick OK if your problem is fixed.")){
aDbg=myArr;
reapply(aBACKUP);
myreset(myArr.slice(0,parseInt(myArr.length/2)));
while(myArr.length>=2){
alert("NOW TEST AGAIN !");
if(confirm("if the problem still exists click OK, otherwise click cancel.")){
myArr=myArr.slice(parseInt(myArr.length/2));
if(myArr.length==1){
alert("The problem is caused by more than 1 pref !\n\nNarrowed it down to "+aDbg.length.toString()+" prefs, check the console ...");
break;
}
}else{
myArr=myArr.slice(0,parseInt(myArr.length/2));
aDbg=myArr;
if(myArr.length==1){found=true;break;}
}
reapply(aBACKUP);
myreset(myArr.slice(0,parseInt(myArr.length/2)));// reset half of the remaining prefs
}
reapply(aBACKUP);
}
else{
reapply(aBACKUP);
return;
}
if(found){
alert("narrowed it down to:\n\n"+myArr[0].name+"\n");
myreset(myArr);// reset the culprit
}
else{
console.log("the problem is caused by a combination of the following prefs:");
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.