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