Tor Browser DPI spoofing omitted window.devicePixelRatio

I suspected that the test for DPI at browserspy.dk was not functioning properly, so I kind of dared people on Twitter to come up with a PoC for using relative element sizing to infer true DPI, beating Tor Browser's DPI-spoofing. 0xPoly reported that the true DPI size can be inferred via such a mechanism, and provided the following example PoC:

page.html:

<div id='testdiv' style='height: 1in; left: -100%; position: absolute; top: -100%; width: 1in;'></div>

page.js:

var devicePixelRatio = window.devicePixelRatio || 1;
dpi_x = document.getElementById('testdiv').offsetWidth * devicePixelRatio;
dpi_y = document.getElementById('testdiv').offsetHeight * devicePixelRatio;

alert(dpi_x);

In Tor Browser, even on high-density displays, the DPI is correctly spoofed to 96x96, and the above code does alert('96'). However, if the user changes the zoom level, i.e. via Ctrl-+ or Ctrl--, then the above Javascript will detect a non-96x96 DPI. When I tested (on a machine with a 96x96 DPI display), zooming once led to alert('115.20000457763672'), however that '115.20000457763672' stayed the same if I scaled the browser window size differently and reloaded the page (keeping the zoom at the same level). Peter Todd reported that detecting the zoom level also works on a high-density display.

This may particularly be a problem on huge displays, or any other displays probably viewed from a greater-than-arms-length distance, where the users are constantly zooming in.

Possibly related: #7256 (moved)

added GeorgKoppen201505R TorBrowserTeam201505R component::applications/tor browser owner::tbb-team priority::high resolution::fixed status::closed tbb-fingerprinting-resolution tbb-firefox-patch tbb-testcase type::defect labels

Trac:
Cc: isis, gk, mikeperry to isis, gk, mikeperry, pete@petertodd.org

Apparently this may also be an issue if the user tweaks some Windows DPI scaling option? Unclear what that is or what that means. https://twitter.com/0xPoly/status/539593347078164480

I'm less concerned about zoom being detectable, especially since the process of zooming will cause all sorts of CSS reflows that will likely be detectable no matter what, at least with how zoom is currently implemented.

There's also #4316 (moved) though, which is perhaps more concerning. I wonder if #4316 (moved) is still even an issue though. That sure is an old ticket.

Replying to mikeperry:

Apparently this may also be an issue if the user tweaks some Windows DPI scaling option? Unclear what that is or what that means. https://twitter.com/0xPoly/status/539593347078164480

I didn't understand that either… perhaps that person will comment more. Thanks, mikeperry, for cataloging that tweet for me; I nearly forgot to add it to the ticket.

hello, poly here. Sorry for the late reply, I'm just getting used to the trac system.

I created a writeup (with photos!) to clarify the windows dpi scaling and another POC to show that the actual zoom level can be inferred. Skip to the description section for the relevant stuff. Can anyone try the second POC and comment on how reliable it is?

http://darkdepths.net/dpi-leaks-in-tor-browser.html

Trac:
Username: poly

Trac:
Username: poly
Cc: isis, gk, mikeperry, pete@petertodd.org to isis, gk, mikeperry, pete@petertodd.org, poly@darkdepths.net

Replying to poly:

hello, poly here. Sorry for the late reply, I'm just getting used to the trac system.

I created a writeup (with photos!) to clarify the windows dpi scaling and another POC to show that the actual zoom level can be inferred. Skip to the description section for the relevant stuff. Can anyone try the second POC and comment on how reliable it is?

I did often get no zoom level back while zooming around but maybe that's just because the zoom level was not exactly hard-coded. But I could confirm that #4316 (moved) is fixed, thanks. That said this ticket is a duplicate of #8076 (moved).

Trac:
Resolution: N/A to duplicate
Status: new to closed

Trac:
Resolution: duplicate to N/A
Status: closed to reopened

Reopened this to dup the other way, ie: calling #8076 (moved) the dup (or simply closed, as this ticket contains the results of investigation).

Replying to mikeperry:

Reopened this to dup the other way, ie: calling #8076 (moved) the dup (or simply closed, as this ticket contains the results of investigation).

Well, the investigation is not over, there is still the CSS case and the things we wanted to study (large amount of variability) which is why I duped it the way I did. That said I don't feel so strongly that I'd start duping this over again but I think we should make sure that a fix we provide for this particular PoC catches all the other DPI-spoofing-is-broken-scenarios, too.

Some relevant resources from #8076 (moved):

https://developer.mozilla.org/en-US/docs/CSS/resolution https://bugzilla.mozilla.org/show_bug.cgi?id=564815 (the devicePixelRatio bug)

Oh, and while I am at it: the issue is visible with a default Tor Browser without messing with the zoom at all (which is why I changed the summary and raised the priority).

