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.
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.
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 :)
Trac: Keywords: fingperint, fingerpriting deleted, tbb-fingerprinting added Cc: N/Ato tom
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)
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.
First Load: FzSw1dVTRpxk42FjoO9LShowed 5 previous visits.[New Identity]ID: FzSw1dVTRpxk42FjoO9LShowed 6 previous visits (5 plus my last one.)[Resize Window][New Identity]ID: 3NoTPDBQoIdFazthz1AqNo 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?
I'm wondering if my recent finding that I was looking for an issue about is related. I noticed that there is a mismatch between the HTTP headers user agent report and the JS attributes user agent, with the JS attributes user agent accurately reflecting the user's actual browser attributes. Most hardened browsers I know always make sure that these match, reasoning that it actually makes a user more identifiable. The discussions I was hoping to have here with someone more familiar with the Tor project than I are:
JS OS is spoofed as one of four: windows, linux, mac, android - this is way more compat friendly
HTTP headers spoof as one of two: windows, android
e.g. think about how this works when browsing in safest mode (no JS) - it reduces the passive FP
There is zero entropy here, as all users in each OS still look the same, and we can't hide the OS (there are too many differences that are unique per OS)
The spec is for them to match, but RFP (or resistFingerprinting) is all about lying and this thus breaking web standards in 100 or so metrics
Got it, thanks. I was a little surprised to see my actual platform in the JS user agent, it looks like I just got (un)lucky at that moment and thought there was a problem.
And yeah, I friggin' love lying about my fingerprints haha. It's why I was even checking. Well then. I'm gonna get down to doing some delicious delicious learning now that I'm here. Might as well try to contribute on some first contribution issues
if you can't trust me, can you trust Peter Snyder from Brave
tl;dr: they are using IP, and state to aid their "fingerprinting". It's also trivial to make it get a different hash (not to be confused with linking FPs on the backend), and the whole FPJS isn't that sophiticated. We already know what we need to work on.