Should Tor Browser users expect Tor Browser to be resistant to commercial grade fingerprinting code and to what extent does the Tor Project use such libraries in testing Tor Browser’s resistance to fingerprinting?
For example, FingerprintJS advertises the commercial version of its library as having “Industry-leading accuracy”. I use the free version myself for testing Tor Browser’s fingerprint, but the commercial version has many more metrics. If they do not already, I would hope the Tor Project could license copy of this and/or similar libraries and use it for testing Tor Browser’s resistance to “industry-leading” fingerprinters. I have no affiliation with FingerprintJS btw.
My question was prompted by a suggestion by a user in a recent post here that Tor Browser ought to identify (& maybe block) known fingerprinting JavaScript code. Blocking such code may break some sites, but if Tor Browser was known & proven to be resistant to it (even commercial grade fingerprinting code) there would presumably be no need to block it
Tor Browser ought to identify (& maybe block) known fingerprinting
There are five steps fingerprint resistance can take
block known scripts
the best fingerprinting code is no code, but this is easily bypassed, a form of enumerating badness, is inherently reactive, and can undermine legitimate uses causing breakage or rejection (anti-fraud and bot-detection)
engineer solutions to remove the fingerprint problem
e.g. Firefox ships, for all users, the same same math library in audio across all platforms. This removes the audio entropy caused by floating points, and the only differences left are equivalency of platform architecture (which we can’t hide)
e.g. reduction in canvas entropy can be achieved by using software instead of hardware/GPU rendering
change existing and shape/reject new web standards
grow the crowd
the bigger the crowd hopefully the more users you share a fingerprint with to help hide your traffic in
reduceentropy buckets
blocking is a mostly meaningless band-aid that treats a symptom instead of solving the actual problem, which is what reducing buckets is for
Should Tor Browser users expect Tor Browser to be resistant to commercial grade fingerprinting
We always assume the worse case - commercial scripts are not that sophisticated (and they do get analyzed). Be aware that this is an ongoing process - scripts get better, new APIs get added, new PoCs are created, new defenses are put into place or improvements made in existing ones etc.
TB’s FPing protection is world-class, first-in-class - but the only way to know for sure how well we stack up is to do a real-world large-scale one-result-per-profile study using a robust and thorough script
this shows a few things, but do take into account that the limitations (small samples etc)
brave randomizing didn’t fool anyone
FPs are a snapshot in time, and metrics can be manipulated/weighted (doesn’t have to be server-side, but server-side hides their methods) to produce stable and consistent fingerprints
TB stood the test, everyone else failed (I’m summarizing)
Also feel free to read DRAFT: Browser Fingerprinting - it’s a draft but I wrote it over a year ago (its still awaiting some peer reviewing) - it’s aimed at a reading level of “no technical knowledge required”
Mitigating Browser Fingerprinting in Web Specifications was also drafted about the same time (which I was not aware of) and the relevant part here is the consensus that randomizing isn’t preferred - which echoes what I said. I went further and gave more reasons - and I also talked about benign vs adversarial values
If you have any other FPing questions - ping @PieroV
The first paper you cite is exactly what I was looking for @thorin. Real-world server-side testing with FingerprintJS Pro, which Tor Browser alone passed. It is good to know that these commercial libraries are not that good and do get analyzed in any case to keep up with new vulnerabilities.
I consider this more than adequately answers my question but will leave the topic open for a day or too in case anyone else wishes to comment. Many thanks.
No. DOMRect and a multitude of other ways to measure “things” is simply how shit is measured. This is the symptom.
What methods are available for measuring something depends on what that something is - but generally speaking there are too/so many that it’s implausible to try and successfully spoof them all so as to be consistent and you’ll end up with paradoxical/adversarial results) - and spoofing is only going to cause breakage/weirdness because you’re telling websites false information about layout/rendering/positioning etc
Instead we need to treat the actual problem(s) which is mostly subpixels (or devicePixelRatio: think of it as any system scaling and any zoom levels applied in the browser). We can’t hide subpixels - but we could maybe bucket it. From memory css pixels are 1/60ths and how device pixels relate to css pixels is complicated.
Outside of subpixels (which we can’t hide and they manifest everywhere) the issues lie elsewhere
e.g. for widgets (forms, buttons, checkboxes, radio options, etc) we can enforce the same fonts and “looks and feels” (per platform)
e.g. for fonts we can bundle some/all fonts and enforce the same font is used (per platform and language) - this way all characters/fonts used should always be the same
e.g. scrollbars could be overlay or non-overlay. Non-overlay dimensions can vary per OS version e.g. win10 vs win11) etrc
Each “thing” will have it own set of (multiple) causes - excluding devicePixelRatio. e.g. fonts and anti-aliasing/smoothing etc
We work on fixing the causes, not masking symptoms by breaking web standards and specs
once again
If you have any other FPing questions - ping @PieroV
