Tor Browser getClientRects fingerprinting

OK thanks. If you couldn’t work it out, my chances are minimal to none.

BTW was this issue below ever fixed in Tor Browser? If not, it’s a major oversight (and we should also document it).

I note it is the usual story i.e. JavaScript-based, just like the mouse tracking i.e. JS is a tracking nightmare and should basically never be allowed unless absolutely necessary since it is at the core of most tracking efforts.

Advanced Tor Browser Fingerprinting
Element.getClientRects() - Web APIs | MDN

getClientRects fingerprinting

The most intersting fingerprinting vector I found on Tor Browser is getClientRects. Is strange that reading back from a canvas has been prevented but simply asking the browser javascript API how a specific DOM elements has been drawn on the screen has not been prevented or protected in any way.

getClientRects allows to get the exact pixel position and size of the box of a given DOM element. Depending on the resolution, font configuration and lots of other factors, the results of getClientRects are different, allowing for a very quick and easy fingerprinting vector, even better than the canvas fingerprinting that is fixed.

1 Like

Not only DOMRect readouts of HTML elements (text transformations, buttons, progress elements, …) itself are fingerprintable

but DOMRect also makes for example MathML Fingerprinting

Emoji Fingerprinting

ClientRects Fingerprinting - BrowserLeaks seems very severe.

  • Tor Browser in one Qubes-Whonix VM → Tor Browser in another Qubes-Whonix VM → Same fingerprint.
  • Tor Browser in one Qubes Debian VM → Tor Browser in another Qubes-Whonix VM → Same fingerprint.
  • Chromium in Qubes Debian VM vs Tor Browser in another Qubes-Whonix VM → Different fingerprint.
  • Chromium in Qubes Debian VM vs Firefox in same VM → Different fingerprint.
  • Different browser window size → Same fingerprint.
  • Tor Browser, different tabs → Same fingerprint.

Mozilla bug (no action for 2 years, so don’t hold your breath):

I note the CanvasBlocker addon randomizes those values:

CanvasBlocker randomizes the values (but doesn’t change those three values that are only 2 decimal places)

Also note this (old) research which suggests TBB fingerprinting defenses are inadequate and can be defeated, leading to clear differences between using TBB on Tails vs Whonix vs TBB in isolation for example:

Interesting part (my bold):

This matches the partial results obtained by @starius, and it is a good thing. Fingerprints of TBB and IceWeasel are not fully equal: there is 1 font more available in IceWeasel than in TBB. We can see a strong difference between fingerprints of TAILS, Whonix and TBB in different environments, and it is the bad thing. This means that an adversary can distinguish between TBB on different OS’es.

And in their conclusion:

Disabling JavaScript is a mandatory measure, at least you should disable fonts and most dangerous API using about:config. None of this was done neither in TAILS nor in TBB…

Disabling JS won’t help because there are CSS (sophisticated technology of styling elements, allowing even creating simple games without any line of JS code!), using which it is also possible to extract info about computer, but this will make tracking a bit harder because CSS allows to extract less informationthan JS and it is harder to send it to server. Even if we disable CSS, there will be other holes. So, I don’t think that disabling CSS will help you much.

There is a strong need in a standard on anonymized browser behaviour.

Disabling JS is incompatible with highly commercialised the Web of today. Business is business, if for making money (or not prosecuting and changing high ranked managers) it was necessary to collaborate with intelligence and law enforcement agencies, enlist itself into non secretor secret registry, track users, analyse their actions and spread malware, this would be done. Some sites were intentionally made non-functional without JS, some of them have a note that they won’t work without JS (but sometimes you can bypass it).

1 Like

Seems like a non-issue in Whonix.

For me, ClientRects Fingerprinting - BrowserLeaks shows the same Full Hash in,

  • a Qubes-Whonix-Workstation Tor Browser as well as in a
  • a Non-Qubes-Whonix-Workstation Tor Browser

on completely different hardware.

I don’t really want to publish my Full Hash and if this thing is real then I would discourage anyone else to abstain from this too as this could link your Full Hash to your unchangeable Tor Browser “pseudonym” (Full Hash). It would be similar to a “permanent IP address”. Running the Full Hash through a hashing function such as sha512 also would not help. Any adversary that knew the full hash could easily run it themselves through sha512. Comparing the secret securely without revealing it would require something innovative such as zero knowledge proofs but I am not aware of any application that allows to do that.

Excluded possibilities:

  • Test totally broken, showing every visitor the same value. Imagine that. We would worry about nothing. This is clearly not the case since the test shows different things for different browsers for example when viewing the test website through so it’s fingerprinting something.

Updated my previous post just now.

1 Like