- 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
- the service implies a check is done first, I'm more concerned with the actual updating: not that updates are bad, it's about controlling when (if ever e.g. my test suite)
- since 0301 has to be done manually in Windows, 0302 is a good fallback **IF** the background service is applicable (read the link)
- clean up the numbering
- "enforce" is for when we set the default value
- use [WARNING] for inactive (they're inactive for a reason and people really do not need to turn them on) but less scary [NOTE] for active (tweak away at your own risk)
- seems neater, easier and less scary for users setting up the first time: i.e they only need to initially look at active items
- FYI: I was going to add something to LSNG (2760) that it is required for Fission, but will wait, and it struck me that 2680 was the only active item with a warning: seems inconsistent
- 2684: security delay .. make enforce mean enforce (default) ... not worth occasionally saving .3 seconds
- for now it's one less item in differences/flips
- might make this inactive in 91+, and add a warning
- it has been a very long time since we added this due to bad advise/references on the internet on how to speed up Firefox
- they all have on/off switches
- dxr no longer exists: update URL
- don't recommend users delete files
- saves two lines
- they poses zero threat (they have prefs)
- deleting them can causes unwanted console errors/noise
It literally cannot hurt [1], and makes it easier for users to use custom mode with TCP/dFPI. Turning on socialtracking helps gain parity with strict mode
[1] gorhill: https://old.reddit.com/r/firefox/comments/l7xetb/network_priority_for_firefoxs_enhanced_tracking/gl9rn9n/
> All extensions and ETP work in parallel, they all inspect network requests and all make the decision to block or not, hence if they all decide to block, they will all report that they block something. ETP is a bit different than normal extension in that it will give precedence to an extension trying to redirect to a local resource, this ensures ETP works harmoniously with normal extensions.
>
> Once something is not blocked, it then goes through a DNS query, and the browser waits for the response.
>
> I will add examples of how ETP + multiple blocker extensions work together when dealing with a network request; let's say "A" and "B" are two different blockers:
>
> - ETP=block, A=allow, B=allow: result=block
> - ETP=allow, A=block, B=allow: result=block
> - ETP=allow, A=allow, B=redirect: result=redirect
> - ETP=allow, A=block, B=redirect: result=block
> - ETP=block, A=allow, B=redirect: result=redirect
>
> So as you can see, ETP is a bit different than a normal extension in that it won't prevent redirection from happening if ever a network request is redirected by one of the normal extension.
