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.
It is simpler to leave the PointerEvent pref where it is, until ESR78 is EOL
- FF87+ users who use RFP Alts simply add a dead pref, no harm
- This way ESR78 users don't have to worry about extra char flipping: it's the same as before: 1 flip for ESR, 1 flip for RFP Alts
only stable is false, at the time of writing. but enforcing this for all channels is good, so no-one ends up wasting mozilla resources reporting a compat problem when they've got 200 odd prefs flipped
- don't differentiate between channels
- both can be made inactive
- webcompat requires user action: and I don't see this as a bad thing to have in non-stable
- unsubmitted crashReports on Nightly is probably already covered by killing the URL, so no big deal
- 0000: remove old XUL info, dropped in FF73+
- 0201: save 3 chars
- 0350: add default status for unsubmittedCheck
- 0351: change to enforce: has been default false going back to at least FF60, including current Beta/Dev/Nightly
- along with 0602 `network.dns.disablePrefetchFromHTTPS` and 0603 `network.predictor.enable-prefetch`, I considered making them inactive, but decided it was good to leave them active for non-stable users just in case they get flipped
- 0515: add default status
- 0850c: remove info: out of date: doesn't work lilke that anymore and can't be assed figuring it out what with megabar and urlbar2 changes
- 0871: make inactive: default false since at least FF60
- no need to enforce for non-stable in case it is flipped. It's a pretty minor shoulder-surfer privacy issue and the previews are small. If you're not sure what this pref does. On false you get one tab shown, on true you get as many as can fit across your screen. I squeezed in 15, and after that it became a list
- fixup `***/`
- shave off six lines and almost 400 bytes for you bastards
- This is too minimal to be of any use, breaks too much (e.g. zoom video)
- Tor browser stopped flipping this (I *think*) about 5 years ago: it certainly hasn't been used in ESR60+ based TB builds, I checked
- we already disable webgl, so making this inactive removes yet another pref users need to flip/troubleshoot
- I will leave it in the user js for a few releases so prefsCleaner will pick it up
- It is controlled in both runtime and via user.js by the state of `media.eme.enabled`. Also, who cares about the vis of a ui option
- note, there is no need to add this to the removed scratchpad list
- remove useless `see` word for reference links
- fixup 0701
- "do not play nice" is not measurable
- don't reference to self as a source: people can just search "VPN leak Ipv6" or something
- shrink and remove outdated info from section 0300 header
- combine some bugzillas
- drop some references
- 1647829 for HTTPS-Only mode
- hardware metrics: not going to implicitly encourage users to use this pref or tell them what sizes to use
- update [STATS]
- also remove TLS [STATS].. stats on TLS 1.0 and 1.1 are irrelevant: the default is now TLS 1.2+
- single CRLite reference for all blog articles
- save 588 bytes so all you bastards can theoretically load Firefox just that tiny bit faster
Note
- this is not the same as 2517 which disables the API
- RFP does not determine what is supported or not supported: so that entropy remains
- with or without RFP, if the media config is not supported it returns false,false (so there is nothing to spoof here)
* misc
- cleanup of old release notation in comments: e.g. if it's not applicable to ESR78+
- same with default version info
- simplify and save bytes on section 4700
- update 4500 header
- and unify the message about using extensions as counterproductive
- letterboxing
- provide info on stepped ranged (and drop crap about FF67)
- don't judge users who dislike seeing margins (I don't like them either, but I force my window to exact dimensions and stay there)
- screenshots uploading was disabled in FF67+ : [67 release notes](https://www.mozilla.org/en-US/firefox/67.0/releasenotes/)
- the pref is still there (default false) but so far I'm 99% sure this pref now does anything
- I will add it to the scatchpad script if this change sticks
* simplify 4500 RFP, see #1041
* update removed script
* tidy readme, see #1045
- also put readme before releases
* RIP FX Site Compat
* clean out RFP Alts info: the information is redundant: it's already in the readme
- make 1401 inactive: it affects RFP's FPing
- remove old warning/setup-web: we do not care about documenting breakage or FPing risks when we have a warning and they are inactive. If someone uses them, that's on them
- new warnings
- this was made inactive in v68
- since at least FF79, when active as false, it breaks the web and browser consoles
- it breaks websites
- it breaks extensions: e.g. uBO panel functionality
- it does nothing to mitigate possible fingerprinting (which was why it was initially added as a concern) - i.e the API only provided a standardized method, it does not stop previous/earlier workarounds
- less active prefs
- now that ESR68 is EOL, at least a whopping two (0602, 1273)
- also I don't know when the default changed - another whopping whole one (1240)
- and where we do enforce/reset a pref to default, lets say that
- this is not a definitive list, sing out if there is anything else
- IPv6 info
- especially for Iron Heart who likes to claim that this pref breaks 5% of sites
- cleanup of settings tags now we only care abut ESR78+
- adds the new tests including the non-JS JA3
Co-authored-by: rusty-snake <41237666+rusty-snake@users.noreply.github.com>
Co-authored-by: earthlng <earthlng@users.noreply.github.com>
