#11949: Randomize Tor Browser Fingerprint --------------------------------------+-------------------------- Reporter: mt2014 | Owner: tbb-team Type: enhancement | Status: closed Priority: Medium | Milestone: Component: Applications/Tor Browser | Version: Severity: Normal | Resolution: wontfix Keywords: tbb-firefox-patch | Actual Points: Parent ID: | Points: Reviewer: | Sponsor: --------------------------------------+--------------------------
Comment (by Thorin): Replying to [comment:7 gk]: > (Before we actually go that route we should have some hard data showing that randomizing is superior for our use-case) IMO, you don't **need** hard data - math alone can illustrate it perfectly :) You only need hard data to know how "bad" an existing metric is, and maybe experiments after. As long as the entropy is high enough, it's actually more effective IMO. The question/problem is that the anti-fingerprinting measure taken needs to be decided based on what is being protected: e.g it would be silly to randomize language/locale (too complex, not very user friendly, etc) or to randomize the UA/platform (because these are already obtainable other ways, breakage, the entropy is too small). But randomizing something like canvas is arguably better than returning a white canvas - it produces less breakage and removes the tell-tale white canvas hash (not that TB is trying to hide that it's TB). Generally speaking, spoofing to lower by using the most common value (or one value per platform) is the simplest fix, whereas randomizing is much more complex - and the implementation can lead to unintended leaks, information paradoxes, breakage etc. That said: tor project has always taken the lower entropy route, but I just want to point out that randomizing should be considered in some cases. Because non-random means a stable metric can always be used **against** you (even where no entropy exists: e.g. oh, a white canvas, no service for you then), whereas randomizing should completely ruin it - take for example the script at #32861 where any change to the window size caused a hash change (I'm not saying to randomize window sizes - just showing how that script becomes unreliable) It really depends on what is being protected and the pros/cons weight up (especially the maintenance and complexity), but imagine if canvas, audio, clientrects and screen (not inner) were always randomized - this would really wreck almost every script out there, and I'm all for that :) One area I think randomizing should be considered is in clientrects: all those high precision measurements which keep coming up in FP PoCs -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/11949#comment:8> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs