ToDo: create RFP Alternative [inactve] section[s]

[Thorin-Oakenpants]

snip

[earthlng]

1337161 - disable gamepad API (see 2501) (FF56+)

Setting dom.gamepad.enabled to false disables the API and can be detected. resistFingerprinting will provide a better solution by not disabling the API and instead "hiding" any connected gamepads from websites:

1. navigator.getGamepads() will always return an empty array
2. gamepadconnected and gamepaddisconnected events will not be fired

ps. "disable gamepad API" is incorrect because that's not what the patch does.

https://bugzilla.mozilla.org/show_bug.cgi?id=1337161#c2 https://bugzilla.mozilla.org/show_bug.cgi?id=1337161#c3 https://hg.mozilla.org/mozilla-central/rev/41a148dc837d

---

1369309 - spoof media statistics to 0 (see 2506) (FF57+)

they don't spoof to 0, see part 3 of that bug @ https://hg.mozilla.org/mozilla-central/rev/9afd71d7438c

When 57 lands we should probably add a note to media.video_stats.enabled and make it inactive. People who don't want to use resistFingerprinting and/or ESR users can activate it in their own copies.

[Theemim]

Do those prefs being active have any ill effects when privacy.resistFingerprinting is enabled? Some may not enable RFP because they don't see it enabled by default (is code ready for prime time?). Some may disable it if they run into a problem. Doesn't matter if they are ESR or not. If you decide to make the covered prefs inactive, maybe the note shouldn't only mention ESR?

BTW, one question I haven't looked into (but maybe you already know the answer): does disabling the geolocation API prevent the backend communication with the geolocation provider?

[2glops]

FF56+ privacy.resistFingerprinting = true and all relative prefs inactive User could make RFP false and activate only some relative prefs (yes, it loose benefits from RFP, user choice),

ESR52+ User should have an easy way to find and activate all prefs handled by RFP.

From that, I don't see a solution for stable / ESR users to avoid resetting / uncommenting from about:config / user.js. A master could not fits all without user action.

[COVERED BY 2699 FF56+] : Good to see imediately the section number.

How will all prefs covered by RFP be handled after the end of ESR 52 series ? Inactive with a note "covered by RFP" or ignored and flipped out the user.js ?

[savyajha]

I'm not sure if this would be a consideration, but this issue is caused by privacy.resistFingerprinting being true. This is a bit of a bummer, because while I like security, I love performance. If possible, it would be great if we can find a way to get each part of the master switch working.

[earthlng]

Users on stable still need to know what to reset in about:config

we could highlight that in the changelogs IMO

For now I like your super early edit/draft but maybe over time it would be better to move them all to a new section and group them together similar to what we do in the deprecated section, with groups for each release and super-groups for ESR versions. I also think at a certain point RFP will have so many benefits that we no longer should cater for non-RFP users and simply remove the obsoleted prefs, for example when ESR52 reaches EOL.

[2glops]

1369319 - disable device sensor API (see 2512) (FF56+) Provide the similar behavior as 'device.sensors.enabled' = false (checked on Nightly) So, with RFP = true : // user_pref("device.sensors.enabled", false);

[earthlng]

So far I've only found 1 pref that should be made inactive because the RFP code is superior (gamepads). For media_stats a case can be made that maybe spoofing to 0 (by using the pref itself) is better in certain circumstances. The sensors and performance prefs are doing basically the same thing as RFP does and can therefore stay active to make it easier for ESR users. I haven't had time to look at the remaining ones because the UUID-leak came up and I was more interested in that. And I'm using ESR now so the problem here doesn't really affect me and thus I'm in no hurry to get this resolved tbh. You open these massive todo issues and then expect it to get dealt with immediately. The issue here is about "confirm exact actions" and we haven't even done that but you're already thinking about re-structuring the user.js for it. You don't need to be able to read the code to get an idea about what a certain patch does btw; the comments from the devs alone explain it pretty well most of the times. If this is a high priority issue for you, you can help speed this up by reading their comments and quoting them here, which in turn helps me (and maybe others) because I won't have to read the whole bugzilla comment section and can just quickly look at the code to confirm that we either still need or don't need a certain pref anymore. It takes time to do these things properly and our manpower here is pretty limited, so people either need to live with that and accept that we get to it when we get to it, or they need to step up and help out.

