Open
Bug 1428331
Opened 7 years ago
Updated 2 years ago
HiDPI and privacy.resistFingerprinting
Categories
(Core :: Layout, defect)
Core
Layout
Tracking
()
UNCONFIRMED
People
(Reporter: bruno.n.pagani, Unassigned, NeedInfo)
References
(Depends on 1 open bug, Blocks 3 open bugs)
Details
(Whiteboard: [fingerprinting][fp-triaged])
Attachments
(4 files)
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).
Reporter | ||
Comment 1•7 years ago
|
||
It also affect pdf.js rendering.
Comment 2•7 years ago
|
||
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
Component: Untriaged → General
Reporter | ||
Comment 3•7 years ago
|
||
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.
Reporter | ||
Comment 4•7 years ago
|
||
Reporter | ||
Comment 5•7 years ago
|
||
Reporter | ||
Comment 6•7 years ago
|
||
Reporter | ||
Comment 7•7 years ago
|
||
Reporter | ||
Comment 8•7 years ago
|
||
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•7 years ago
|
||
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?
Flags: needinfo?(tom)
Flags: needinfo?(milan)
Comment 10•7 years ago
|
||
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.
Flags: needinfo?(tom)
Whiteboard: [fingerprinting-breakage]
Probably more of a layout question first?
Flags: needinfo?(milan) → needinfo?(dbaron)
Comment 12•7 years ago
|
||
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•7 years ago
|
||
(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.)
Updated•7 years ago
|
Priority: -- → P5
Whiteboard: [fingerprinting-breakage] → [fingerprinting-breakage][fp-triaged]
Updated•6 years ago
|
Blocks: fingerprinting-breakage
Whiteboard: [fingerprinting-breakage][fp-triaged] → [fingerprinting]
Updated•6 years ago
|
Blocks: uplift_tor_fingerprinting
Whiteboard: [fingerprinting] → [fingerprinting][fp-triaged]
Updated•6 years ago
|
Priority: P5 → P3
Comment 14•6 years ago
|
||
see also Bug 1216800
Comment 15•4 years ago
|
||
Per the comments, seems like this should live in layout.
Component: General → Layout
Priority: P3 → --
Product: Firefox → Core
Comment 16•3 years ago
|
||
I got the same problem on wetty which uses xterm.js.
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•