arkenfox / user.js

Firefox privacy, security and anti-tracking: a comprehensive user.js template for configuration and hardening
MIT License
10.04k stars 514 forks source link

review: inactive prefs #138

Closed Thorin-Oakenpants closed 7 years ago

Thorin-Oakenpants commented 7 years ago

There are currently 86 matches for "// user_" (up to 2800 inclusive) - we should check them all for consistency - eg why? are tags applied [warning], [setup] etc? are [notes] included? etc. Are we enforcing defaults consistently?

Consider (39 items in 32 pref numbers)

:small_orange_diamond: pref value differs from the default but we give no warning/note (or even a setup) as to why we left it inactive

:small_blue_diamond: pref value is the same as default, why don't we just enforce it


While we're at it

Would like these changed from default false to inactive true, fix the description (in the last week of bugzilla reading I can confirm without any refs, that openWIndows refers to sessiondata/session restore), and add in that there is a long standing issue unlikely to be resolved re double windows on launch (maybe it's ok on linux or something, I am still amazed why it's enforced in PK's as true - already three issues raised over it, no doubt many more to come. We also have session restore disabled anyway)

Ignore (47 items in 29 pref numbers)

PB start mode, auto-update checks, Kinto+SB+TB etc, e10s, containers, UA spoofing, FPI, and user choice on window res (almost all of these differ from default)

...

earthlng commented 7 years ago
earthlng commented 7 years ago
earthlng commented 7 years ago

Tinkering with it would probably lead to stability/performance issues.

Only if you set it too high. Setting it to 0 as we have in the template should have no such impacts. It doesn't need a warning IMO. Everything is perfectly explained in the description. If someone wants to tweak it they can look at the linked page and decide what they want.

Why keep cookies for 90 days? We could change that that to 10 days

sure, but why keep them for 10 days? Either you want certain cookies, most likely until they expire, or you don't care about cookies and can delete them on shutdown. Both items let the user know what the default values are in FF and that's good enough IMO. No need to change anything

earthlng commented 7 years ago

and I also think we shouldn't add WARNING tags on inactive prefs. We should try to keep those to a minimum IMO

earthlng commented 7 years ago

I don't store cookies across sessions but you do, so you can better decide what you would want those prefs to be should someone choose to activate them (in combination with the other cookie prefs). 2 + 30, 3 + 30, 3 + 10 - do whatever you think is best - IDC :)

earthlng commented 7 years ago

I like that the inactive ones with "set..." default to the same as FFs default. If someone wants to enforce the defaults they can just active those, or tweak them if they prefer that. We can activate 1032. For 1031 the title is pretty self-explanatory. The other orange ones we just discussed and the remaining blue ones we can ignore IMO.