ToDo:
First of all, I know.. I know... you're all excited.... but just relax ... I appreciate feedback etc, but please let "us" analyze it first and trim the list down (there's some junk in there) and actually create an end product. We already have the info, so please no suggestions - that can come later when we refine.
Well, based on what's getting changed in overrides, what we already have tags on (we put em there for a reason), what's already in the troubleshooter (TS for short), and what's important (just because someone changed it doesn't mean its worthy):
Green (relaxed) vs red (hardened) isn't necessarily that but generally fits that pattern (we have active prefs that can actually hardened further). The green is actually active prefs, red, inactive. In general, active prefs should be where almost all our setup tags go (to relax), and warning and harden tags would primarily be on inactive prefs (to harden or warn, doh!). The TS info is a hybrid, as earthlng is trying to cover any end-user's config.
PS: when we create a hardened list you can see immediately that items stand out (from the red lot)
1. disable history
2. disable password saving
3. make permissions memory only
4. make certs memory only
5. disable svg
6. block websites setting a context menu?
7. blank restricted domains
8. disable memory cache (not in the results, but I'd add this)
The same process is just as easy for relaxed/setup items, just more of them which we can breakup into perf, web & chrome - and we've already done most of it.
From #438 I summarized the results manually and have added in tag & troubleshooter info for a more complete picture
I have this all in a spreadsheet, and I'll post an image next comment. Someone tell me the syntax in here for table shit and I'll try and replace it with text (or earthlng or :cat2: can just do one for me). Sorry for the big ass picture
In the results, E=earthlng and K=krathalan, W=always web, not warning, SR=smart referer
PS: it's not all totally scientific, because we flipped and changed things in the last 8 or 9 months since people shared their overrides. My shorthand is totally made up, so e.g 2, and 1xbecause=uMatrix means 2 person relaxed it but 1 didn't really because he's blocking it by default in uM and whitelisting. Hope that all makes sense

I see 4001 breaks CAD=not true line.... that came from me, but its was true back in May, and for sure it is not anymore... which suggests me that you have old overrides (at least from what I have dropped in #438 )
Do you wish get the latest? For sure there was some changes.
Mozilla has done a big evolving with FPI in the last half of the year... back then quite a lot login pages, where you have been redirected to another domain for login, had breakages, which is not the case anymore.
I will do a diffs for my overrides from #438 with latest and will report back... but will not be able to do it tomorrow, since I will be "out of office"... so after tomorrow, if that is OK with you?
Cheers
it's not all totally scientific, because we flipped and changed things in the last 8 or 9 months since people shared their overrides
Thanks, but I don't need anything @crssi , we already have a list. I seriously doubt anything to be considered is missing. We probably have enough data, and certainly knowledge, to do this. Also my notation is not a criticism of the reason why you or someone disabled something in the past, I'm just squeezing info into the tiny cell, so when I see the figures I can easily discount them or work them out, e.g breaksCAD=nottrue = means it's no longer an issue (so I can ignore it), and 1xK = ignore it (because see my explanation about K).
Anyway, FPI (and RFP) will not be made inactive and are already tagged and troubleshooted .. this is what I mean by letting us clean up the list (read the OP). Otherwise we'll end up with comments about each pref and discussions on each one, and the thread will become 300-1000000gazillion comments with everyone's views :)
chill out man and let me work my magic :)
Someone tell me the syntax in here for table shit and I'll try and replace it with text
https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet#tables
Maybe you can try something like this to make your life easier.
I have started to make the list before I noticed your last reply... so I will dump it anyway.
And no, no... i didn't take it as criticism. But there are some to drop out for sure and some to add.
For example:
2701 back then was different than ghacks, but now its the same as yours.
Upper 1240 came from my overrides back then, but now its also the same as yours.... upper count is 1 (so its from me) and you can drop it out from upper list.
2030 now its media.autoplay.enabled has changed, mine value now is 0.
You can change 2403 from count 1 to count 2 (I have added to overrides)
You can change 2682 from count 2 to count 1 (I have removed from overrides)
You can drop 4001, since that count came from me and I do not differ from ghacks anymore.
New to my overrides:
/* 5000 */ user_pref("browser.newtabpage.activity-stream.asrouter.userprefs.cfr", false); // disable CFR
/* 4503 */ user_pref("privacy.resistFingerprinting.block_mozAddonManager", false); // allow addon web site to work as intended, also 2662 must be default
/* 2510 */ user_pref("dom.webaudio.enabled", true); // should be false, except if using WE CanvasBlocker
Now I will shut up until I won't. :heart:
dude, I'm onto it :) Relax.. i know we flipped cookies and clearing cookies - its not important, any setup* is always going to look at cookie prefs. I know media.autoplay.enabled changed, I combined them under the new pref. etc. I got this bro .... trust me
@Thorin-Oakenpants If you are looking for more overrides here are mine: https://github.com/publicarray/dotfiles/blob/master/apps/firefox/myuser.js
They are a bit messy due to copy and paste from various places. Some prefs might be completely out of date and don't do anything in FF anymore
in upper table under webgl you have 2010,1012 (row 42), but it should be 2010,2012
cheers
@crssi Can you give me an example of WOFF2 (1405) which is on the list. If all it does is break readability, then I might make it inactive with a harden tag. I never see breakage though - this is just local fonts right?
WOFF2 is used quite a lot for Icons, for example a "magnify glass" for search buttons, etc.
Will disable it here and when I stumble on a page, I will post URL here. Expect it soon.
Cheers
when I stumble on a page, I will post URL here
Cool. a test page would be awesome. I need to work out if these can be/are affected by other prefs: e.g downloadable fonts, 3rd party, etc. I mean, does Windows come with WOFFs? I'm not a font expert. 3rd party can be controlled by uBO, uM.
I'm just not sure what the privacy risk is here. Pretty sure there is no security risk.
I did some quick digging. WOFF / WOFF2 is a downloadable font. It's right there in the pref name. The default is true in TB. And likewise, we also do NOT have 1403 as active (that's disabling icon fonts). This is a readability / usability issue
I probably do see breakage, but don't attribute it to anything in particular: I block all 3rd party calls by default, I block fonts in other ways (request control). CSS allows for fallback to ttf - assuming the web dev codes it like that, but breakage is bound to happen. WOFF1 was introduced back in FF3.6, WOFF2 in FF35. It would also be a FP metric that would be detectable via JS or CSS (by watching server calls for the fallback font).
I will make this inactive and add a harden tag - but at the end of the day I think the "risk" from this is minimal, if at all - I do not think there are any problems with security/exploits, and plugging a font third party call is misleading, when the real solution is to control ALL 3rd party (a la uMatrix)
Tank you for 1403. I stumbled around and not yet found glyph breakages, since all the sample pages I had reverted to PNGs in the meantime. But I have found some, where fonts are not the same as with woff/woff2 and the page is uglifyed. But it doesn't matter anymore due to your change today it is OK now. :smile_cat:
I would vote for 1241 to be inactive. Its passive content, leads to breakages like missing images. Is it really security/privacy problem?
Never had a problem with 1406 as it is now, at least I haven't been aware of.
I would vote for 2001 to stay as it is now. Otherwise it is a privacy/information leak problem. Or it must be covered by uBO.
Same goes for 2510 due to fingerprinting, if inactive it must be covered by CB.
Voting for 2203 to be inactive. Is there really security/privacy issue?
I am not smart enough for 2403. Smells a bit, but I have this in overrides as true, the same with 2402.
I guess for 0207 we are covered by RFP (4500) if active and true
If there is an statement in implementation that default search engine must be set to one that is privacy oriented (like DDG or other similar) then 0801, 0807 and 0808 could go inactive. If not, those should stay active, IMHO.
1241 (passive insecure content) would be off the cards: the breakage lessens everyday with uptake of HTTPS, and yes, there are privacy concerns: sending requests in the clear is enough to disable it. It just needs a setup tag and maybe a warning
OK. I think I'm almost done here. Here is the summary

