Opened 10 months ago

Last modified 10 months ago

#32861 new defect

"Fingerprint.js PRO" successfully fingerprints Tor Browser

Reported by: printerman22 Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-fingerprinting
Cc: tom Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Not affiliated with the site. Demo: https://fingerprintjs.com/demo.

When using Tor Browser 68.3.0esr on macOS Catalina, this site is capable of successfully fingerprinting me across multiple visits with a different identity each time.

Steps to reproduce:

  1. Visit https://fingerprintjs.com/demo in the Tor Browser.
  2. Click the "New Identity" button.
  3. Wait a little bit to avoid timing correlation.
  4. Revisit the website.

Screenshot of the fingerprinting: https://i.ibb.co/SvWsP4K/image.png.

A potential solution is taking some features from the "Trace" Firefox add-on (not affiliated): https://addons.mozilla.org/en-US/firefox/addon/absolutedouble-trace/. It prevented Fingerprint.js from successfully fingerprinting anything. Every time I created a "New Identity" in the Tor Browser and visited the website, it gave me a new identifier, with no record of my past visits.

When using the Firefox add-on "Canvas Blocker", Fingerprint.js was still capable of identifying me across identities.

Here are the Trace features I have enabled: https://i.ibb.co/BPCbWCk/image.png.

Here are the advanced Trace features I have enabled: https://i.ibb.co/8bmNYxL/image.png.

Child Tickets

Change History (5)

comment:1 Changed 10 months ago by Thorin

Cc: tom added
Keywords: tbb-fingerprinting added; fingperint fingerpriting removed

it's linking "previous" visits by the id hash it generates

so how does it compute the id hash?

  • view-source:https://fingerprintjs.com/dist/demo.js
  • https://unminify.com/ - unminify it = 31K+ lines

This looks like some sort of JS attack template (don't let the word "attack" alarm you): in other words it's checking everything it possibly can including the kitchen sink. The code is using very short variables, but it's easy enough to spot "normal/established" fingerprinting like screen measurements, font lists, canvas, glyphs, etc. And if each TB stable release per OS is not tinkered with, then the rest (the JS attack part) should be the same for everybody in that group (there will most likely be entropy between major OS versions, and probably between Linux distros).

Here's some basic tests/proofs:

  • change your reported inner window size: id changes
  • remember to reset this: flip dom.webaudio.enabled: id changes
  • ditto for flipping for all sorts of APIs on/off

TB users are advised to stay at default window size, and not to mess with settings. And here's the thing: it told me on my first visit that I've visited before, but I haven't (AFAICRemember, certainly not in the last 12 hours, or 3 days, and not with these TB builds). It did this to me twice: once on stable, once on alpha: both had different ids due to a different window size. In other words: yes there is entropy across stable TB versions (OS limitations such as available screen height -> inner window, OS fonts, OS widgets measurements and font, and so on), but there are still numbers of users per configuration (but... see note below)

It's so easy / trivial to get the id to change (which is why a JS attack template is not a good real world application for security checks, IMO), but the fact my TB's id by default (for me on Windows = probably popular: not so much you on Mac OS Catalina) tells me I had already visited (when I hadn't) tells me that TB's anti-fingerprinting is working to some degree. note: that said, we already know other areas that need work (see tbb-fingerprinting bugs), and I/we have PoCs for them (such as clientRect: e.g the domrect test at TZP combines this with your default font and widget).

Howver, this is a bit of a nightmare script to output and debug. Maybe tom or gk or someone else can "debug" it a little? But AFAIConcerned, this is wasted time and I have other yaks to shave :)

comment:2 in reply to:  description Changed 10 months ago by Thorin

Replying to printerman22:

A potential solution is taking some features from the "Trace" Firefox add-on

OOoh... almost forgot... please don't use non-TB provided extensions: they will increase your entropy and they are not vetted by the TB team (I know for a fact that double trace has a number of flaws: no, I won't elaborate)

This works because it is trivial to alter the id hash, and the extension is randomizing some results: cogito ergo sum: different hash. TB could also easily do this by simply randomizing something, like canvas: but this is not TB's design/spec (although personally, I think some areas could do with it when implemented)

comment:3 in reply to:  1 ; Changed 10 months ago by printerman22

And here's the thing: it told me on my first visit that I've visited before, but I haven't

This may have just been their "Demo visit history". Here is an example of what the "Demo visit history" looks like: https://i.ibb.co/8xscz7S/image.png. This is random placeholder data which is different from what the actual visit history is: https://i.ibb.co/SvWsP4K/image.png. If you click the button "show my visit history", it would most likely redirect to a list of nothing.

comment:4 in reply to:  3 Changed 10 months ago by Thorin

Replying to printerman22:

And here's the thing: it told me on my first visit that I've visited before, but I haven't

This may have just been their "Demo visit history"

Yes, I saw that, and only took notice of "your visit history". I totally ignored "demo visit history"

comment:5 Changed 10 months ago by tom

My experience:

First Load:  FzSw1dVTRpxk42FjoO9L

Showed 5 previous visits.

[New Identity]

ID:  FzSw1dVTRpxk42FjoO9L

Showed 6 previous visits (5 plus my last one.)

[Resize Window]

[New Identity]

ID:  3NoTPDBQoIdFazthz1Aq

No Visit History

My *guess* is that because we spoof your screen size to be the browser dimensions, which resizing changes, it is assigning a new Id based on that dimension (along with a new other things that are non-unique for Tor Browser users.)

The open question to me however is if their script was smarter and realized that they can't use the screen dimension as a uniqueness test and instead consider it as variable would they be able to fingerprint people uniquely? Or well?

Note: See TracTickets for help on using tickets.