[tbb-bugs] #11949 [Applications/Tor Browser]: Randomize Tor Browser Fingerprint

[Tor Bug Tracker & Wiki]

#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