Trac:
Priority: normal to major
Keywords: N/A deleted, tbb-testcase, tbb-firefox-patch added
Summary: Tor Browser DPI spoofing is broken if the user changes zoom level to Tor Browser DPI spoofing is broken

Trac:
Keywords: tbb-fingerprinting deleted, tbb-fingerprinting-resolution added

Trac:
Cc: isis, gk, mikeperry, pete@petertodd.org, poly@darkdepths.net to isis, gk, mikeperry, pete@petertodd.org, poly@darkdepths.net, brade, mcs

Trac:
Cc: isis, gk, mikeperry, pete@petertodd.org, poly@darkdepths.net, brade, mcs to isis, gk, mikeperry, pete@petertodd.org, poly@darkdepths.net, brade, mcs, arthuredelstein

Here's a fixup to our #5856 (closed) patch that spoofs window.devicePixelRatio to 1 for content scripts:

https://github.com/arthuredelstein/tor-browser/commit/a5648c8d80f396caf294d761cc4a9a76c0b33a9d

I ran into this issue while working on #14429 (moved) (and #7256 (moved)).

Trac:
Keywords: N/A deleted, TorBrowserTeam201504R added
Status: reopened to needs_review

Kathy and I looked at the patch and it looks good. Do you think this addresses all of the issues for this ticket?

Replying to mcs:

Kathy and I looked at the patch and it looks good. Do you think this addresses all of the issues for this ticket?

As far as I am aware. I believe your patch for #2875 (closed) already took care of the "-moz-device-pixel-ratio" and "resolution" media queries: https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0esr-4.5-1&id=958aa2e6bcb71f497ec9253fdf9b6dfc1553225c

Trac:
Keywords: N/A deleted, MikePerry201504R added

Also looks good to me. poly: feel free to reopen this or open a new ticket if you notice any remaining issues. This fix will appear in 4.5-stable.

Trac:
Status: needs_review to closed
Summary: Tor Browser DPI spoofing is broken to Tor Browser DPI spoofing omitted window.devicePixelRatio
Resolution: N/A to fixed

It turns out my fix made it impossible for chrome code to read the true devicePixelRatio of a content window, which is needed for my patch in #14429 (moved) (and may be useful in general). So here's another fixup which continues to spoof devicePixelRatio for content code, but returns the true value for chrome code:

https://github.com/arthuredelstein/tor-browser/commit/7a4d6e2bf2b3cd0812b93dab5a899f2412340154

Trac:
Status: closed to reopened
Keywords: TorBrowserTeam201504R, MikePerry201504R deleted, TorBrowserTeam201505R, MikePerry201505R added
Resolution: fixed to N/A

Trac:
Status: reopened to needs_review

My typical question with this IsCaller stuff: Is this property exported to WebSockets? What happens there?

Also, how about scripts inside blob URIs from the URL bar? And blob URIs from an iframe?

Replying to mikeperry:

My typical question with this IsCaller stuff: Is this property exported to WebSockets? What happens there?

Are you thinking of WebWorkers? I ran a quick manual test, and devicePixelRatio is not exposed to WebWorkers.

Also, how about scripts inside blob URIs from the URL bar? And blob URIs from an iframe?

Yeah, again I think you're right that the IsCallerChrome() call is dangerous, and I should have thought about these possibilities more. Also it worries me that using IsCallerChrome to prevent leaks to content is not very future-proof, even if we can confirm that it is airtight now.

An alternative method for getting the "true zoom level" of a content window, instead of

let trueZoom = gBrowser.contentWindow.devicePixelRatio;

is to call

let trueZoom = gBrowser.contentWindow.QueryInterface(Ci.nsIInterfaceRequestor)
                       .getInterface(Ci.nsIDOMWindowUtils)
                       .screenPixelsPerCSSPixel;

So here's an alternative patch that leaves nsGlobalWindow::GetDevicePixelRatio with the IsChrome call and instead fixes nsDOMWindowUtils::GetScreenPixelsPerCSSPixel so that it isn't spoofed when "privacy.resistFingerprinting" is activated. The latter call is only available from chrome code.

https://github.com/arthuredelstein/tor-browser/commit/4c316cacb6383c9b60606630ef331301fa51da10

Given that we only need this for #14429 (moved), I am going to defer this until 5.0a1.

Trac:
Keywords: MikePerry201505R deleted, GeorgKoppen201505R added

Looks good to me.

Ok, this is merged into tor-browser-31.7.0esr-5.0-1 for 5.0a1.

Trac:
Resolution: N/A to fixed
Status: needs_review to closed

closed

mentioned in issue #14429 (moved)

mentioned in issue #15474 (moved)

mentioned in issue #18144 (moved)

moved to tpo/applications/tor-browser#13875 (closed)