1854851 - Inform the user about non-optimal settings when FPP or RFP is enabled

Status: UNCONFIRMED

(Core :: Privacy: Anti-Tracking, enhancement)

Description

[sworddragon2]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/117.0

Steps to reproduce:

1. Go to about:config and set privacy.resistFingerprinting to true.
2. Change common settings in Firefox, for example disabling microphone/camera permissions via Firefox's options GUI.

Actual results:

While privacy.resistFingerprinting is enabled to reduce tracking caused by specific user metrics some other settings (like disabing microphone/camera permissions) work against this.

Expected results:

The RFP code could also keep track of settings that work against it and in some way inform the user about those to make him aware of the issue and give him an easy opportunity to correct those settings if needed. The alternative would be to enforce a value on all those settings - and since those can easily be quite more than just a few this might negatively impact the usability even more.

Since at some point in the future RFP will probably be added to Firefox's options GUI if it advances even more this might be a good opportunity to also implement the first idea here to easily inform the user about those settings.

Comment 1

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'Core::Privacy: Anti-Tracking' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Tom Ritter [:tjr]]

Hm. An interesting idea. I'm going to broaden this a bit to encompass FPP, it might be something we want to do depending on what RFP Targets we enable there.

For RFP specifically, we would probably take the lead from Tor Browser on this and see if there were specific things they wanted to do..

Comment 3

[sworddragon2]

If I recall correctly from a test on fingerprinting-testing websites quite a while ago users with the default settings on the example above (disabling to ask for specific permissions like camera/microphone) provided the least amount of entropy while users that disabled them in all categories were on second place - but still fine.

But now I feared after that long time there might have been new permissions choices been added which might have caused me to get into a more unique pool over time so I rechecked them. At some point in the future I probably call them legacy for myself and go with the default values - which would be currently a bit tedious to change (since I don't recall what exactly was the default). And who knows what other settings might bring me in the same scenario even while I'm already pretty careful.

So yes, a feature that tells me about my mistakes and how to change them would be really helpful here and prevent fingerprinting even more especially for older profiles.

For FPP I noticed there is a new setting in the options GUI in Firefox 118 that seems to be mapped to privacy.fingerprintingProtection(.pbmode). But the tracking protection dialog in the options GUI has no good reputation at all in my mind despite anti-tracking/fingerprinting having an extraordinary high priority for me.
It has the dFPI setting to isolate cookies but I recall vaguely that this one also had strings attached to it. And from a test I saw from external parties in the past I remember that the other settings (or several of them) are downloading a list of websites which is very imcomplete and has barely any effect.

And when I saw the FPP setting there I'm just waiting for it to backfire somehow as well. Unfortunately I could not find the setting explained in the SUMO article when the Firefox version was set to 118. But maybe this is just a temporary localization issue but unfortunately I did not see anything on the site that lets me change it to my preferred language and the usual workaround to change the "de" here to "en" in the address does not work since the parts after it are also localized.

Well, I guess I will figure out what the setting does in the next days anyways. For now I just disabled it - RFP is enabled which I see mainly as the strong protection so I should be fine.

Comment 4

[sworddragon2]

(In reply to sworddragon2 from comment #3)

For FPP I noticed there is a new setting in the options GUI in Firefox 118 that seems to be mapped to privacy.fingerprintingProtection(.pbmode). But the tracking protection dialog in the options GUI has no good reputation at all in my mind despite anti-tracking/fingerprinting having an extraordinary high priority for me.
It has the dFPI setting to isolate cookies but I recall vaguely that this one also had strings attached to it. And from a test I saw from external parties in the past I remember that the other settings (or several of them) are downloading a list of websites which is very imcomplete and has barely any effect.

Still, ETP Strict possibly seems to fit as most sane default yet.

(In reply to sworddragon2 from comment #3)

And when I saw the FPP setting there I'm just waiting for it to backfire somehow as well. Unfortunately I could not find the setting explained in the SUMO article when the Firefox version was set to 118. But maybe this is just a temporary localization issue but unfortunately I did not see anything on the site that lets me change it to my preferred language and the usual workaround to change the "de" here to "en" in the address does not work since the parts after it are also localized.

I believe it enables most but not all capabilities of RFP and does effectively allow for webcompat this way - to disable chosen capabilities on troublesome sites. Basically it is like RFP just with exceptions. Probably a similar thing what happened with dFPI as it seems to be like FPI just with some exceptions (for dFPI some or maybe even all(?) of them can be disabled via about:config). Maybe this could be a way to unify RFP and FPP? privacy.resistFingerprinting could be removed and the user needs now to enable privacy.fingerprintingProtection + e.g. a newly introduced privacy.fingerprintingProtection.strict to achieve the same behavior as RFP. Maybe this could be even implemented well in the options UI (as well for dFPI).

But I actually I haven't gotten here now for this - I just did reread the posts before writing and found those 2 things to respond to. I will create another post for my actual matter.

Comment 5

[sworddragon2]

Originally I have requested a mechanism to inform the user about non-optimal settings that might result in better traceability. While personally I would accept tradeoffs like switching from my current autoplay and permissions settings there are things I would not change (like https-only mode) even if they put me into a more unique pool.

And then there was an event recently that caused me to create ticket #1951278 which also caused me to check around a bit for other browsers and besides considering the TOR Browser I also learned about LibreWolf.

LibreWolf is focused on privacy and has RFP enabled by default. It also has more hardened default settings and quite several of them comply with my ones. I already made the decission to migrate over to LibreWolf as soon as Firefox opens a dialog after a future update with the new terms and if declining them prevents me using Firefox. However, even assuming this won't happen and I will stay on Firefox I started doubting if this would be still the right decision. The rational behind this is that LibreWolf provides defaults that I eventually don't even need to change at all with only minor tradeoffs so I'm in an optimal pool of users and thus reducing traceability as much as possible which I currently could not achieve with Firefox even if this feature request here in its original form would be implemented.

And where I want to go with all this: The feature I requested here intends to tell the user about all traceable settings that are different from their default. However, nobody sayed we need to use Firefox's normal default here - we could just define a default subset for RFP that this feature would recommend (e.g. it could complain when https-only mode is off (currently still Firefox's default I believe) and not when it is on).

Even more ideally such a default subset would match as close as possible the ones of other prominent RFP-enabled browsers to avoid pool fragmentation as much as possible and effectively to make Firefox a serious choice amongst those browsers again.