What do you think of my idea for the section jiggling and one-char switch ALT section

IMO, for now we should just use [COVERED BY 2699 FFxx+] tags for the few prefs that we end up making inactive, and maybe something like [INCLUDED IN 2699 FFxx+] for the ones that we keep active. Eventually we can open another issue to create a new section for them. That way we also don't clutter the comments here with 2 separate issues. Yeah that sucks for ESR users but we can deal with that in the changelogs. We'll get to it when we get to it!

[earthlng]

2697: USER AGENT (UA) SPOOFING 2698: FIRST PARTY ISOLATION (FPI) 2699: privacy.resistFingerprinting ^^ renumber these, add in privacy.resistFingerprinting ALTERNATIVES

suggest

4000: privacy.resistFingerprinting 4001: privacy.resistFingerprinting ALTERNATIVES 4002: USER AGENT (UA) SPOOFING 4003: FIRST PARTY ISOLATION (FPI)

• shove shutdown out to 5000 & personal out to 6000 or something

shutdown is pretty important and shouldn't be moved too far down IMO, lets keep it 2800. Personal to 5000 or so is ok. What to do with USER AGENT (UA) SPOOFING though? For starters we should probably rename it to NAVIGATOR SPOOFING. Although, does it even need to be its own section anymore when we create an RFP ALTERNATIVES? - IMO no, because 2697a-f are all covered by RFP and it should be in the RFP ALTZ section or completely removed. And looking at the patch for spoofing Navigator API => platform, appname + appversion cannot be overwritten anymore when RFP=true anyway.

Since FPI is almost done I think it should come first and can be its own, round-hundred number, 4000 for example. And then RFP = 4100 and RFP ALTZ 4200 or so.

[earthlng]

https://developer.mozilla.org/en-US/docs/Web/API/SpeechRecognition#Browser_compatibility

• [2] Can be enabled via the media.webspeech.recognition.enable flag in about:config on mobile. Not implemented at all on Desktop Firefox — see bug 1248897.

Only media.webspeech.synth.enabled is now covered by RFP and our current approach to move more than just the prefs that are covered by RFP to the new section is not great IMO. Same for 4609.

[earthlng]

I think we can remove media.webspeech.recognition.enable completely. The ticket mentions Q2 2018 when it should be ready and we will see it in the diffs. Then we can check if we even need that pref or if it's already covered by RFP. [EDIT] link [1] in 4608 can go as well.

you said just the 4 geo.*

I said quote "geo.enabled only"! I like what pyllyukko does:

// PREF: When geolocation is enabled, use Mozilla geolocation service instead of Google
user_pref("geo.wifi.uri", "https://location.services.mozilla.com/v1/geolocate?key=%MOZILLA_API_KEY%");

// PREF: When geolocation is enabled, don't log geolocation requests to the console
user_pref("geo.wifi.logging.enabled", false); // (hidden pref)

and then we can drop geo.wifi.xhr.timeout and move the 2 browser.search.geoip. currently under 0201 to 0202 and add the link that pyllyukko also has, as well, like this:

/* 0202: disable GeoIP-based search results
 * [NOTE] May not be hidden if Firefox has changed your settings due to your locale
 * [1] https://trac.torproject.org/projects/tor/ticket/16254
 * [2] https://support.mozilla.org/en-US/kb/how-stop-firefox-making-automatic-connections#w_geolocation-for-default-search-engine ***/
user_pref("browser.search.countryCode", "US"); // (hidden pref)
user_pref("browser.search.region", "US"); // (hidden pref)
user_pref("browser.search.geoip.url", "");
user_pref("browser.search.geoip.timeout", 1);

and the new 4609:

// 4609: [0201] disable Location-Aware Browsing (geolocation)
   // [1] https://www.mozilla.org/en-US/firefox/geolocation/
user_pref("geo.enabled", false);

[earthlng]

Go ahead and fix them all with direct commits

done. https://github.com/ghacksuserjs/ghacks-user.js/commit/fec0c992873a417717d76dc20321c97b0c1e3de1 https://github.com/ghacksuserjs/ghacks-user.js/commit/bbb29237ccbbe96046b632812d0945d40a6f7e33

What do you think about keeping the previous number for items moved to 4600, as I did with 4609? [02xx] would also be an option, to at least let users know under which section it was. (?)

[2glops]

A good idea IMO.