- in v94 we switched to cookies lifetime as session, so users could use site exceptions to retain selected cookies (to stay logged in one assumes)
- that mean not deleting all cookies on shutdown
- but some login methods/types require more than cookies and also need the "site data" part of "cookies + site data" - that's the offlineApps part
- note: all site data (and cookies) is still cleared on close except site exceptions
FYI: https://bugzilla.mozilla.org/1738372
There is a small privacy issue with shoulder surfers, but in reality, this just needs to happen IMO
- we already prompt where to save, but even if we didn't, we also know we clicked or initiated a download
- unless it's a drive by or user-gesture trickery - which is why we prompt
- the download icon is shown (if hidden) and the throbber/accent color go to work
- users can always click the icon to show entries (and open folder etc)
- this maintains the current behavior in FF94
anti-fingerprinting doesn't fit here: it's not a major component or priority of this user.js, and only a few prefs outside RFP (as a robust built-in browser solution that defeats naive scripts) have anything to do with it
move all sanitizing on exit prefs into 2800
switch to cookie lifetime as session
- now users can utilize exceptions (as allow)
- session cookies still block service workers (which we disable anyway)
- we still block 3rd party cookies (until we move to dFPI)
- we still have defense in depth for 3rd party cookies with 2803
- we still bulk sanitize offlineApps on exit: localStorage, service worker cache, QuotaManager (IndexedDB, asm-cache)
- i.e you get to keep the cookies only IF you add an exception
add `privacy.clearsitedata.cache.enabled`
The point was that google have said (stated in policy, but fuck knows where that is located these days) that it is anonymized and not used for tracking. It's an API used by **_4 billion devices_** - the API has privacy policies for use. If a whistleblower or someone else found out that google was using this to enhance their user profiling, then all hell would break loose. And they don't even need this to fuel their ad revenue. It is provided, gratis, to the web to help ensure security - they wouldn't dare taint it and get it caught up in a privacy scandal involving **+4 billion devices_**. And in all this time (since 2007), there has been no such whistleblower or proof it is used to track or announcements by google of changes to the contrary.
Anyway, a quick search brings up
- Here is their policy - https://www.google.com/intl/en_us/privacy/browsing.html - it's empty and points to
- https://www.google.com/intl/en/chrome/privacy/
- and if you scroll down to "Safe Browsing practices" it doesn't say anything about privacy policies for the API itself (or the owner of the API) - it just spells out what happens in chrome
- I'm not going to bother to look any further and find a history of policy changes
Anyway, this is Firefox and hashes are part hashes bundled with other real hashes - and we turned off real time binary checks. So this line can fuck the fuck off. It was meant to reassure those who want the security of real-time binary checks, that privacy "shouldn't" be an issue, but I'm not going to expand on it
- and remove obsolete ESR78 notations
- note: we leave the deprecated ESR78.x section and item 6050 until v95 so users upgrading to ESR91 can easily reset those prefs with prefsCleaner
- this helps mitigate the need for scratchpad for those who use prefsCleaner
- in future, if anything was active during the ESR cycle, then it goes in here when removed
- similar to deprecated items: clean out after ESR EOL
- I am no longer short one parrot
- move inactive screenshots to personal
- move FORM autofill to `0800... FORMS` - can't find it now, but this is slated to cease being a system addon and instead be "built-in"
- the rest will get swallowed into a revamped, split QUIETER FOX
- there was only one perf left
- warning is down to 5: two in section headers, 3 on inactive prefs: no need to mention it, people will see them if they read each item/section
More minor tweaks to come. This isn't final
- 0102: ambiguous that the clearing was related to PB mode
- 0900s:
- get rid of 0901, it has no pref, stick link in header
- 0905: values on multi-lines use spaces = more readable
- 1000s:
- rename as disk avoidance and remove sub-section headers
- remove the outdated section header
- 4001: it will never be perfected, it's doing it's job
- 5500s: optional hardening
- legit security measures, but commonality in caveats, so I made them a separate section
- this flips graphite, asm.js and wasm from active to inactive: these are overkill: exhibit A: hundreds of millions of Firefox users
- e.g. graphite and wasm are enabled on Tor Browser
- new CVE keyword links
- 7000s: don't bother - two more items added
- 5000s: optional opsec and cleanout 0800s header
- re-number
- 0900s, 1000s, 1400s, 2400s
PS: I need a new parrot: "9000 syntax error: I ran out of parrots"
Yes it's pretty much useless. Yes it's fingerprintable, and what that entropy is, who knows. Since it's sent regardless with ETP, which we enable in all windows, then who cares. And if you don't use ETP in all windows, then I don't care either - just saying
probably more professional to keep it at the end since it isn't strictly project related. It also opens up space for `DON'T TOUCH` and `OPTIONAL OPSEC`
- merged 3DES cipher to bottom: it is still the same order of [1]
- 3DES pref will be deprecated: pref name changes, and the cipher slated to be unavailable unless you downgrade to < TLS1.2 - see https://bugzilla.mozilla.org/show_bug.cgi?id=1724072
- FYI: we reset TLS downgrades to session only by resetting the pref currently in 1203
- "Minimal/non-existent threat of downgrade attacks"
- FYI: these old ciphers are about 1-2% of traffic (from memory) - but that's still significant breakage
- So the only reason to do this would be to harden against downgrade attacks (and inadvertently use weak sites = breakage): but that doesn't fit most user's threat model: and is probably never going to happen for them. Not sure if I can word that much better and just as succinct
- inactive in user.js since
- v55: gfx.direct2d.disabled
- v67: layers.acceleration.disabled
- the way to counter hardware fingerprinting is within each API that may expose it
- this may have made some sense way back in the day, when there were less options/protections, but not any more
- [are we web render yet](https://arewewebrenderyet.com/) - yes, 100% - there is no need to cripple your browser's perf
- inactive since we added it in v63
- this is not how you defeat fingerprinting (unless done in an enforced set)
- for the record: not even tor browser disable this
- fingerprinting this is not cheap in gecko (for now)
- from [2]
- decoding/encoding capabilities: "it is expected that the entropy ... isn’t going to be significant"
- HDR detection: "... has the potential to add significant entropy .. however .. but ... thus minimizing effective entropy" - it is what it is
- note that RFP has some mitigations in FF82+ 1461454
- just to be clear, this section is not supported: not interested in references or explanations or FF version numbers or default info etc
- "do more harm than good" - ambiguous, not interested in explaining why exactly: but FYI
- some leak
- most break shit
- almost all are easily fingerprinted and the combo of them would make you really stand out
- removed the duplicate `ui.prefersReducedMotion` - this should move to personal as well
- moved `ui.systemUsesDarkTheme` to personal
8000s (was 4600s)
- move below personal, so user-relevant part is shorter
- swap out font vis with document fonts + font whitelist
- font vis still has usability/visual purposes: it just won't really help much with fingerprinting
- ESR78 users (who can't use font vis), sorry, but we made doc fonts inactive for a while now, and now recommend you don't use it anyway
- dead weight since 2017-06-13 when ESR45 reached EOL .. good riddance
- if someone does use it, it's not going to do any harm, so no need to carry it for prefsCleaner
- geo -> warning
- merge container prefs
- remove redundant "see"s
- remove corresponding 4600's item number in RFP mitigations
- it's pretty clear by the preference names in 4600
- could be misconstrued that the 4600 pref is the same result
- RFP's language prompt only checks for en*, not en-US (so en-GB, en-CA etc do not get prompted)
- https://searchfox.org/mozilla-central/source/toolkit/components/resistfingerprinting/RFPHelper.jsm#196
- 0105*: merge into a single block
- 1220: make values more readable with spaces, like 2701 (no need for value 2), add default, update advise (get a new AV, SHA1 is dead baby)
- 2619: remove fluff
- we already disable webgl, that's enough
- the other two prefs are not going to provide much protection if a user decides they want webgl
- "disable-fail-if-major-performance-caveat" only applies to ESR78 and will removed in the future
- one (or two) less pref(2) for users to troubleshoot/flip
- remove 2720
- this is a very old pref, been inactive since at least our first github release: v51
- disabling the API is not how you control client side state: you do that by blocking cookies which also controls other state such as IDB etc
- 2700 section header
- history/downloads is redundant
- Offline Website Data info -> relevant item number with Active Logins info
- ^ technically it still includes appCache for ESR78 users, but that will be moot in less than three months
- tidy RFP
- update to FF91 userAgent spoofing: there is no Android ESR so we don't need to mention "Android 9"
- we don't need to say if the API is enabled for mediaDevices
- the service implies a check is done first, I'm more concerned with the actual updating: not that updates are bad, it's about controlling when (if ever e.g. my test suite)
- since 0301 has to be done manually in Windows, 0302 is a good fallback **IF** the background service is applicable (read the link)
- clean up the numbering
- "enforce" is for when we set the default value
- use [WARNING] for inactive (they're inactive for a reason and people really do not need to turn them on) but less scary [NOTE] for active (tweak away at your own risk)
- seems neater, easier and less scary for users setting up the first time: i.e they only need to initially look at active items
- FYI: I was going to add something to LSNG (2760) that it is required for Fission, but will wait, and it struck me that 2680 was the only active item with a warning: seems inconsistent
- 2684: security delay .. make enforce mean enforce (default) ... not worth occasionally saving .3 seconds
- for now it's one less item in differences/flips
- might make this inactive in 91+, and add a warning
- it has been a very long time since we added this due to bad advise/references on the internet on how to speed up Firefox
- add -s parameter to start immediately / skip prompt / run non-interactive
This is useful if the user wants to automate the process of updating the user.js and cleaning prefs.
- fQuit: error messages to stderr
- fFF_check: info msg to stderr
Better support for suppressing/redirecting stdout while still showing any error messages in the console, useful for example with `prefsCleaner.sh -s >/dev/null`
- re-arrange the match patterns to fix the remaining issue of dropping lines after the 9999 block
- make it work on Mac too
- use `|` where possible so we don't need to escape the forward-slashes. That saves a few bytes and makes the pattern easier to read
see #1188
this should fix the issue that "All prefs after a multi-line comment declaration, on a single line, are deleted with the remove_comments function from the updater."
- they all have on/off switches
- dxr no longer exists: update URL
- don't recommend users delete files
- saves two lines
- they poses zero threat (they have prefs)
- deleting them can causes unwanted console errors/noise
It literally cannot hurt [1], and makes it easier for users to use custom mode with TCP/dFPI. Turning on socialtracking helps gain parity with strict mode
[1] gorhill: https://old.reddit.com/r/firefox/comments/l7xetb/network_priority_for_firefoxs_enhanced_tracking/gl9rn9n/
> All extensions and ETP work in parallel, they all inspect network requests and all make the decision to block or not, hence if they all decide to block, they will all report that they block something. ETP is a bit different than normal extension in that it will give precedence to an extension trying to redirect to a local resource, this ensures ETP works harmoniously with normal extensions.
>
> Once something is not blocked, it then goes through a DNS query, and the browser waits for the response.
>
> I will add examples of how ETP + multiple blocker extensions work together when dealing with a network request; let's say "A" and "B" are two different blockers:
>
> - ETP=block, A=allow, B=allow: result=block
> - ETP=allow, A=block, B=allow: result=block
> - ETP=allow, A=allow, B=redirect: result=redirect
> - ETP=allow, A=block, B=redirect: result=block
> - ETP=block, A=allow, B=redirect: result=redirect
>
> So as you can see, ETP is a bit different than a normal extension in that it won't prevent redirection from happening if ever a network request is redirected by one of the normal extension.
It is simpler to leave the PointerEvent pref where it is, until ESR78 is EOL
- FF87+ users who use RFP Alts simply add a dead pref, no harm
- This way ESR78 users don't have to worry about extra char flipping: it's the same as before: 1 flip for ESR, 1 flip for RFP Alts
only stable is false, at the time of writing. but enforcing this for all channels is good, so no-one ends up wasting mozilla resources reporting a compat problem when they've got 200 odd prefs flipped
- don't differentiate between channels
- both can be made inactive
- webcompat requires user action: and I don't see this as a bad thing to have in non-stable
- unsubmitted crashReports on Nightly is probably already covered by killing the URL, so no big deal
- 0000: remove old XUL info, dropped in FF73+
- 0201: save 3 chars
- 0350: add default status for unsubmittedCheck
- 0351: change to enforce: has been default false going back to at least FF60, including current Beta/Dev/Nightly
- along with 0602 `network.dns.disablePrefetchFromHTTPS` and 0603 `network.predictor.enable-prefetch`, I considered making them inactive, but decided it was good to leave them active for non-stable users just in case they get flipped
- 0515: add default status
- 0850c: remove info: out of date: doesn't work lilke that anymore and can't be assed figuring it out what with megabar and urlbar2 changes
- 0871: make inactive: default false since at least FF60
- no need to enforce for non-stable in case it is flipped. It's a pretty minor shoulder-surfer privacy issue and the previews are small. If you're not sure what this pref does. On false you get one tab shown, on true you get as many as can fit across your screen. I squeezed in 15, and after that it became a list
- fixup `***/`
- shave off six lines and almost 400 bytes for you bastards
- This is too minimal to be of any use, breaks too much (e.g. zoom video)
- Tor browser stopped flipping this (I *think*) about 5 years ago: it certainly hasn't been used in ESR60+ based TB builds, I checked
- we already disable webgl, so making this inactive removes yet another pref users need to flip/troubleshoot
- I will leave it in the user js for a few releases so prefsCleaner will pick it up
- It is controlled in both runtime and via user.js by the state of `media.eme.enabled`. Also, who cares about the vis of a ui option
- note, there is no need to add this to the removed scratchpad list
cmd.exe has a command line length limit of 8192 characters. Abort if prefs.js contains strings that would get dropped while recreating the new prefs.js.
`browser.newtabpage.activity-stream.asrouter.providers.snippets`
These (which landed in FF64 with snippets above) are not in the user.js, so why bother with the snippet one
- `browser.newtabpage.activity-stream.asrouter.providers.cfr`
- `browser.newtabpage.activity-stream.asrouter.providers.onboarding`
also these aren't in the user.js
- `browser.newtabpage.activity-stream.asrouter.providers.cfr-fxa`
- `browser.newtabpage.activity-stream.asrouter.providers.message-groups`
- `browser.newtabpage.activity-stream.asrouter.providers.messaging-experiments`
- `browser.newtabpage.activity-stream.asrouter.providers.whats-new-panel`
There are no privacy concerns here. At the end of the day, what Firefox connects to and sends is E2EE and only used locally in non-web content: and you have other prefs and a UI to disable them from being displayed
- remove useless `see` word for reference links
- fixup 0701
- "do not play nice" is not measurable
- don't reference to self as a source: people can just search "VPN leak Ipv6" or something
- shrink and remove outdated info from section 0300 header
- combine some bugzillas
- drop some references
- 1647829 for HTTPS-Only mode
- hardware metrics: not going to implicitly encourage users to use this pref or tell them what sizes to use
- update [STATS]
- also remove TLS [STATS].. stats on TLS 1.0 and 1.1 are irrelevant: the default is now TLS 1.2+
- single CRLite reference for all blog articles
- save 588 bytes so all you bastards can theoretically load Firefox just that tiny bit faster
Note
- this is not the same as 2517 which disables the API
- RFP does not determine what is supported or not supported: so that entropy remains
- with or without RFP, if the media config is not supported it returns false,false (so there is nothing to spoof here)
* misc
- cleanup of old release notation in comments: e.g. if it's not applicable to ESR78+
- same with default version info
- simplify and save bytes on section 4700
- update 4500 header
- and unify the message about using extensions as counterproductive
- letterboxing
- provide info on stepped ranged (and drop crap about FF67)
- don't judge users who dislike seeing margins (I don't like them either, but I force my window to exact dimensions and stay there)
- screenshots uploading was disabled in FF67+ : [67 release notes](https://www.mozilla.org/en-US/firefox/67.0/releasenotes/)
- the pref is still there (default false) but so far I'm 99% sure this pref now does anything
- I will add it to the scatchpad script if this change sticks
* simplify 4500 RFP, see #1041
* update removed script
* tidy readme, see #1045
- also put readme before releases
* RIP FX Site Compat
* clean out RFP Alts info: the information is redundant: it's already in the readme
- make 1401 inactive: it affects RFP's FPing
- remove old warning/setup-web: we do not care about documenting breakage or FPing risks when we have a warning and they are inactive. If someone uses them, that's on them
- new warnings
- this was made inactive in v68
- since at least FF79, when active as false, it breaks the web and browser consoles
- it breaks websites
- it breaks extensions: e.g. uBO panel functionality
- it does nothing to mitigate possible fingerprinting (which was why it was initially added as a concern) - i.e the API only provided a standardized method, it does not stop previous/earlier workarounds
* 0 : successful termination
* 2 : command line syntax error
* 1 : catchall for general errors
Plus a few text improvements based on unmerged PR 4fbb2be98d
- less active prefs
- now that ESR68 is EOL, at least a whopping two (0602, 1273)
- also I don't know when the default changed - another whopping whole one (1240)
- and where we do enforce/reset a pref to default, lets say that
- this is not a definitive list, sing out if there is anything else
- IPv6 info
- especially for Iron Heart who likes to claim that this pref breaks 5% of sites
- cleanup of settings tags now we only care abut ESR78+
* rework DOWNLOAD_METHOD, download_file, open_file
* remove legacy command leftover line
* return empty string if download fails and return/exit if this happens and show error message
* fix IFS var typo
* bump version
* add quotes
Co-authored-by: TotallyLeGIT <bbkqx24kxlgvgbss@mailban.de>
- Go to https://telemetry.mozilla.org/
- click `measurement dashboard`
- select `SSL_HANDSHAKE_VERSION`
I looked at Nightly 75 (0.26 and 0.01) and Nightly 76 (0.2 and 0)
* simplify ciphers
- let's not encourage (remove options 1, 2) changing your cipher suite FP
- remove "it's quite technical ..." (everything is technical to someone), trim to one line
- add test link so users can just see that it's FP'able
- reinforce not to fuck with the cipher suite in the cipher's sub-section
https://wiki.mozilla.org/Security:Renegotiation describes
> **the new default behaviour** that was introduced in experimental mozilla-central nightly versions on 2010-02-08
where the last step is
> - should the server (or a MITM) request **renegotiation**, Mozilla will terminate the connection with an error message
and then after talking about breakage ...
> The above defaults may break some client/server environments where a Server is still using old software and requires renegotiation.
mentions workarounds to reduce said breakage:
> In order to give such environments a way to keep using Firefox (et.al.) to connect to their vulnerable server infrastructure, the following preferences are available:
specifically talking about the first 2 prefs listed there, one allowing to specify a list of hosts "where renegotiation may be performed" and the 2nd one "completely disables the new protection mechanisms".
But both those prefs were removed in FF38, meaning that since then it's no longer possible to disable the default behaviour that is "should the server (or a MITM) request **renegotiation**, Mozilla will terminate the connection with an error message".
But all of this is about the **re**-negotiation part and not negotiation. And nowhere does it say "insecure" renegotiation, which, as I read it, means that FF will terminate the connection for any kind of **renegotiation**, safe or unsafe.
1201 controls the negotiation part:
> This pref controls the behaviour during the initial negotiation between client and server.
> If set to true, a Mozilla client will reject all connection attempts to servers that are still using the old SSL/TLS protocol and which might be vulnerable to the attack.
> Setting this preference to “true” is the only way to guarantee full protection against the attack.
I think "servers that are still using the old SSL/TLS protocol" actually means servers that **only** support the old protocols.
Servers still supporting those old protocols in addition to some new protocol versions should not be affected by this pref because FF will be able to negotiate to use one of the newer protocol versions.
Ergo lets fix the title and remove the line about renegotiation support because I think that's irrelevant.
ps. the sslpulse link is nice and I'd like to keep it somewhere but it doesn't really fit in 1201 IMO so I moved it to 1202.
see `1273`
- we already make **all** windows do this (which overrides the pb mode setting), and these were inactive
- in FF70+ the icon pref (for PB mode and all windows) is now default true
- split geo related vs language/locale related
- rip out intl.locale.requested
- rip out intl.regional_prefs.use_os_locales
- add intl.charset.fallback.override
it rode the train in 69... after a bumpy ride in 68 where it was backed out. Note: it still has some issues. Suggest users wipe the site permissions once upgraded to 69
with `plugins.click_to_play` deprecated in FF69, no-one here is sure if `intervalInMinutes` still applies to Flash or even works, and no-one here cares about Flash. Happy to let Mozilla just keep restricting it more and more until it's deprecated in early 2020. Note: we already disable flash anyway in pref 1803.
- EFF has pretty pictures and stuff and explains the issues (replaces wikipedia which people can still search for)
- tor issue doesn't hold anything important (out it goes)
- moz wiki page I'll leave in for the bugzilla links if someone wants to research how it's all meant to work
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!!***
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](https://github.com/arkenfox/user.js/issues?utf8=✓&q=is%3Aissue+label%3Achangelog), compare [releases](https://github.com/arkenfox/user.js/releases) 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.
### 🟪 user.js
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/arkenfox/user.js/wiki/1.1-Overview) wiki page.
The `ghacks user.js` is a **template**, which, as provided, 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).
### 🟩 the arkenfox user.js
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.
The `arkenfox 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).
Literally thousands of sources, references and suggestions. That said...
Everyone, experts included, should at least read the [implementation](https://github.com/arkenfox/user.js/wiki/1.3-Implementation) wiki page, as it contains important information regarding a few `user.js` settings.
* Martin Brinkmann at [ghacks](https://www.ghacks.net/) <sup>1</sup>
* The 12bytes article now uses this user.js and supplements it with an additonal JS hosted right [here](https://github.com/atomGit/Firefox-user.js) at github
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.
<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.
Also be aware that the `arkenfox user.js` is made specifically for desktop Firefox. Using it as-is in other Gecko-based browsers can be counterproductive, especially in the Tor Browser.
echo -e "\nThis script should be run from your Firefox profile directory.\n"
echo"It will remove any entries from prefs.js that also exist in user.js."
echo"This will allow inactive preferences to be reset to their default values."
echo -e "\nThis Firefox profile shouldn't be in use during the process.\n"
select option in Start Help Exit;do
case$option in
Start)
fStart(){
if[ ! -e user.js ];then
fQuit 1"user.js not found in the current directory."
elif[ ! -e prefs.js ];then
@ -80,8 +75,28 @@ select option in Start Help Exit; do
echo"Cleaning prefs.js..."
fClean "$bakfile"
fQuit 0"All done!"
}
echo -e "\n\n"
echo" ╔══════════════════════════╗"
echo" ║ prefs.js cleaner ║"
echo" ║ by claustromaniac ║"
echo" ║ v1.4 ║"
echo" ╚══════════════════════════╝"
echo -e "\nThis script should be run from your Firefox profile directory.\n"
echo"It will remove any entries from prefs.js that also exist in user.js."
echo"This will allow inactive preferences to be reset to their default values."
echo -e "\nThis Firefox profile shouldn't be in use during the process.\n"
["$1"=='-s']&& fStart
select option in Start Help Exit;do
case$option in
Start)
fStart
;;
Help)
fUsage
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."
@ -90,7 +105,7 @@ select option in Start Help Exit; do
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"
echo -e "If you are able to identify the cause of your issues, please bring it up on the arkenfox user.js GitHub repository.\n"
// reset prefs that set the same value as FFs default value
let aTEMP=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 ...");
functiongetMyList(arr){
constaRet=[];
for(constsPnameofarr){
if(Services.prefs.prefHasUserValue(sPname)){
constptype=Services.prefs.getPrefType(sPname);
switch(ptype){
case32:// string (see https://dxr.mozilla.org/mozilla-central/source/modules/libpref/nsIPrefBranch.idl#31)
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.