Randomising vs. Blending In
gosuto-inzasheru opened this issue · 7 comments
Wouldn't it be a lot safer to be able to randomize your browser fingerprint every time when visiting a site? If I understand correctly this script tries to blend in with existing Tor visitors by mimicking their fingerprint but what about completely randomizing the data?
A fingerprint which is never the same twice in a row can hardly be called a fingerprint.
Right, so to recap (and this is just my current understanding), we could:
- Join the largest crowd of lookalike fingerprints (Tor Browser, iOS (?)). However, if there are differences between us and the crowd we are trying to join, those differences could be used to make us more identifiable.
- Randomize our fingerprint. Need to consider when to randomize (to avoid session linkability), perhaps only send realistic fingerprints (to avoid being conspicuous), ... If there are fingerprintable identifiers that we are failing to randomize, they could be used to link our random sessions and make us more identifiable.
- Block fingerprinting scripts from loading. Fingerprinting could be passive (server collects headers from a pixel) or active (script performs canvas fingerprinting, ... sends collected data back to server). Blocking scripts protects against active fingerprinting, which is where the majority of fingerprintable data comes from.
Chameleon started off by trying to blend in with Tor, but I now think altering your fingerprint alone (whether via blending in or randomizing) is not enough. While we would fool naive fingerprinters, we would only stand out more to better tracking implementations. See Chameleon's fingerprinting technique coverage table for what Chameleon does and doesn't do (and perhaps will not be able to do as a browser extension).
So now I am focusing on the third bullet point: dynamically identifying and blocking resources that appear to perform fingerprinting.
Here is a similar suggestion for Tor Browser, by the way: https://trac.torproject.org/projects/tor/ticket/11949
A research paper on randomization as a means of defense: https://research.microsoft.com/pubs/209989/tr1.pdf
Thanks for those links!
It seems like blocking known fingerprinting scripts is a good way to block common ad scripts, and a lousy way to protect from more sinister attackers.
So it certainly has value, but it probably shouldn't be the last line of defense.
On the topic of canvas fingerprinting, the tracker du jour, it could be useful to intercept some common canvas APIs and have them perform minor, essentially invisible pixel tweaks at random locations. Preferably pick APIs that are expensive compared to reading/settings a few pixels to minimize practical overhead. That ought to foil most fingerprinting techniques based on hashing canvas images.
Hi itsnotlupus!
Could you elaborate on your first statement please?
To clarify, when I wrote "dynamically identifying" fingerprinting resources above, I meant connecting fingerprinting-associated property accesses (navigator.plugins, ...) and techniques (canvas, font enumeration, ...) with script URLs that perform them. We could then apply a set of rules (let's say, "URL performed canvas image data extraction AND queried any navigator properties AND is a third party URL") to flag certain URLs as fingerprinters. Then, we would proceed to block fingerprinter domains from loading any resources.
Ah yes, that's better that I thought. I thought you were planning to operate a good old blacklist.
I guess the tricky part is to consistently identify which script is accessing API.
Tor masquerading has been removed in the master branch.