User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.100 Safari/537.36

Steps to reproduce:

Set privacy.resistFingerprinting to true in about:config and ran browser fingerprint test at https://panopticlick.eff.org/

Actual results:

Screen Size and Color Depth changed from 3440x1440x24 (an uncommon, but standard size) to 1152x1041x24 (a completely unique size)

Expected results:

Screen Size and Color Depth should have changed to the most common screen size that the window, as currently sized, would fit in. e.g. if the window was 1152x1041 the reported screen size should be 1920x1080. It is utterly nonsensical for a feature which is supposed to reduce a browser fingerprint, to actually make it unique.

While that would be ideal; lying about the screen size produces poor layout rendering. We have theorized about a way where we might lie about the size but still render things moderately well; but even then we think there would be several types of rendering artifacts and the system as a whole is quite complicated to implement. It's not out of the question to POC it, but it is not on the roadmap right now.

Instead we implemented letterboxing (enabled with privacy.resistFingerprinting.letterboxing) which will letterbox your content window to a dimension multiple to reduce the uniqueness.

If lying about screen size produces a poor rendering layout (any example of code in the wild that does this would be appreciated, so I could better understand the issues), then the code as existing when resistFingerprinting=true already does that. Changing it to report 1920x1080 instead of a completely custom size would surely produce no worse layout, and is obviously superior to providing a completely unique resolution. I must admit, I can't understand why returning the largest common screen resolution that completely fits the window would result in adverse effects, while contributing greatly to anti-fingerprinting by replaying uncommon large resolutions with common ones. I admire the push Firefox has been making recently towards privacy, and this should be on the roadmap. Letterboxing feels like an ugly kludge.

Hi I've fixed it it works like it should do now!

Hi Lizard,

Thanks for the details. Using this page http://whatismyscreenresolution.net/ I was able to reproduce the bug on the following versions:

nightly 69.0a1 (2019-06-27) (64-bit)
release 67.0.4 (64-bit)
Beta 68.0b13 (64-bit)

I've chosen a component. If you consider that there's another component that's more proper for this case you may change it.

This might be a duplicate of bug 1330882 but I'm not sure.

Best regards, Flor.

Thanks for the patch; I'll try it out and see if I can identify any specific breakages!

Ah; I tried out this patch - I didn't notice what it was doing at first look.

There are two relevant resolutions the browser reports: the user's screen resolution, and the viewport size. The viewport size is the size the content has to display itself and the screen resolution is the resolution of your monitor.

When RFP is enabled it lies about the resolution and says it is whatever the viewport is. This means the webpage never knows what your resolution is; although it can infer that it is probably larger than the reported size, and may be the closest resolution that is larger than the reported size (if your window is maximized.) Screen resolution doesn't add that many bits of entropy to a user's fingerprint, since they're fairly standard.

Your viewport is quite unique though: it depends on your toolbars, font sizes, taskbar/dock size, and so on.

Letterboxing disguises the viewport; and lying about the viewport will lead to rendering issues I described earlier.

Lying about the screen resolution will not lead to rendering issues (at least I'm pretty sure it won't) but I'm also not sure what the benefit is to lie about it in the manner of this patch vs what we do currently (after all, we disclose the viewport size). This patch actually leaks more information than we do currently: regardless of what my window size is, this will disclose if my monitor is in portrait or landscape mode.

True, with the current behaviour, it doesn't know what your screen resolution is, but it does know with a very simple check that you're one of the few people on the internet who are using TOR browser or are attempting to reduce your browser fingerprint. It shouldn't be that easy to profile, and would seem to be a low hanging fruit to pick by making it harder by returning a standard resolution. I don't like the idea that a simple check of screen.width==viewport.width && screen.height==viewport.height => set suspicious flag.

Re: being able to identify orientation, I was mindful that some sites might use the reported screen resolution to perform layout changes (e.g. to put a UI toolbar on a different edge so that their webapp responds to orientation changing in a pleasing way when run full screen on a tablet/Surface... but yes they should maybe be using something other than the screen resolution, to drive that logic) so it's a judgement call whether to preserve this, or to always lie and return a common landscape screen resolution, given running a portrait orientation monitor is rare.

(In reply to hello i'm a lizard from comment #7)

True, with the current behaviour, it doesn't know what your screen resolution is, but it does know with a very simple check that you're one of the few people on the internet who are using TOR browser or are attempting to reduce your browser fingerprint. It shouldn't be that easy to profile, and would seem to be a low hanging fruit to pick by making it harder by returning a standard resolution. I don't like the idea that a simple check of screen.width==viewport.width && screen.height==viewport.height => set suspicious flag.

I'm afraid there are a lot of ways to identify that people are in that category; and therefore we don't attempt to hide it. Besides this example:

• canvas image extraction is a blank white square
• font enumeration is a fixed set of fonts (Tor Browser only)
• gamepad/webspeech/device sensors/performance APIs disabled
• performance.now() is a multiple of 100ms
• media devices are spoofed to specific strings
• Media Statistics API is deterministic
• (more, but these were the ones off the top of my head)