=====
excluding personal and deprecated, and parrots
249 active
113 inactive (10 are active in RFP ALTs which is an inactive section)
===
362 total
249 active
15 active enforced at default
===
234 pref changes (at most)
^^ covered by 42 [SETUP* tags
1 [SETUP-SECURITY]: SB binary checks
5 [SETUP-PERF]: AltSvc, cache, SSL Session IDs, asm.js, wasm
14 [SETUP-CHROME]
18 [SETUP-WEB]
3 [SETUP-HARDEN] HWA, MathML, "open with"
1 [SETUP-non-RFP]
Overall, this should provide a more balanced user.js, but one which is still pretty heavily geared towards hard rather than relaxed, but one which allows very easy troubleshooting: e.g. 18 set-up web tags should cover 95% of breakage
I can't say it's been fun. I shall close this and open a new issue on whether we even need to provide a relaxed version. AFAIC.. the information is all in the user.js
Most helpful comment
I did some quick digging. WOFF / WOFF2 is a downloadable font. It's right there in the pref name. The default is true in TB. And likewise, we also do NOT have
1403as active (that's disabling icon fonts). This is a readability / usability issueI probably do see breakage, but don't attribute it to anything in particular: I block all 3rd party calls by default, I block fonts in other ways (request control). CSS allows for fallback to ttf - assuming the web dev codes it like that, but breakage is bound to happen. WOFF1 was introduced back in FF3.6, WOFF2 in FF35. It would also be a FP metric that would be detectable via JS or CSS (by watching server calls for the fallback font).
I will make this inactive and add a harden tag - but at the end of the day I think the "risk" from this is minimal, if at all - I do not think there are any problems with security/exploits, and plugging a font third party call is misleading, when the real solution is to control ALL 3rd party (a la uMatrix)