1428331 - HiDPI and privacy.resistFingerprinting

Status: UNCONFIRMED

(Core :: Layout, defect)

Description

[Bruno Pagani]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0
Build ID: 20100101

Steps to reproduce:

Enable privacy.resistFingerprinting


Actual results:

HiDPI rendering of website is broken, because a scale factor of 1 is sent.


Expected results:

HiDPI should stay? Or at least maybe configurable.

I know that having some value diverging from the common set is not really good for resisting fingerprinting, but they are already exceptions for e.g. Platform/UA (because spoofing OS is too hard), and regarding HiDPI it makes some pages blurry (osm.org, GitHub repos “network” page) or even very blurry (GMaps, maybe there is something else happening there, I would need to do some more tests).

Comment 1

[Bruno Pagani]

It also affect pdf.js rendering.

Comment 2

[ovidiu boca[:Ovidiu]]

I will move this to General based on the fact that the vast majority of the bugs logged to meta bug 1401493 are in General.
Bruno, can you please add more details of what steps you follow, except the one where you Enable privacy.resistFingerprinting. Thanks

Comment 3

[Bruno Pagani]

So for OSM it seems I was wrong, it’s blurry in both cases.

But GitHub and GMaps are definitively affected. To reproduce, on an HiDPI system (I’m on Linux BTW, so it’s GTK3 providing the DPI for Firefox to decide toggling devcssperpixels to 2) in a clean profile:

1. Open https://github.com/mozilla/multi-account-containers/network. See how it looks crisp.
2. Toggle privacy.resistFingerprinting to true. Reload the page. See how it looks blurry.

You can replace this URL by Google Maps, same kind of results. I’m attaching screenshots for both cases and both sites.

Comment 4

[Bruno Pagani]

Attachment: without_resistFingerprinting.png

Comment 5

[Bruno Pagani]

Attachment: with_resistFingerprinting.png

Comment 6

[Bruno Pagani]

Attachment: maps_noRFP.png

Comment 7

[Bruno Pagani]

Attachment: maps_RFP.png

Comment 8

[Bruno Pagani]

Oh, and regarding Maps they are likely to different issues at the same time, I think that RFP disables WebGL and maybe other things (because just like canvas those can be hashed or something, and I would prefer Firefox to spoof the readout rather than disabling the feature altogether but that is another topic), as you can see by the different rendering of 3D buildings I guess. But if you look for instance at the “Satellite” minibox, you’ll see that picture has twice more details in the nonRFP case.

Comment 9

[Panos Astithas (he/him) [:past] (please ni?)]

Tom, Milan: is it possible to implement a way to properly render the page while withholding the correct DPI values from the web page JS?

Comment 10

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

Hm. I'm not sure.

Certainly anything that lets the webpage view how something was rendered (like Canvas or WebGL) would be able to determine it.  However we try to block those avenues regardless.

But I don't know about it in general. I tend to assume the page is doing something like

> if(hidpi) { render things better }
> else { don't }

in which case we could not lie and get the desired effect.

Comment 11

[Milan Sreckovic [:milan] (needinfo for best results)]

Probably more of a layout question first?

Comment 12

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

So there are various things we do for privacy.resistFingerprinting, such as:
https://searchfox.org/mozilla-central/rev/7fb999d1d39418fd331284fab909df076b967ac6/layout/style/nsMediaFeatures.cpp#296,301-303
https://searchfox.org/mozilla-central/rev/7fb999d1d39418fd331284fab909df076b967ac6/layout/style/nsMediaFeatures.cpp#379,383
https://searchfox.org/mozilla-central/rev/7fb999d1d39418fd331284fab909df076b967ac6/dom/base/nsGlobalWindowOuter.cpp#3532,3544-3546

It's worth noting that there are a bunch of APIs in the web platform that examine a single underlying situation (i.e., the display's dpr, the various zoom states, etc.) in various ways (e.g., the above media queries and window attributes including window attributes that get sizes, what certain CSS units like px and vw compute to, etc.).  I think it's probably worth auditing that the things we're doing to resist fingerprinting are also giving a consistent view of a single underlying state, even if that state is a lie.  This may well require documenting how all those things respond to the various units, which is in itself a worthwhile project for standardization.  If we discover that the things that privacy.resistFingerprinting don't represent a single underlying consistent state, then the inconsistency could certainly break web content, and it probably also means that the fingerprinting resistence is a lot weaker.

Comment 13

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(I also suspect that the current fingerprinting protections may not be obscuring the information they intend to obscure because it's still available via other ways, e.g., through combinations of the APIs being patched, callers that go through APIs like nsGlobalWindowOuter::GetInnerSize, the way CSS units compute, etc.  Building solid fingerprinting protection here does require building that model of how all these things relate.)

Comment 14

[Simon Mainey]

see also Bug 1216800

Comment 15

[:Gijs (he/him)]

Per the comments, seems like this should live in layout.

Comment 16

[shizunge]

I got the same problem on wetty which uses xterm.js.