1447592 - Don't reset privacy.spoof_english when privacy.resistFingerprinting is flipped back to false

Status: RESOLVED FIXED

(Firefox :: Security, defect, P2)

Description

[sworddragon2]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0
Build ID: 20100101

Steps to reproduce:

If a website is being visited Firefox 59 shows now a dialog and asks the user if he wants to set his preferred language to english to reduce tracking (probably privacy.resistFingerprinting needs to be set to true to make this dialog to appear). The choice for this setting gets stored into privacy.spoof_english.


Actual results:

If privacy.resistFingerprinting is now flipped back to false it will also reset privacy.spoof_english which has the negative side-effect that the user has to set this preference again (causing the dialog to appear again) after he enables privacy.resistFingerprinting again.


Expected results:

Either:
1. privacy.spoof_english has not effect if privacy.resistFingerprinting is set to false -> so there is no reason to reset it as it is likely the user wants to have its last used setting back instead of configuring it again.
or:
2. privacy.spoof_english has an effect if privacy.resistFingerprinting is set to false (currently I assume this being the unlikely case) -> there is now even more a reason to not reset it.


Additional information:

For example this has currently a negative impact on usability for me as I need to temporarily disable privacy.resistFingerprinting so that http://www.kongregate.com is able to detect the Flash Player. After the detection has occured I enable privacy.resistFingerprinting again but now I get asked again if I want to set english to my preferred language while I would prefer this selection would still have been remembered.

Comment 1

[Adrian Florinescu [:aflorinescu]]

Thank you for the report. 
I can't reproduce the issue on ESR 52.7.2 20180315163333 and given the fact that AFAIK, antifingerprinting is not an ESR 52 feature, i will assume that the report is related to release 59.0.1 20180315233128, where I can reproduce the issue. I can reproduce this issue on 61.0a1 20180325220121 and on 60.0b6 20180322152034. (updating flags accordingly) 

Since I don't know the functionality for "privacy.spoof_english", I'm not sure if this is an an enhancement but as an initial triage I think blocking bug 1329996 and Firefox::Preferences as component are a good step forward.

Comment 2

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

That's annoying, but I think it's an easy fix.

Comment 3

[sworddragon2]

(In reply to Adrian Florinescu [:AdrianSV] from comment #1) 
> I can't reproduce the issue on ESR 52.7.2 20180315163333 and given the fact
> that AFAIK, antifingerprinting is not an ESR 52 feature, i will assume that
> the report is related to release 59.0.1 20180315233128, where I can
> reproduce the issue.

Yes, I have found this issue while using Firefox 59.0.1. Since I'm using Firefox normally with privacy.resistFingerprinting set to true the version of Firefox gets spoofed resulting in an autodetection of Firefox 52 (and I always forget about it on creating new tickets).


For some reason while still being on the same version of Firefox the issue doesn't reproduce anymore for me. But in the meantime I noticed that answering the dialog question with yes (causing privacy.spoof_english to be set to 2) causes also non-english languages to be removed from the language settings. I'm not sure why this actually happens as this seems to be redundant and making it more difficult for the user to revert the settings. However, maybe fiddling around with those settings to correct them caused to change the behavior of this issue causing it to not reproduce anymore for me - or just something else caused it.

Comment 4

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

Attachment: Bug 1447592 Do not reset the Spoof English pref after disabling Resist Fingerprinting

Review commit: https://reviewboard.mozilla.org/r/231842/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/231842/

Comment 5

[Johann Hofmann [:johannh]]

Comment on attachment 8962998 [details]
Bug 1447592 Do not reset the Spoof English pref after disabling Resist Fingerprinting

https://reviewboard.mozilla.org/r/231842/#review237872

Thanks!

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/0473a11b4734
Do not reset the Spoof English pref after disabling Resist Fingerprinting r=johannh

Comment 7

[Andrei Ciure[:aciure]]

https://hg.mozilla.org/mozilla-central/rev/0473a11b4734

Comment 8

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

This should be fixed on Nightly, if you're able to confirm.

Comment 9

[sworddragon2]

I'm more concerned that this issue didn't reproduce anymore for me and since the reason is unknown that this also might hard to tell on a new profile. Comment #2 implies that you was able to reproduce this issue. Couldn't you reproduce it anymore with your patch being applied?

In any case I assume all is fine for now and if I should see this issue with Firefox 61+ on a productive environment again I'm reopening this ticket or creating a new one.

Comment 10

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

(In reply to sworddragon2 from comment #9)
> I'm more concerned that this issue didn't reproduce anymore for me and since
> the reason is unknown that this also might hard to tell on a new profile.
> Comment #2 implies that you was able to reproduce this issue. Couldn't you
> reproduce it anymore with your patch being applied?
> 
> In any case I assume all is fine for now and if I should see this issue with
> Firefox 61+ on a productive environment again I'm reopening this ticket or
> creating a new one.

The reason was pretty clear actually, it was an easy patch. I believe it's fixed but it's good to get external verification. Please do reopen this ticket if you see it again on 61+. If I don't hear anything in a week or so I'm going to uplift to 60.

Comment 11

[sworddragon2]

(In reply to Tom Ritter [:tjr] from comment #10)
> The reason was pretty clear actually, it was an easy patch.

But it doesn't reproduce anymore on Firefox 59.0.1 (without the patch) which is the actual problem here.