- 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.
