work in progress, prototyping
- 4604
- 1357733 is a duplicate of [1359076](https://bugzilla.mozilla.org/show_bug.cgi?id=1359076) which was non-stable -> [1462308](https://bugzilla.mozilla.org/show_bug.cgi?id=1462308) which I listed for now, where certain Sensor APIs were disabled in FF62+ - see [this](https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/62#APIs_2) - so swap 1357733 with 1462308
- remove tor ticket: it adds nothing: it just says, ooh, flip this pref
- 4604: part two: we need to update what the threat is
- added MDN Sensor API status page
- I need to check but AFAIK, only orientation and motion is left: motion has some precision (that's the 1292751 bugzilla)
- left in for now: the PoC - but 99% sure (see above bullet point) it doesn't apply anymore to FF
- 4606: we don't need the tor issue: the FP info is listed in the description (USB device ID enumeration)
- 4607: wicg is all we need
- 4610: bugzilla adds nothing, it's just a reference to the pref being added, tor ticket also adds nothing: FPing issue is in description
anyway, that's four more lines less noise
This is a draft
- merge 4700's into 4600s
- remove old numbers in the square brackets
- remove notation of when RFP kicked in (that info is in 4500s)
- since we now do not recommend this section
- cleanup info on each release in README section
- do away with one char flip
- move 4616 to deprecated where it belongs
- remove "optional if..." lines
- start cleaning up references, descriptions to shorten the section
- will list what I removed: e.g. bugzillas to when the pref was added are a bit useless
todo / consider
- 4600 title
- 4600 section description can be a lot better
- 4600 link to wiki page on RFP ( issue #1218 - that is, if RFP is not for you, then just use Canvas Blocker, which can leak but should fool naive scripts if any get thru etc )
- do we want to add dom.enable_performance_navigation_timing
while these all fit together as "covered by RFP", some of these seem out of place
- maybe we could split this into two
- 4600: "optional without RFP" - these won't hurt RFP but they also won't help your fingerprinting - e.g. font vis, prefers-color, prefers-reduced-motion
- 4700: "do not use EVER especially with RFP" - these will affect RFP, can break shit, etc, and won't help your fingerprinting - e.g. all the timing stuff, disabling APIs, etc
- also. the webgl one seems a bit out of place since we disable webgl
- we could always move some items back to their relevant sections as inactive with some sort of RFP tag/warning
I'm not sure what's the cleanest way to convey this. Anyway, pushing a PR to get some discussion going
- 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
- add -s parameter to start immediately / skip prompt / run non-interactive
This is useful if the user wants to automate the process of updating the user.js and cleaning prefs.
- fQuit: error messages to stderr
- fFF_check: info msg to stderr
Better support for suppressing/redirecting stdout while still showing any error messages in the console, useful for example with `prefsCleaner.sh -s >/dev/null`
- re-arrange the match patterns to fix the remaining issue of dropping lines after the 9999 block
- make it work on Mac too
- use `|` where possible so we don't need to escape the forward-slashes. That saves a few bytes and makes the pattern easier to read
see #1188
this should fix the issue that "All prefs after a multi-line comment declaration, on a single line, are deleted with the remove_comments function from the updater."
- 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
