1475825 - setting resistFingerprinting to true results in a better fingerprint by screen resolution

Status: RESOLVED INVALID

(Core :: Window Management, defect, P3)

Description

[Marcel]

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

Steps to reproduce:

Works with Firefox 61.0.1 and 63.0a1 (the currently latest build).

("privacy.resistFingerprinting" must be set to false for the first run)
1. Go to https://panopticlick.eff.org and checked the fingerprint ("Screen Size and Color Depth" was 5.13 bits of information (value was 1600x900x24))
2.  Set "privacy.resistFingerprinting" to true
3. Test your browser fingerprint again


Actual results:

The bits of identifying information of the "Screen Size and Color Depth" has gone up to 16.55.
Detected screen resolution of 1600x738x24, which is a more unique value than 1600x900x24 (as 1600x900 is a very common screen resolution, 1600x738 is definitely not).


Expected results:

When activating "resistFingerprinting", the screen size that is reported to websites should be a common value but at least not more identifying than without the resistFingerprinting flag.

Comment 1

[Ethan Tseng [:ethan]]

Tim, could you confirm whether this bug is valid or not?

Comment 2

[Tim Huang[:timhuang]]

It's more like a limitation of the current design of the window dimensions protection. There are two protections should be applied in order to hide the screen resolution including rounding the window size and only report the size of the content viewport for the screen size. However, the rounding only happens during opening a window. So, the browser will report the content viewport size in your case. I believe that the 162 pixels difference is the size of your chrome UI.

IMO, we should either add a warning to inform users to restart the browesr for making the protection effective, like Bug 1403747 wants to do, or dynamically round the content viewport like Bug 1407366 wants to do.

Comment 3

[Marcel]

Ok, I got it know.
When the flag is activated, the property screen.height is actually returning the document's height.
So why not just return full hd or 4K (if the actual screen resolution is higher than full hd) for the screen resolution? I mean, a website should never be interested in the screen resolution right? Maybe the document's resolution.
Here are some arguments that should be considered please:
1. The style of a website can't rely on the screen properties. If there is some website that relies on the resolution, it will be the document's resolution.
2. Returning an unusual resolution will result in better tracking. Also, there is a practical aspect of this: most users just use their browsers maximized.

I'm probably missing something here and I'm sorry for raising the fundamental question: For which purpose does a website need the screen resolution anyway?
I only can think of the document's resolution as reasonable.

Comment 4

[Abe - QA (:Abe_LV)]

I tested this on Ubuntu 16.04 with the latest nightly, and it is reproducible. When privacy.resistFingerprinting" is set to true, the value of "Screen Size and Color Depth" looks unique. 

Test Environment:
Version 	63.0a1
Build ID 	20180718100918
Update Channel 	nightly
User Agent 	Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0

Comment 6

[Ethan Tseng [:ethan]]

This issue is very like to be fixed by bug 1407366.

Comment 7

[Thorin [:thorin]]

(In reply to Ethan Tseng [:ethan] from comment #6)

This issue is very like to be fixed by bug 1407366.

While the letterboxing pref is (currently) independent of privacy.resistFingerprinting, I can confirm that toggling the pref changes the letterboxing

STR (FF67+)

• open browser
• open [1] or [2] to view the inner window measurements in real time (css @media)
• manually resize so the inner window is not 200x100 steps
• in about:config, if not already present, create a new pref privacy.resistFingerprinting.letterboxing as true
• check your open tab with the test page - the letterboxing is in place
• change the pref to false
• check your open tab with the test page - the letterboxing is now gone

We can either close this, or leave it in place until letterboxing is finalized: i.e I assume the letterboxing pref will eventually be removed and the code tied to RFP itself.

Note there is at least one other protection for RFP that requires a restart: TZ spoofing, I think you can turn it on without a restart, but not off - or vice versa, can't remember which. And font whitelisting when implemented needs a restart as well (I know it's not ready yet). Do we need an audit of what requires a restart - maybe we're missing something?

[1] https://demos.traudt.xyz/css/media/index.html
[2] https://ghacksuserjs.github.io/TorZillaPrint/TorZillaPrint.html#screen

Comment 8

[Tom Ritter [:tjr]]

I'm going to resolve this as invalid. The bug report is about entropy. There are two values here, Screen Resolution (A) and Viewport Resolution (B).

With RFP off, A is reported truthfully and B is reported truthfully.
With RFP on, A is reported as B and B is reported truthfully.

The possible values of A are weighted towards standard resolutions; thus reporting the value of B seemingly increases the user's entropy. However when you consider the combination of A and B; with RFP enabled we disclose less information than is revealed when RFP is disabled.

The entropy calculation could be made smarter by detecting if you have RFP enabled (which is trivial); and if so producing a more accurate value. This more accurate value would show that RFP decreases entropy.