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
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
