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