1507879 - Investigate getClientRects for fingerprinting

Status: NEW

(Core :: DOM: CSS Object Model, enhancement, P3)

Description

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

getClientRects and related APIs (at least Element.getBoundingClientRect and Element.clientWidth, Element.clientHeight but probably others) allow one to get precise measurements of how DOM nodes are rendered. This has fingerprinting implications.

At the very least, fonts are a vector. (Tor fortunetly mitigates this.) There's rounding the content window at startup which is relevant too. 

But I'm wondering if there are other vectors. Like GPU rendering of a page perhaps? 

I compared TB8 and TB8.5 and got the same results on https://browserleaks.com/rects thankfully

An early idea was to round or floor or ceil the results returned; however I don't think this is a good approach, as an attacker could just slowly increase size until the value increments, and learn the real value from that.

CanvasBlocker randomizes the values (but doesn't change those three values that are only 2 decimal places)
- looks like it fuzzes by +/- 0.100 (we could easily check the code on github)

    original ticket: https://github.com/kkapsner/CanvasBlocker/issues/236
    other tickets / teething issues etc (as a heads up)
        https://github.com/kkapsner/CanvasBlocker/issues/275 (fixed)
        https://github.com/kkapsner/CanvasBlocker/issues/270 (breaks startpage, fixed)

See Also: http://jcarlosnorte.com/security/2016/03/06/advanced-tor-browser-fingerprinting.html

P3 for now, but probably a P2.

Comment 1

[Simon Mainey]

FYI: a cleaner test page: https://canvasblocker.kkapsner.de/test/domRectTest.html

Comment 2

[KOLANICH]

https://github.com/KOLANICH/Article-2015-Dull-captaincy-or-the-way-Tor-Project-fights-browser-fingerprinting

Comment 3

[KOLANICH]

For some reasons LaTeX to pdf build is currently broken, so either build on a local machine, or read the source, or take the pdf from the latest successful build from gitlab mirror.

Comment 4

[Simon Mainey]

also see: https://trac.torproject.org/projects/tor/ticket/29564
also use: https://ghacksuserjs.github.io/TorZillaPrint/TorZillaPrint.html#domrect

Comment 5

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

I tested on Firefox Nightly on Windows 10 with RFP enabled.

I found that the following desktop settings affected the output of the DomRect test on https://ghacksuserjs.github.io/TorZillaPrint/TorZillaPrint.html

Display -> Change the size of text, apps and other items
Display -> Resolution

The following did not:

Display -> Color Profile (although maybe the test doesn't use colors, I'd have expected this one to affect it...)

I did not test Orientation (too hard) or Nightlight (wrong time of day).

So there is definitely no question that we are leaking device configuration information here; even on Tor Browser where the fonts are fixed.

Comment 6

[Simon Mainey]

color? > https://privacycheck.sec.lrz.de/active/fp_gcr/fp_getclientrects.html

Comment 7

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

https://trac.torproject.org/projects/tor/ticket/29564#comment:4 is a great comment pointing to some pages that have a lot more explicit examples of what exactly clientrect is measuring in rendering. (Comment 6 too)

I'm not sure what TorZillaPrint is rendering; but the pages comment illustrates that rendering browser elements (like selects or progress bars) and MathML and Emoji are other non-font related problems.

At this point it seems very likely to me that we won't be able to neuter this API to return safe data, so we need to either gate it behind a prompt like canvas image extraction or just disable it entirely.

To do that I expect we're going to need to figure out some estimation of what we'll break. We could add telemetry for the APIs. We can examine tracking scripts to see if they use it (from historical crawl data?). We can examine non-tracking scripts to see if it uses it (from fresh crawl data?)

Comment 8

[Simon Mainey]

(In reply to Tom Ritter [:tjr] (On Leave) from comment #7)

I'm not sure what TorZillaPrint is rendering...

FYI: https://ghacksuserjs.github.io/TorZillaPrint/iframes/domrect.html .. which is the same as the domrect test from https://canvasblocker.kkapsner.de/test/ which is based on https://browserleaks.com/rects

Comment 9

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

With the help of Steve, we ran a quick OpenWPM scan looking for usages of getClientRects and related. The results I found, based on the un-minified function names, are all focused on visibility checking; so I am lead to believe that at this time it's not used for fingerprinting.... much?

Comment 10

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

(In reply to Tom Ritter [:tjr] (On Leave) from comment #5)

I tested on Firefox Nightly on Windows 10 with RFP enabled.

I found that the following desktop settings affected the output of the DomRect test on https://ghacksuserjs.github.io/TorZillaPrint/TorZillaPrint.html

Display -> Change the size of text, apps and other items

This is now Bug 1538718

Display -> Resolution

This I think was a misdirect, not understanding all the properties.

Comment 11

[Emilio Cobos Álvarez (:emilio)]

GPU or such doesn't affect getBoundingClientRect and co. DPI does though.