Browser fingerprinting overview?

Site Development
1

This was posted all the way back in 2023, and I don’t see anything apart from a short explanation in the Mullvad Browser section. Did it get dropped?

2

DRAFT: Browser Fingerprinting is a good overview and IMO would obsolete this

3

A fingerprinting script will get as much information as it thinks it needs, by testing metrics that add entropy. If a metric splits any users into smaller buckets, then it adds entropy. If it adds entropy, the distribution of users across the fingerprint affects each bucket differently, usually measured in bits. Enough bits (33 bits: 332 is 8.59 billion, which is more than the number the humans on the planet), and theoretically you are unique. This is not a perfect analogy: not everyone is online or using browsers, and we’re not identifying people, we’re identifying browser profiles (multiple devices, multiple browsers and profiles). But the point remains. Think of it as the less users in a bucket, the more they stand out because the bucket/crowd is smaller, so the higher the entropy and bits.

This shouldl be 2^33. Is this open to being corrected on GitHub?

4

GitHub - arkenfox/thorin · GitHub No idea if thorin is accepting PRs.

5

I haven’t finished reading, but this explanation seems very long and dense, which isn’t the style of PrivacyGuides. I’m not sure the layperson needs to understand entropy or zombie cookies in order to protect themselves. I’d still like to see a digestible guide on the Knowledge Base page.

6

Interesting. According to this document, disabling JavaScript is a great way to reduce the possible buckets you fall into.

7

After reading this, my key takeaways are:

  • Fingerprinting resistance (FPR) is an apt term, since it’s about reducing available information and making people less unique, rather than hiding everything and making everyone look identical.
  • FPR isn’t about stopping all data collection, since some will always be collected.
  • Restriction (reducing available information like Tor) is generally better than randomizing values (e.g. Brave), since even though they have similar effects, where restriction puts people into bucket of the same data values, and randomization puts people in the “randomized value” bucket, randomization is harder to implement and easier to see through.
  • FPR is often less about completely fooling scripts and more about forcing scripts to work harder and take more resources if they want a piece of data, at a cost to other things like speed and user experience.
  • Some information can be easily protected by restricting what data is made available, like fonts.
  • Some information is harder to protect, like screen resolution. Here, a browser dev can’t change your screen’s actual resolution, so they have to do their best to convincingly lie about it. Thus we see the screen for Tor browser being smaller than whatever the window size is. But this kind of thing isn’t as robust, and an advanced enough script could in theory get around this.
  • Some information is impossible to hide, like the browser or OS you’re using, or is not worth hiding since it’s necessarily implied by an piece of data that can’t be hidden, like your user agent, which is essentially a readout of your browser and OS.
  • A site could, in theory, track certain user behavior, and there’s nothing browser devs can do about that.
  • Solutions to specific data points are often imperfect.
  • Trying to hide too much information can worsen the user experience, like certain text not loading because of a missing font. Devs need to find a balance between protection and usability.
  • Certain actions by the user can compromise certain protections, like pressing F11 or fullscreening a video giving away your real screen resolution, or tweaking protection settings leading to you standing out, or granting one site permission with the same effect.
  • Disabling JavaScript will greatly reduce the available information a site can collect, but often at the cost of disabling most if not all of its functionality.
  • It’s no use to try to block just the bad scripts, since 1. That leads to an ever-expanding, ever-incomplete list of scripts to block, and 2. the bad scripts can just be buried in scripts the site can’t function without.
  • Test sites that claim to measure your FPR are useless.

All in all, you shouldn’t consider yourself untraceable just because you’re using the Tor browser, or Mullvad browser with a VPN, even if you do everything right and are careful not to compromise any FPR.

Is there anything important I missed or got wrong?

8

You could add protections to mouse movement and keyboard strokes, which could be used as a potential fingerprinting vector.

Your summary is generally correct