Updates to fingerprinting section of TBB design doc.
Mike Perry

Mike Perry commited on 2014-11-07 02:14:06
Zeige 1 geänderte Dateien mit 130 Einfügungen und 105 Löschungen.

... ...
@@ -1,5 +1,5 @@
1 1
 <?xml version="1.0" encoding="UTF-8"?>
2
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>The Design and Implementation of the Tor Browser [DRAFT]</title><meta name="generator" content="DocBook XSL Stylesheets V1.78.1" /></head><body><div class="article"><div class="titlepage"><div><div><h2 class="title"><a id="design"></a>The Design and Implementation of the Tor Browser [DRAFT]</h2></div><div><div class="author"><h3 class="author"><span class="firstname">Mike</span> <span class="surname">Perry</span></h3><div class="affiliation"><div class="address"><p><code class="email">&lt;<a class="email" href="mailto:mikeperry#torproject org">mikeperry#torproject org</a>&gt;</code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Erinn</span> <span class="surname">Clark</span></h3><div class="affiliation"><div class="address"><p><code class="email">&lt;<a class="email" href="mailto:erinn#torproject org">erinn#torproject org</a>&gt;</code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Steven</span> <span class="surname">Murdoch</span></h3><div class="affiliation"><div class="address"><p><code class="email">&lt;<a class="email" href="mailto:sjmurdoch#torproject org">sjmurdoch#torproject org</a>&gt;</code></p></div></div></div></div><div><p class="pubdate">November 6th, 2014</p></div></div><hr /></div><div class="toc"><p><strong>Table of Contents</strong></p><dl class="toc"><dt><span class="sect1"><a href="#idp59241696">1. Introduction</a></span></dt><dd><dl><dt><span class="sect2"><a href="#components">1.1. Browser Component Overview</a></span></dt></dl></dd><dt><span class="sect1"><a href="#DesignRequirements">2. Design Requirements and Philosophy</a></span></dt><dd><dl><dt><span class="sect2"><a href="#security">2.1. Security Requirements</a></span></dt><dt><span class="sect2"><a href="#privacy">2.2. Privacy Requirements</a></span></dt><dt><span class="sect2"><a href="#philosophy">2.3. Philosophy</a></span></dt></dl></dd><dt><span class="sect1"><a href="#adversary">3. Adversary Model</a></span></dt><dd><dl><dt><span class="sect2"><a href="#adversary-goals">3.1. Adversary Goals</a></span></dt><dt><span class="sect2"><a href="#adversary-positioning">3.2. Adversary Capabilities - Positioning</a></span></dt><dt><span class="sect2"><a href="#attacks">3.3. Adversary Capabilities - Attacks</a></span></dt></dl></dd><dt><span class="sect1"><a href="#Implementation">4. Implementation</a></span></dt><dd><dl><dt><span class="sect2"><a href="#proxy-obedience">4.1. Proxy Obedience</a></span></dt><dt><span class="sect2"><a href="#state-separation">4.2. State Separation</a></span></dt><dt><span class="sect2"><a href="#disk-avoidance">4.3. Disk Avoidance</a></span></dt><dt><span class="sect2"><a href="#app-data-isolation">4.4. Application Data Isolation</a></span></dt><dt><span class="sect2"><a href="#identifier-linkability">4.5. Cross-Origin Identifier Unlinkability</a></span></dt><dt><span class="sect2"><a href="#fingerprinting-linkability">4.6. Cross-Origin Fingerprinting Unlinkability</a></span></dt><dt><span class="sect2"><a href="#new-identity">4.7. Long-Term Unlinkability via "New Identity" button</a></span></dt><dt><span class="sect2"><a href="#other-security">4.8. Other Security Measures</a></span></dt></dl></dd><dt><span class="sect1"><a href="#BuildSecurity">5. Build Security and Package Integrity</a></span></dt><dd><dl><dt><span class="sect2"><a href="#idp60746000">5.1. Achieving Binary Reproducibility</a></span></dt><dt><span class="sect2"><a href="#idp60781056">5.2. Package Signatures and Verification</a></span></dt><dt><span class="sect2"><a href="#idp60784992">5.3. Anonymous Verification</a></span></dt></dl></dd><dt><span class="appendix"><a href="#Transparency">A. Towards Transparency in Navigation Tracking</a></span></dt><dd><dl><dt><span class="sect1"><a href="#deprecate">A.1. Deprecation Wishlist</a></span></dt><dt><span class="sect1"><a href="#idp60816992">A.2. Promising Standards</a></span></dt></dl></dd></dl></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="idp59241696"></a>1. Introduction</h2></div></div></div><p>
2
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>The Design and Implementation of the Tor Browser [DRAFT]</title><meta name="generator" content="DocBook XSL Stylesheets V1.78.1" /></head><body><div class="article"><div class="titlepage"><div><div><h2 class="title"><a id="design"></a>The Design and Implementation of the Tor Browser [DRAFT]</h2></div><div><div class="author"><h3 class="author"><span class="firstname">Mike</span> <span class="surname">Perry</span></h3><div class="affiliation"><div class="address"><p><code class="email">&lt;<a class="email" href="mailto:mikeperry#torproject org">mikeperry#torproject org</a>&gt;</code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Erinn</span> <span class="surname">Clark</span></h3><div class="affiliation"><div class="address"><p><code class="email">&lt;<a class="email" href="mailto:erinn#torproject org">erinn#torproject org</a>&gt;</code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Steven</span> <span class="surname">Murdoch</span></h3><div class="affiliation"><div class="address"><p><code class="email">&lt;<a class="email" href="mailto:sjmurdoch#torproject org">sjmurdoch#torproject org</a>&gt;</code></p></div></div></div></div><div><p class="pubdate">November 6th, 2014</p></div></div><hr /></div><div class="toc"><p><strong>Table of Contents</strong></p><dl class="toc"><dt><span class="sect1"><a href="#idp42746080">1. Introduction</a></span></dt><dd><dl><dt><span class="sect2"><a href="#components">1.1. Browser Component Overview</a></span></dt></dl></dd><dt><span class="sect1"><a href="#DesignRequirements">2. Design Requirements and Philosophy</a></span></dt><dd><dl><dt><span class="sect2"><a href="#security">2.1. Security Requirements</a></span></dt><dt><span class="sect2"><a href="#privacy">2.2. Privacy Requirements</a></span></dt><dt><span class="sect2"><a href="#philosophy">2.3. Philosophy</a></span></dt></dl></dd><dt><span class="sect1"><a href="#adversary">3. Adversary Model</a></span></dt><dd><dl><dt><span class="sect2"><a href="#adversary-goals">3.1. Adversary Goals</a></span></dt><dt><span class="sect2"><a href="#adversary-positioning">3.2. Adversary Capabilities - Positioning</a></span></dt><dt><span class="sect2"><a href="#attacks">3.3. Adversary Capabilities - Attacks</a></span></dt></dl></dd><dt><span class="sect1"><a href="#Implementation">4. Implementation</a></span></dt><dd><dl><dt><span class="sect2"><a href="#proxy-obedience">4.1. Proxy Obedience</a></span></dt><dt><span class="sect2"><a href="#state-separation">4.2. State Separation</a></span></dt><dt><span class="sect2"><a href="#disk-avoidance">4.3. Disk Avoidance</a></span></dt><dt><span class="sect2"><a href="#app-data-isolation">4.4. Application Data Isolation</a></span></dt><dt><span class="sect2"><a href="#identifier-linkability">4.5. Cross-Origin Identifier Unlinkability</a></span></dt><dt><span class="sect2"><a href="#fingerprinting-linkability">4.6. Cross-Origin Fingerprinting Unlinkability</a></span></dt><dt><span class="sect2"><a href="#new-identity">4.7. Long-Term Unlinkability via "New Identity" button</a></span></dt><dt><span class="sect2"><a href="#other-security">4.8. Other Security Measures</a></span></dt></dl></dd><dt><span class="sect1"><a href="#BuildSecurity">5. Build Security and Package Integrity</a></span></dt><dd><dl><dt><span class="sect2"><a href="#idp45273472">5.1. Achieving Binary Reproducibility</a></span></dt><dt><span class="sect2"><a href="#idp45308512">5.2. Package Signatures and Verification</a></span></dt><dt><span class="sect2"><a href="#idp45312448">5.3. Anonymous Verification</a></span></dt></dl></dd><dt><span class="appendix"><a href="#Transparency">A. Towards Transparency in Navigation Tracking</a></span></dt><dd><dl><dt><span class="sect1"><a href="#deprecate">A.1. Deprecation Wishlist</a></span></dt><dt><span class="sect1"><a href="#idp45344896">A.2. Promising Standards</a></span></dt></dl></dd></dl></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="idp42746080"></a>1. Introduction</h2></div></div></div><p>
3 3
 
