[tor-commits] [tor-browser-spec/master] Updating the fingerprinting section

[mikeperry@xxxxxxxxxxxxxx]

commit 5578c09d4143b30b305204c0f0bd5f1eda4a377d
Author: Georg Koppen <gk@xxxxxxxxxxxxxx>
Date:   Tue May 5 10:45:50 2015 +0000

    Updating the fingerprinting section
---
 design-doc/design.xml |   49 +++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 49 insertions(+)

diff --git a/design-doc/design.xml b/design-doc/design.xml
index cf0d959..715e950 100644
--- a/design-doc/design.xml
+++ b/design-doc/design.xml
@@ -1581,6 +1581,55 @@ url="https://amiunique.org/";>Am I Unique</ulink>.
      </listitem>
    </orderedlist>
   </sect3>
+
+   <sect3 id="fingerprinting-defenses-general">
+    <title>General Fingerprinting Defenses</title>
+    <para>
+Without looking at a particular fingerprinting vector there are basically two
+strategies to thwart fingerprinting attacks in general:
+<orderedlist>
+  <listitem>
+    Making users uniform: This would render fingerprinting moot as it only works
+    if there are detectable differences between targets.
+  </listitem>
+  <listitem>
+    Giving randomized values back: This would bury the real device
+    characteristics within noise. That way a fingerprinter cannot be sure to
+    identify a user upon (re-)visit of a website which is rendering
+    fingerprinting ineffective.
+  </listitem>
+</orderedlist>
+Although there is some research <ulink url="http://research.microsoft.com/pubs/209989/tr1.pdf";>suggesting</ulink> the second approach
+we think the former is currently a better suited heuristic for Tor Browser
+for a couple of reasons:
+   <itemizedlist>
+     <listitem>
+       It might not be possible to randomize all fingerprintable characteristics.
+     </listitem>
+     <listitem>
+       It might not be easy to randomize values in a way that they are not
+       distinguishable from noise.
+     </listitem>
+     <listitem>
+       Randomizing involves performance costs. This is especially true if the
+       fingerprinting surface is large (like in a modern browser) and one needs
+       more elaborate randomizing strategies to make the result
+       indistinguishable from noise.
+     </listitem>
+     <listitem>
+       Randomizing itself might introduce a new fingerprinting vector as the
+       process of generating the values for the fingerprintable attributes
+       could be susceptible to timing side-channel attacks.
+     </listitem>
+  </itemizedlist>
+  We'll see in the next section that the idea of making users uniform does not
+  work either in the general way expressed above mainly due to usability issues.
+  However, we believe that it avoids a lot of the complications involved in
+  randomization even if just used as a guiding principle.
+    </para>
+  </sect3>
+
+
   <sect3 id="fingerprinting-defenses">
    <title>Fingerprinting Defenses in the Tor Browser</title>
    <para>



_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits