Open Bug 1507879 Opened 2 years ago Updated 6 months ago

Investigate getClientRects for fingerprinting


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





(Reporter: tjr, Unassigned)


(Depends on 1 open bug, Blocks 1 open bug)


(Whiteboard: [tor 29564][fingerprinting][fp-triaged])

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 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:
    other tickets / teething issues etc (as a heads up) (fixed) (breaks startpage, fixed)

See Also:

P3 for now, but probably a P2.
Component: DOM → DOM: CSS Object Model
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.
Whiteboard: [tor 18500][fingerprinting][fp-triaged] → [tor 29564][fingerprinting][fp-triaged]

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

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.

Flags: needinfo?(tom) 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?)

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

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

FYI: .. which is the same as the domrect test from which is based on

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?

(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

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.

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

You need to log in before you can comment on or make changes to this bug.