4 4
 This document describes the <a class="link" href="#adversary" title="3. Adversary Model">adversary model</a>,
5 5
 <a class="link" href="#DesignRequirements" title="2. Design Requirements and Philosophy">design requirements</a>, and <a class="link" href="#Implementation" title="4. Implementation">implementation</a>  of the Tor Browser. It is current as of Tor Browser
... ...
@@ -654,13 +654,13 @@ system-wide extensions (through the use of
654 654
 disabled, which prevents Flash cookies from leaking from a pre-existing Flash
655 655
 directory.
656 656
 
657
-   </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="disk-avoidance"></a>4.3. Disk Avoidance</h3></div></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp60523824"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote">
657
+   </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="disk-avoidance"></a>4.3. Disk Avoidance</h3></div></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp45049760"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote">
658 658
 
659 659
 The User Agent MUST (at user option) prevent all disk records of browser activity.
660 660
 The user should be able to optionally enable URL history and other history
661 661
 features if they so desire. 
662 662
 
663
-    </blockquote></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp60525184"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote">
663
+    </blockquote></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp45051120"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote">
664 664
 
665 665
 We achieve this goal through several mechanisms. First, we set the Firefox
666 666
 Private Browsing preference
... ...
@@ -734,7 +734,7 @@ the url bar origin for which browser state exists, possibly with a
734 734
 context-menu option to drill down into specific types of state or permissions.
735 735
 An example of this simplification can be seen in Figure 1.
736 736
 
737
-   </p><div class="figure"><a id="idp60547888"></a><p class="title"><strong>Figure 1. Improving the Privacy UI</strong></p><div class="figure-contents"><div class="mediaobject" align="center"><img src="NewCookieManager.png" align="middle" alt="Improving the Privacy UI" /></div><div class="caption"><p></p>
737
+   </p><div class="figure"><a id="idp45073824"></a><p class="title"><strong>Figure 1. Improving the Privacy UI</strong></p><div class="figure-contents"><div class="mediaobject" align="center"><img src="NewCookieManager.png" align="middle" alt="Improving the Privacy UI" /></div><div class="caption"><p></p>
738 738
 
739 739
 This example UI is a mock-up of how isolating identifiers to the URL bar
740 740
 origin can simplify the privacy UI for all data - not just cookies. Once
... ...
@@ -954,39 +954,50 @@ determine how many bits of identifying information each attribute provided.
954 954
 
955 955
    </p><p>
956 956
 
957
-Because fingerprinting is a problem that potentially touches every aspect of
958
-the browser, we reduce the efforts for fingerprinting resistance by only
959
-concerning ourselves with reducing the fingerprintable differences
960
-<span class="emphasis"><em>among</em></span> Tor Browser users. We do not believe it is possible
961
-to solve cross-browser fingerprinting issues.
957
+Unfortunately, there are limitations to the way the Panopticlick study was
958
+conducted. Because the Panopticlick dataset is based on browser data spanning
959
+a number of widely deployed browsers over a number of years, any
960
+fingerprinting defenses attempted by browsers today are very likely to cause
961
+Panopticlick to report an <span class="emphasis"><em>increase</em></span> in fingerprintability
962
+and entropy, because those defenses will stand out in sharp contrast to
963
+historical data. Moreover, because fingerprinting is a problem that
964
+potentially touches every aspect of the browser, we do not believe it is
965
+possible to solve cross-browser fingerprinting issues. We reduce the efforts
966
+for fingerprinting resistance by only concerning ourselves with reducing the
967
+fingerprintable differences <span class="emphasis"><em>among</em></span> Tor Browser users. 
962 968
 
963 969
    </p><p>
964 970
 
965
-Unfortunately, the unsolvable nature of the cross-browser fingerprinting
966
-problem means that the Panopticlick test website itself is not useful for
967
-evaluating the actual effectiveness of our defenses, or the fingerprinting
968
-defenses of any other web browser. Because the Panopticlick dataset is based
969
-on browser data spanning a number of widely deployed browsers over a number of
970
-years, any fingerprinting defenses attempted by browsers today are very likely
971
-to cause Panopticlick to report an <span class="emphasis"><em>increase</em></span> in
972
-fingerprintability and entropy, because those defenses will stand out in sharp
973
-contrast to historical data. We have been <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/6119" target="_top">working to convince
974
-the EFF</a> that it is worthwhile to release the source code to
975
-Panopticlick to allow us to run our own version for this reason.
971
+The unsolvable nature of the cross-browser fingerprinting problem also means
972
+that the Panopticlick test website itself is not useful for evaluating the
973
+actual effectiveness of our defenses, or the fingerprinting defenses of any
974
+other web browser. We are interested in deploying an improved version of
975
+Panopticlick that measures entropy and variance only among a specific user
976
+agent population, but until then, intuition serves as a decent guide.
977
+Essentially, anything that reveals custom user configuration, third party
978
+software, highly variable hardware details, and external devices attached to
979
+the users computer is likely to more fingerprintable than things like
980
+operating system type and even processor speed.
976 981
 
977 982
    </p><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="fingerprinting-defenses"></a>Fingerprinting defenses in the Tor Browser</h4></div></div></div><p>
978 983
 
979 984
 The following defenses are listed roughly in order of most severe
980
-fingerprinting threat first, though we are desperately in need of updated
981
-measurements to determine this with certainty. Where our actual implementation
982
-differs from an ideal solution, we separately describe our <span class="command"><strong>Design
983
-Goal</strong></span> and our <span class="command"><strong>Implementation Status</strong></span>.
985
+fingerprinting threat first. This ordering based on the above intuition that
986
+user configurable aspects of the computer are the most severe source of
987
+fingerprintability, though we are in need of updated measurements to determine
988
+this with certainty.
989
+
990
+   </p><p>
991
+Where our actual implementation differs from
992
+an ideal solution, we separately describe our <span class="command"><strong>Design Goal</strong></span>
993
+and our <span class="command"><strong>Implementation Status</strong></span>.
984 994
 
985 995
    </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem">Plugins
986 996
      <p>
987 997
 
988
-Plugins add to fingerprinting risk via two main vectors: their mere presence in
989
-window.navigator.plugins, as well as their internal functionality.
998
+Plugins add to fingerprinting risk via two main vectors: their mere presence
999
+in window.navigator.plugins (because they are optional, end-user installed
1000
+third party software), as well as their internal functionality.
990 1001
 
991 1002
      </p><p><span class="command"><strong>Design Goal:</strong></span>
992 1003
 
... ...
@@ -1014,11 +1025,9 @@ leaking plugin installation information.
1014 1025
      </p></li><li class="listitem">HTML5 Canvas Image Extraction
1015 1026
      <p>
1016 1027
 
1017
-The <a class="ulink" href="https://developer.mozilla.org/en-US/docs/HTML/Canvas" target="_top">HTML5
1018
-Canvas</a> is a feature that has been added to major browsers after the
1019
-EFF developed their Panopticlick study. After plugins and plugin-provided
1020
-information, we believe that the HTML5 Canvas is the single largest
1021
-fingerprinting threat browsers face today. <a class="ulink" href="http://www.w2spconf.com/2012/papers/w2sp12-final4.pdf" target="_top">Initial
1028
+After plugins and plugin-provided information, we believe that the <a class="ulink" href="https://developer.mozilla.org/en-US/docs/HTML/Canvas" target="_top">HTML5
1029
+Canvas</a> is the single largest fingerprinting threat browsers face
1030
+today. <a class="ulink" href="http://www.w2spconf.com/2012/papers/w2sp12-final4.pdf" target="_top">Initial
1022 1031
 studies</a> show that the Canvas can provide an easy-access fingerprinting
1023 1032
 target: The adversary simply renders WebGL, font, and named color data to a
1024 1033
 Canvas element, extracts the image buffer, and computes a hash of that image
... ...
@@ -1030,8 +1039,9 @@ image can be used almost identically to a tracking cookie by the web server.
1030 1039
      </p><p>
1031 1040
 
1032 1041
 In some sense, the canvas can be seen as the union of many other
1033
-fingerprinting vectors. If WebGL were normalized through software rendering,
1034
-and the browser shipped a fixed collection of fonts, it might not be necessary
1042
+fingerprinting vectors. If WebGL is normalized through software rendering,
1043
+system colors were standardized, and the browser shipped a fixed collection of
1044
+fonts (see later points in this list), it might not be necessary
1035 1045
 to create a canvas permission. However, until then, to reduce the threat from
1036 1046
 this vector, we have patched Firefox to <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/3b53f525cfb68880e676e64f13cbc0b928ae3ecf" target="_top">prompt
1037 1047
 before returning valid image data</a> to the Canvas APIs, and for <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/fb9f463fe3a69499d6896c217786bafdf0cda62f" target="_top">access
... ...
@@ -1047,7 +1057,13 @@ In Firefox, by using either WebSockets or XHR, it is possible for remote
1047 1057
 content to <a class="ulink" href="http://www.andlabs.org/tools/jsrecon.html" target="_top">enumerate
1048 1058
 the list of TCP ports open on 127.0.0.1</a>. In other browsers, this can
1049 1059
 be accomplished by DOM events on image or script tags. This open vs filtered
1050
-vs closed port list can provide a very unique fingerprint of a machine.
1060
+vs closed port list can provide a very unique fingerprint of a machine,
1061
+because it essentially enables the detection of many different popular third
1062
+party applications and optional system services (Skype, Bitcoin, Bittorrent
1063
+and other P2P software, SSH ports, SMB and related LAN services, CUPS and
1064
+printer daemon config ports, mail servers, and so on). It is also possible to
1065
+determine when ports are closed versus filtered/blocked (and thus probe
1066
+custom firewall configuration).
1051 1067
 
1052 1068
      </p><p>In Tor Browser, we prevent access to
1053 1069
 127.0.0.1/localhost by ensuring that even these requests are still sent by
... ...
@@ -1055,7 +1071,19 @@ Firefox to our SOCKS proxy (ie we set
1055 1071
 <span class="command"><strong>network.proxy.no_proxies_on</strong></span> to the empty string). The local
1056 1072
 Tor client then rejects them, since it is configured to proxy for internal IP
1057 1073
 addresses by default.
1058
-     </p></li><li class="listitem">USB Device ID enumeration
1074
+     </p></li><li class="listitem">Invasive Authentication Mechanisms (NTLM and SPNEGO)
1075
+     <p>
1076
+
1077
+Both NTLM and SPNEGO authentication mechanisms can leak the hostname, and in
1078
+some cases the current username. The only reason why these aren't a more
1079
+serious problem is that they typically involve user interaction, and likely
1080
+aren't an attractive vector for this reason. However, because it is not clear
1081
+if certain carefully-crafted error conditions in these protocols could cause
1082
+them to reveal machine information and still fail silently prior to the
1083
+password prompt, these authentication mechanisms should either be disabled, or
1084
+placed behind a site permission before their use. We simply disable them.
1085
+
1086
+     </p></li><li class="listitem">USB Device ID Enumeration
1059 1087
      <p>
1060 1088
 
1061 1089
 The <a class="ulink" href="https://developer.mozilla.org/en-US/docs/Web/Guide/API/Gamepad" target="_top">GamePad
... ...
@@ -1066,38 +1094,6 @@ should be behind a site permission in Private Browsing Modes, or should present
1066 1094
 controller type (perhaps a two button controller that can be mapped to the keyboard) in all cases.
1067 1095
 We simply disable it via the pref <span class="command"><strong>dom.gamepad.enabled</strong></span>.
1068 1096
 
1069
-     </p></li><li class="listitem">Invasive Authentication Mechanisms (NTLM and SPNEGO)
1070
-     <p>
1071
-Both NTLM and SPNEGO authentication mechanisms can leak the hostname, and in
1072
-some cases the machine username. These authentication mechanisms should either
1073
-be disabled, or placed behind a site permission before their use. We simply
1074
-disable them.
1075
-     </p></li><li class="listitem">WebGL
1076
-     <p>
1077
-
1078
-WebGL is fingerprintable both through information that is exposed about the
1079
-underlying driver and optimizations, as well as through performance
1080
-fingerprinting.
1081
-
1082
-     </p><p>
1083
-
1084
-Because of the large amount of potential fingerprinting vectors and the <a class="ulink" href="http://www.contextis.com/resources/blog/webgl/" target="_top">previously unexposed
1085
-vulnerability surface</a>, we deploy a similar strategy against WebGL as
1086
-for plugins. First, WebGL Canvases have click-to-play placeholders (provided
1087
-by NoScript), and do not run until authorized by the user. Second, we
1088
-obfuscate driver information by setting the Firefox preferences
1089
-<span class="command"><strong>webgl.disable-extensions</strong></span> and
1090
-<span class="command"><strong>webgl.min_capability_mode</strong></span>, which reduce the information
1091
-provided by the following WebGL API calls: <span class="command"><strong>getParameter()</strong></span>,
1092
-<span class="command"><strong>getSupportedExtensions()</strong></span>, and
1093
-<span class="command"><strong>getExtension()</strong></span>.
1094
-
1095
-     </p><p>
1096
-
1097
-Another option for WebGL might be to use software-only rendering, using a
1098
-library such as <a class="ulink" href="http://www.mesa3d.org/" target="_top">Mesa</a>. The use of
1099
-such a library would avoid hardware-specific rendering differences.
1100
-
1101 1097
      </p></li><li class="listitem">Fonts
1102 1098
      <p>
1103 1099
 
... ...
@@ -1106,7 +1102,8 @@ they are provided as an enumerable list in filesystem order, via either the
1106 1102
 Flash or Java plugins. However, it is still possible to use CSS and/or
1107 1103
 Javascript to query for the existence of specific fonts. With a large enough
1108 1104
 pre-built list to query, a large amount of fingerprintable information may
1109
-still be available.
1105
+still be available, especially given that additional fonts often end up
1106
+installed by third party software and for multilingual support.
1110 1107
 
1111 1108
      </p><p><span class="command"><strong>Design Goal:</strong></span> The sure-fire way to address font
1112 1109
 linkability is to ship the browser with a font for every language, typeface,
... ...
@@ -1143,13 +1140,16 @@ To improve rendering, we exempt remote <a class="ulink" href="https://developer.
1143 1140
 fonts</a> from these counts, and if a font-family CSS rule lists a remote
1144 1141
 font (in any order), we use that font instead of any of the named local fonts.
1145 1142
 
1146
-     </p></li><li class="listitem">Monitor and OS Desktop resolution
1143
+     </p></li><li class="listitem">Monitor and OS Desktop Resolution
1147 1144
      <p>
1148 1145
 
1149 1146
 Both CSS and Javascript have access to a lot of information about the screen
1150 1147
 resolution, usable desktop size, OS widget size, toolbar size, title bar size,
1151 1148
 and OS desktop widget sizing information that are not at all relevant to
1152
-rendering and serve only to provide information for fingerprinting.
1149
+rendering and serve only to provide information for fingerprinting. Since many
1150
+aspects of desktop widget positioning and size are user configurable, these
1151
+properties yield customized information about the computer, even beyond the
1152
+monitor size.
1153 1153
 
1154 1154
      </p><p><span class="command"><strong>Design Goal:</strong></span>
1155 1155
 
... ...
@@ -1190,7 +1190,7 @@ Beyond simple resolution information, a large amount of so-called "Media"
1190 1190
 information is also exported to content. Even without Javascript, CSS has
1191 1191
 access to a lot of information about the device orientation, system theme
1192 1192
 colors, and other desktop features that are not at all relevant to rendering
1193
-and serve only to provide information for fingerprinting. Most of this
1193
+and also user configurable. Most of this
1194 1194
 information comes from <a class="ulink" href="https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Media_queries" target="_top">CSS
1195 1195
 Media Queries</a>, but Mozilla has exposed <a class="ulink" href="https://developer.mozilla.org/en-US/docs/Web/CSS/color_value#System_Colors" target="_top">several
1196 1196
 user and OS theme defined color values</a> to CSS as well.
... ...
@@ -1210,6 +1210,32 @@ detection of font smoothing on OSX</a>. We also always
1210 1210
 <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/09561f0e5452305b9efcb4e6169c613c8db33246" target="_top">report
1211 1211
 landscape-primary</a> for the screen orientation.
1212 1212
 
1213
+     </p></li><li class="listitem">WebGL
1214
+     <p>
1215
+
1216
+WebGL is fingerprintable both through information that is exposed about the
1217
+underlying driver and optimizations, as well as through performance
1218
+fingerprinting.
1219
+
1220
+     </p><p>
1221
+
1222
+Because of the large amount of potential fingerprinting vectors and the <a class="ulink" href="http://www.contextis.com/resources/blog/webgl/" target="_top">previously unexposed
1223
+vulnerability surface</a>, we deploy a similar strategy against WebGL as
1224
+for plugins. First, WebGL Canvases have click-to-play placeholders (provided
1225
+by NoScript), and do not run until authorized by the user. Second, we
1226
+obfuscate driver information by setting the Firefox preferences
1227
+<span class="command"><strong>webgl.disable-extensions</strong></span> and
1228
+<span class="command"><strong>webgl.min_capability_mode</strong></span>, which reduce the information
1229
+provided by the following WebGL API calls: <span class="command"><strong>getParameter()</strong></span>,
1230
+<span class="command"><strong>getSupportedExtensions()</strong></span>, and
1231
+<span class="command"><strong>getExtension()</strong></span>.
1232
+
1233
+     </p><p>
1234
+
1235
+Another option for WebGL might be to use software-only rendering, using a
1236
+library such as <a class="ulink" href="http://www.mesa3d.org/" target="_top">Mesa</a>. The use of
1237
+such a library would avoid hardware-specific rendering differences.
1238
+
1213 1239
      </p></li><li class="listitem">User Agent and HTTP Headers
1214 1240
      <p><span class="command"><strong>Design Goal:</strong></span>
1215 1241
 
... ...
@@ -1241,12 +1267,13 @@ We set the fallback character set to set to windows-1252 for all locales, via
1241 1267
 the JS engine</a> to use en-US as its internal C locale for all Date, Math,
1242 1268
 and exception handling.
1243 1269
 
1244
-     </p></li><li class="listitem">Timezone and clock offset
1270
+     </p></li><li class="listitem">Timezone and Clock Offset
1245 1271
      <p>
1246 1272
 
1247 1273
 While the latency in Tor connections varies anywhere from milliseconds to
1248
-several seconds, it is still possible for the remote site to detect large
1274
+a few seconds, it is still possible for the remote site to detect large
1249 1275
 differences between the user's clock and an official reference time source. 
1276
+
1250 1277
      </p><p><span class="command"><strong>Design Goal:</strong></span>
1251 1278
 
1252 1279
 All Tor Browser users MUST report the same timezone to websites. Currently, we
... ...
@@ -1264,7 +1291,7 @@ the browser can obtain this clock skew via a mechanism similar to that used in
1264 1291
 We set the timezone using the TZ environment variable, which is supported on
1265 1292
 all platforms.
1266 1293
 
1267
-     </p></li><li class="listitem">Javascript performance fingerprinting
1294
+     </p></li><li class="listitem">Javascript Performance Fingerprinting
1268 1295
      <p>
1269 1296
 
1270 1297
 <a class="ulink" href="http://w2spconf.com/2011/papers/jspriv.pdf" target="_top">Javascript performance
... ...
@@ -1278,13 +1305,18 @@ We have <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3
1278 1305
 mitigation approaches</a> to reduce the accuracy of performance
1279 1306
 fingerprinting without risking too much damage to functionality. Our current
1280 1307
 favorite is to reduce the resolution of the Event.timeStamp and the Javascript
1281
-Date() object, while also introducing jitter. Our goal is to increase the
1282
-amount of time it takes to mount a successful attack. <a class="ulink" href="http://w2spconf.com/2011/papers/jspriv.pdf" target="_top">Mowery et al</a> found that
1283
-even with the default precision in most browsers, they required up to 120
1308
+Date() object, while also introducing jitter. We believe that Javascript time
1309
+resolution may be reduced all the way up to the second before it seriously
1310
+impacts site operation. Our goal with this quantization is to increase the
1311
+amount of time it takes to mount a successful attack. <a class="ulink" href="http://w2spconf.com/2011/papers/jspriv.pdf" target="_top">Mowery et al</a> found
1312
+that even with the default precision in most browsers, they required up to 120
1284 1313
 seconds of amortization and repeated trials to get stable results from their
1285 1314
 feature set. We intend to work with the research community to establish the
1286
-optimum trade-off between quantization+jitter and amortization time.
1287
-
1315
+optimum trade-off between quantization+jitter and amortization time, as well
1316
+as identify highly variable Javascript operations. As long as these attacks
1317
+take several seconds or more to execute, they are unlikely to be appealing to
1318
+advertisers, and are also very likely to be noticed if deployed against a
1319
+large number of people.
1288 1320
 
1289 1321
      </p><p><span class="command"><strong>Implementation Status:</strong></span>
1290 1322
 
... ...
@@ -1293,17 +1325,7 @@ disable <a class="ulink" href="http://www.w3.org/TR/navigation-timing/" target="
1293 1325
 Timing</a> through the Firefox preference
1294 1326
 <span class="command"><strong>dom.enable_performance</strong></span>.
1295 1327
 
1296
-     </p></li><li class="listitem">Non-Uniform HTML5 API Implementations
1297
-     <p>
1298
-
1299
-At least two HTML5 features have different implementation status across the
1300
-major OS vendors: the <a class="ulink" href="https://developer.mozilla.org/en-US/docs/DOM/window.navigator.battery" target="_top">Battery
1301
-API</a> and the <a class="ulink" href="https://developer.mozilla.org/en-US/docs/DOM/window.navigator.connection" target="_top">Network
1302
-Connection API</a>. We disable these APIs
1303
-through the Firefox preferences <span class="command"><strong>dom.battery.enabled</strong></span> and
1304
-<span class="command"><strong>dom.network.enabled</strong></span>. 
1305
-
1306
-     </p></li><li class="listitem">Keystroke fingerprinting
1328
+     </p></li><li class="listitem">Keystroke Fingerprinting
1307 1329
      <p>
1308 1330
 
1309 1331
 Keystroke fingerprinting is the act of measuring key strike time and key
... ...
@@ -1316,7 +1338,7 @@ fingerprinting: timestamp quantization and jitter.
1316 1338
 
1317 1339
      </p><p><span class="command"><strong>Implementation Status:</strong></span>
1318 1340
 We have no implementation as of yet.
1319
-     </p></li><li class="listitem">Operating system type fingerprinting
1341
+     </p></li><li class="listitem">Operating System Type Fingerprinting
1320 1342
      <p>
1321 1343
 
1322 1344
 As we mentioned in the introduction of this section, OS type fingerprinting is
... ...
@@ -1335,15 +1356,18 @@ We intend to reduce or eliminate OS type fingerprinting to the best extent
1335 1356
 possible, but recognize that the effort for reward on this item is not as high
1336 1357
 as other areas. The entropy on the current OS distribution is somewhere around
1337 1358
 2 bits, which is much lower than other vectors which can also be used to
1338
-fingerprint configuration and user-specific information.
1359
+fingerprint configuration and user-specific information.  You can see the
1360
+major areas of OS fingerprinting we're aware of using the <a class="ulink" href="https://trac.torproject.org/projects/tor/query?keywords=~tbb-fingerprinting-os" target="_top">tbb-fingerprinting-os
1361
+tag on our bug tracker</a>.
1339 1362
 
1340 1363
      </p><p><span class="command"><strong>Implementation Status:</strong></span>
1341 1364
 
1342
-We have no defenses deployed that address OS type fingerprinting by itself.
1343
-Several defenses may help also mitigate it, in addition to reducing a lot more
1344
-entropy elsewhere. You can see the major areas of OS fingerprinting we're
1345
-aware of using the <a class="ulink" href="https://trac.torproject.org/projects/tor/query?keywords=~tbb-fingerprinting-os" target="_top">tbb-fingerprinting-os
1346
-tag on our bugtracker</a>.
1365
+At least two HTML5 features have different implementation status across the
1366
+major OS vendors: the <a class="ulink" href="https://developer.mozilla.org/en-US/docs/DOM/window.navigator.battery" target="_top">Battery
1367
+API</a> and the <a class="ulink" href="https://developer.mozilla.org/en-US/docs/DOM/window.navigator.connection" target="_top">Network
1368
+Connection API</a>. We disable these APIs through the Firefox preferences
1369
+<span class="command"><strong>dom.battery.enabled</strong></span> and
1370
+<span class="command"><strong>dom.network.enabled</strong></span>. 
1347 1371
 
1348 1372
      </p></li></ol></div></div><p>
1349 1373
 For more details on fingerprinting bugs and enhancements, see the <a class="ulink" href="https://trac.torproject.org/projects/tor/query?keywords=~tbb-fingerprinting&amp;status=!closed" target="_top">tbb-fingerprinting tag in our bug tracker</a>
... ...
@@ -1353,11 +1377,11 @@ In order to avoid long-term linkability, we provide a "New Identity" context
1353 1377
 menu option in Torbutton. This context menu option is active if Torbutton can
1354 1378
 read the environment variables $TOR_CONTROL_PASSWD and $TOR_CONTROL_PORT.
1355 1379
 
1356
-   </p><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp60693264"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote">
1380
+   </p><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp45220704"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote">
1357 1381
 
1358 1382
 All linkable identifiers and browser state MUST be cleared by this feature.
1359 1383
 
1360
-    </blockquote></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp60694512"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p>
1384
+    </blockquote></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp45221952"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p>
1361 1385
 
1362 1386
 First, Torbutton disables Javascript in all open tabs and windows by using
1363 1387
 both the <a class="ulink" href="https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIDocShell#Attributes" target="_top">browser.docShell.allowJavascript</a>
... ...
@@ -1437,7 +1461,7 @@ all non-WebM HTML5 codecs (<span class="command"><strong>media.ogg.enabled</stro
1437 1461
 Fingerprinting</a> is a statistical attack to attempt to recognize specific
1438 1462
 encrypted website activity.
1439 1463
 
1440
-     </p><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp60722880"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p>
1464
+     </p><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp45250352"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p>
1441 1465
 
1442 1466
 We want to deploy a mechanism that reduces the accuracy of <a class="ulink" href="https://en.wikipedia.org/wiki/Feature_selection" target="_top">useful features</a> available
1443 1467
 for classification. This mechanism would either impact the true and false
... ...
@@ -1459,7 +1483,7 @@ Congestion-Sensitive BUFLO</a>. It may be also possible to <a class="ulink" href
1459 1483
 defenses</a> such that they only use existing spare Guard bandwidth capacity in the Tor
1460 1484
 network, making them also effectively no-overhead.
1461 1485
 
1462
-     </p></blockquote></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp60729776"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p>
1486
+     </p></blockquote></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp45257248"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p>
1463 1487
 Currently, we patch Firefox to <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/27ef32d509ed1c9eeb28f7affee0f9ba11773f72" target="_top">randomize
1464 1488
 pipeline order and depth</a>. Unfortunately, pipelining is very fragile.
1465 1489
 Many sites do not support it, and even sites that advertise support for
... ...
@@ -1524,7 +1548,7 @@ contend with. For this reason, we have deployed a build system
1524 1548
 that allows anyone to use our source code to reproduce byte-for-byte identical
1525 1549
 binary packages to the ones that we distribute.
1526 1550
 
1527
-  </p><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idp60746000"></a>5.1. Achieving Binary Reproducibility</h3></div></div></div><p>
1551
+  </p><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idp45273472"></a>5.1. Achieving Binary Reproducibility</h3></div></div></div><p>
1528 1552
 
1529 1553
 The GNU toolchain has been working on providing reproducible builds for some
1530 1554
 time, however a large software project such as Firefox typically ends up
... ...
@@ -1641,7 +1665,7 @@ unitialized memory</a> that only appear in LXC mode, as well as
1641 1665
 <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/12240" target="_top">oddities related to
1642 1666
 time-based dependency tracking</a> that only appear in LXC containers.
1643 1667
 
1644
-   </p></li></ol></div></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idp60781056"></a>5.2. Package Signatures and Verification</h3></div></div></div><p>
1668
+   </p></li></ol></div></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idp45308512"></a>5.2. Package Signatures and Verification</h3></div></div></div><p>
1645 1669
 
1646 1670
 The build process produces a single sha256sums.txt file that contains a sorted
1647 1671
 list of the SHA-256 hashes of every package produced for that build version. Each
... ...
@@ -1675,7 +1699,7 @@ and by their nature are based on non-public key material, providing native
1675 1699
 code-signed packages while still preserving ease of reproducibility
1676 1700
 verification has not yet been achieved.
1677 1701
 
1678
-    </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idp60784992"></a>5.3. Anonymous Verification</h3></div></div></div><p>
1702
+    </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idp45312448"></a>5.3. Anonymous Verification</h3></div></div></div><p>
1679 1703
 
1680 1704
 Due to the fact that bit-identical packages can be produced by anyone, the
1681 1705
 security of this build system extends beyond the security of the official
... ...
@@ -1791,7 +1815,7 @@ possible for us to <a class="ulink" href="https://trac.torproject.org/projects/t
1791 1815
 ourselves</a>, as they are comparatively rare and can be handled with site
1792 1816
 permissions.
1793 1817
 
1794
-   </p></li></ol></div></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="idp60816992"></a>A.2. Promising Standards</h2></div></div></div><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><a class="ulink" href="http://web-send.org" target="_top">Web-Send Introducer</a><p>
1818
+   </p></li></ol></div></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="idp45344896"></a>A.2. Promising Standards</h2></div></div></div><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><a class="ulink" href="http://web-send.org" target="_top">Web-Send Introducer</a><p>
1795 1819
 
1796 1820
 Web-Send is a browser-based link sharing and federated login widget that is
1797 1821
 designed to operate without relying on third-party tracking or abusing other
1798 1822