Good News - Testing Tor Browser DispVMs Against New fingerprint.js Browser Fingerprinting

I heard about a new browser fingerprinting software in Techlore’s most recent Surveillance Report podcast. This software claims to be 99.5% accurate in tracking users, somehow keeping tracks of apps they have installed?

I’m not sure about the specifics, but they have a demo they can run on your browser (fingerprintjs.com/demo) which gives you a unique identifier which can be used to track your across sites and even browsers.

I decided to test whether the identifier provided in the demo could track me across various instances of a Tor Browser (AnonDist) running off a whonix-ws-15-dvm template.

I first began testing a single instance of the browser DispVM.

Test 1: I went to the above link to the demo and disabled HTML canvassing as soon as the icon popped up in the address bar, and I got this identifier (scrambled for this post because why not): UH0L8FDA6TQNVA3PPBV7

Test 2: After using Tor Browser’s “New Identity” feature, and visiting the demo site, and disabling HTML canvassing as soon as the icon popped up, I got a new identifier: GS2H8RFCFLA1JGSMVJEV, meaning a website implementing this fingerprinting software would not be able to use the identifiers it provided to correlate my “previous identity” visit to the site with my “new identity” visit (assuming finerprint.js is not lying about the efficacy of their demo to Tor exit node).

Test 3: I then tried to see how effective using the “New Circuit” or simply refreshing the webpage would be. These are not effective. I was given the same identifier 9JBEFLKLZZ1FQYI3YSWM after both using the “New Circuit” feature and refreshing the webpage (I wouldn’t expect simply refreshing to have an effect).

Test 4: I then tried to see how effective the software would be with HTML canvassing enabled. Even with canvassing enabled, the software did not provide the same identifier across “New Identities,” leaving this feature as the most effective feature to prevent tracking in a single instance of a Whonix VM. There was no change regarding a “New Circuit” or refreshing the page (the identifier was the same, meaning I was still tracked).

Side Note: the software listed by browser as a Firefox on Windows 10 (LOL). I’m not sure if it’s the way my laptop screen renders images or some peculiar trait of Tor or Whonix, but congratulations to whoever managed to convince this company I’m using Windows.

Bonus Test: I fired up another Tor Browser (AnonDist) from the whonix-ws-15-dvm template and visited the demo website leaving almost no time gap between each instance. I first disabled HTML canvassing, and got different identifiers in each instance of the Browser (really, OS). I then gave each browser a “New Identity” and enabled HTML canvassing, and I still got different identifiers in each browser instance.

Conclusions: it seems that fingerprint.js has a difficult time tracking Tor Browsers which are part of a Whonix VM. I would really love to have some people test this on other Tor Browsers running in Qubes, other GNU/Linux distros, as well as Mac and Windows.

3 Likes

I expect all Whonix installs (unless modified) to return the exact same ID.

What they are doing is pretty simple:

  • there is a thing called URL scheme, where software installed on your
    computer can register a ‘protocol’. So instead of https:// you would see
    a link that starts with i.e. skype:// and your browser knows it should
    call Skype with that URL

  • in JavaScript one can enumerate the available URL schemes, hence find
    out which software is installed

  • they know define I think it was 20 common software URLs and check for
    their presence, with each software being 1 bit in the ID. So if Skype is
    installed the respective bit is 1, otherwise it’s zero.

Knowing the above I don’t think with 20 bits of information there is
much of an individual fingerprint there.

  1. I would always recommend to run NoScript and only selectively allow
    scripts from domains where you absolutely have to… this step alone
    already kills the entire scheme described above

  2. Even with JavaScript enabled, I would expect the TorBrowser to
    already defend against the above. And if it doesn’t yet this week it
    will for sure do so next week :wink:

Reminds me of the favicon tracking that was recently discovered since they both track what app/site-specific content is available in the user’s browser.

I wonder if Tor Browser does well against this as well, since if you visit a certain set of pages with a certain set of favicons, you should be trackable (especially if using default settings with JavaScript enabled).

For another reference point:
A standard Debian Firefox with NoScript and CanvasDefender -
As @Sven says, NoScript blocks completely.
Allowing Scripts, using the same Canvas, through Tor, tends to give (on limited testing) the
same fingerprint between qubes.
Allowing Scripts, using a different Canvas, through Tor, tends not to give (on limited testing) the
same fingerprint between qubes.

“Tends” here means 3-4 out of 5.

It seems that their claim is wildly over optimistic.

As always, you should consider why you are concerned about
fingerprinting.

Re-reading the original post by @qubes-kernel-5.8 I was struck by this:

This doesn’t look like “Good News” for Whonix in Qubes.

But, as I said, you should consider why you are concerned about
fingerprinting.

I didn’t have to mess with canvas or anything. I simply fired up whonix-ws-15-dvm>Tor Browser as it came with my Qubes 4 install and got a new fingerprint I had never gotten before, then clicked new identity and got a new fingerprint.
It seems that it also reports I am on Windows 10 even though I am on whonix.

I’m surprised you think this is a good thing in Whonix: does every instance have a
distinct fingerprint?

1 Like

It would be quite weird if whonix changed Tor Browser’s anti-fingerprinting strategy from uniformity to randomness. If this is true, it may be a real concern. Quoting from Tor Browser’s design document:

Randomization is not a shortcut

While many end-user configuration details that the browser currently exposes may be safely replaced by false information, randomization of these details must be just as exhaustive as an approach that seeks to make these behaviors uniform. When confronting either strategy, the adversary can still make use of any details which have not been altered to be either sufficiently uniform or sufficiently random.

Furthermore, the randomization approach seems to break down when it is applied to deeper issues where underlying system functionality is directly exposed. In particular, it is not clear how to randomize the capabilities of hardware attached to a computer in such a way that it either convincingly behaves like other hardware, or such that the exact properties of the hardware that vary from user to user are sufficiently randomized. Similarly, truly concealing operating system version differences through randomization may require multiple reimplementations of the underlying operating system functionality to ensure that every operating system version is covered by the range of possible behaviors.

1 Like

There are two options that are good for privacy: either every whonix instance in the entire world (no matter the whonix version) gives the exact same fingerprint, or every session has a completely different one. The latter is only slightly inferior, as long as you click “new identity” fairly often.

@Narvey perhaps you can create a topic about this on the whonix forum? so folks there can also know about this? (but perhaps first search on their wiki or forum to see if it hasn’t been addressed first.

1 Like

I’m OK with the way it works now.

If: every instance has a unique fingerprint, then when you combine that with data from other layers of the OSI model, every instance MUST, (it follows logically), be easier to identify - than the former situation wherein every instance does not have a unique fingerprint.

I think however, that conversation may evolve into the depth of web browsers and applications etc and the data that is accessible by enabling an application to run unsigned code, and then there’s the other layers, network security, timing attacks, etc etc etc.

But anyhow: I’m with @unman.

My definition of Anonymity is this (in-case it helps anybody): NUI
Not Uniquely Identifiable.