Consider to change the spoof value of window.devicePixelRatio
Categories
(Core :: DOM: Security, enhancement, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox127 | --- | fixed |
People
(Reporter: ethan, Assigned: pierov)
References
(Blocks 2 open bugs)
Details
(Whiteboard: [fingerprinting][fp-triaged][domsecurity-active])
Attachments
(1 file)
The Window property devicePixelRatio returns the ratio of the resolution in physical pixels to the resolution in CSS pixels for the current display device. This value could also be interpreted as the ratio of pixel sizes: the size of one CSS pixel to the size of one physical pixel. In simpler terms, this tells the browser how many of the screen's actual pixels should be used to draw a single CSS pixel. [1]
When the pref "privacy.resistFingerprinting" is set as true, we spoof the value of window.devicePixelRatio as 1, regardless of the real ratio. This behavior increases the protection of user privacy by reducing the entropy of the browser client fingerprint. However, it causes a side-effect that some web pages become blurred with the spoofed value, such as Google Spreadsheet. [2]
Changing the spoof value as 1.5 or 2 might resolve the blur issue, but we need to make sure such change won't cause other side-effects or breakage. This bug is filed to track the investigation work.
[1] https://developer.mozilla.org/en-US/docs/Web/API/Window/devicePixelRatio
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1532859
| Reporter | ||
Updated•6 years ago
|
Comment 1•5 years ago
|
||
Unassign myself because I am no longer actively working on this.
According to https://developer.mozilla.org/en-US/docs/Web/API/Window/devicePixelRatio, changing it to 2 shouldn't result in any breakage, since if it's implemented as in the example (which might be the only proper way), it should only influence the actual size in memory rather than the display size. That is, the memory usage will be doubled in some steps of the rendering pipeline.
It's a performance penalty for the 96 dpi devices only. On Mobile devices and hidpi laptops the resource usage is expected.
On the other hand, if it really degrades the user experience such explicitly, it should be split from the privacy.resistFingerprinting and be privacy.resistFingerprinting.spoofDevicePixelRatio
Updated•3 years ago
|
Comment 3•2 years ago
|
||
https://bugzilla.mozilla.org/show_bug.cgi?id=1582021#c42
4 months ago
FWIW, returning 2 is being used in Tor Browser (and Mullvad Browser) 13 - currently in alpha, these are the ESR115 based releases. Once it percolates a little in release channel with no issues
And 4 months later, with this in release, there have been no reported side-effects or breakage. **It is time to land this bug :) **
This should solve Bug 1582021, Bug 1533787, Bug 1532859, Bug 1428331 and of course this one. RFP is not front facing nor officially supported in Firefox, the patch is very simple and the risk low to non-existent
pinging tom
Comment 4•2 years ago
|
||
I'd say "let's ship it" :)
| Assignee | ||
Comment 5•2 years ago
|
||
Updated•2 years ago
|
Comment 6•2 years ago
|
||
I'm not convinced there will be no breakage. It seems likely to me that users on monitors where the dPI is 1 will see icons rendered twice as large or something.
But if Tor is shipping it, I'm okay uplifting it.
Comment 8•2 years ago
|
||
Backed out for causing mochitest failures in test_bug418986-1.html
- Backout link
- Push with failures
- Failure Log
- Failure line: TEST-UNEXPECTED-FAIL | dom/base/test/test_bug418986-1.html | window.devicePixelRatio should be equal to 1 - got 2, expected 1
| Assignee | ||
Comment 9•2 years ago
|
||
Sorry, I ran a testbuild but somehow I missed this failure or it didn't catch it.
Amended the commit to update the test (but I need someone to please land it again for me).
Comment 10•2 years ago
|
||
Comment 11•2 years ago
|
||
Landed successfully.
Comment 12•2 years ago
|
||
| bugherder | ||
Description
•