Browse code

More Tor Browser design doc updates.

Mike Perry authored on07/05/2015 00:12:28
Showing1 changed files
... ...
@@ -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">May 6th, 2015</p></div></div><hr /></div><div class="toc"><p><strong>Table of Contents</strong></p><dl class="toc"><dt><span class="sect1"><a href="#idp54432272">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="#idp56215504">5.1. Achieving Binary Reproducibility</a></span></dt><dt><span class="sect2"><a href="#idp56237264">5.2. Package Signatures and Verification</a></span></dt><dt><span class="sect2"><a href="#idp56241792">5.3. Anonymous Verification</a></span></dt><dt><span class="sect2"><a href="#update-safety">5.4. Update Safety</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="#idp56278768">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="idp54432272"></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">May 6th, 2015</p></div></div><hr /></div><div class="toc"><p><strong>Table of Contents</strong></p><dl class="toc"><dt><span class="sect1"><a href="#idp69131840">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="#idp70162016">5.1. Achieving Binary Reproducibility</a></span></dt><dt><span class="sect2"><a href="#idp70184144">5.2. Package Signatures and Verification</a></span></dt><dt><span class="sect2"><a href="#idp70188672">5.3. Anonymous Verification</a></span></dt><dt><span class="sect2"><a href="#update-safety">5.4. Update Safety</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="#idp70225312">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="idp69131840"></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
... ...
@@ -655,13 +655,13 @@ system-wide extensions (through the use of
655 655
 disabled, which prevents Flash cookies from leaking from a pre-existing Flash
656 656
 directory.
657 657
 
658
-   </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="idp55920416"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote">
658
+   </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="idp66184288"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote">
659 659
 
660 660
 The User Agent MUST (at user option) prevent all disk records of browser activity.
661 661
 The user should be able to optionally enable URL history and other history
662 662
 features if they so desire. 
663 663
 
664
-    </blockquote></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp55921776"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote">
664
+    </blockquote></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp66185680"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote">
665 665
 
666 666
 We achieve this goal through several mechanisms. First, we set the Firefox
667 667
 Private Browsing preference
... ...
@@ -733,7 +733,7 @@ the URL bar origin for which browser state exists, possibly with a
733 733
 context-menu option to drill down into specific types of state or permissions.
734 734
 An example of this simplification can be seen in Figure 1.
735 735
 
736
-   </p><div class="figure"><a id="idp55943472"></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>
736
+   </p><div class="figure"><a id="idp66208640"></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 737
 
738 738
 This example UI is a mock-up of how isolating identifiers to the URL bar
739 739
 origin can simplify the privacy UI for all data - not just cookies. Once
... ...
@@ -741,7 +741,7 @@ browser identifiers and site permissions operate on a URL bar basis, the same
741 741
 privacy window can represent browsing history, DOM Storage, HTTP Auth, search
742 742
 form history, login values, and so on within a context menu for each site.
743 743
 
744
-</div></div></div><br class="figure-break" /><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp55946896"></a>Identifier Unlinkability Defenses in the Tor Browser</h4></div></div></div><p>
744
+</div></div></div><br class="figure-break" /><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp69892352"></a>Identifier Unlinkability Defenses in the Tor Browser</h4></div></div></div><p>
745 745
 
746 746
 Unfortunately, many aspects of browser state can serve as identifier storage,
747 747
 and no other browser vendor or standards body has invested the effort to
... ...
@@ -953,25 +953,31 @@ For more details on identifier linkability bugs and enhancements, see the <a cla
953 953
   </p></div></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="fingerprinting-linkability"></a>4.6. Cross-Origin Fingerprinting Unlinkability</h3></div></div></div><p>
954 954
 
955 955
 Browser fingerprinting is the act of inspecting browser behaviors and features in
956
-an attempt to differentiate and track individual users. Fingerprinting attacks
957
-are typically broken up into passive and active vectors. Passive
958
-fingerprinting makes use of any information the browser provides automatically
959
-to a website without any specific action on the part of the website. Active
960
-fingerprinting makes use of any information that can be extracted from the
961
-browser by some specific website action, usually involving Javascript.
962
-Some definitions of browser fingerprinting also include supercookies and
963
-cookie-like identifier storage, but we deal with those issues separately in
964
-the <a class="link" href="#identifier-linkability" title="4.5. Cross-Origin Identifier Unlinkability">preceding section on identifier
965
-linkability</a>.
966
-
967
-   </p><p>
956
+an attempt to differentiate and track individual users.
957
+  </p><p>
968 958
 
959
+Fingerprinting attacks are typically broken up into passive and active
960
+vectors. Passive fingerprinting makes use of any information the browser
961
+provides automatically to a website without any specific action on the part of
962
+the website. Active fingerprinting makes use of any information that can be
963
+extracted from the browser by some specific website action, usually involving
964
+Javascript.  Some definitions of browser fingerprinting also include
965
+supercookies and cookie-like identifier storage, but we deal with those issues
966
+separately in the <a class="link" href="#identifier-linkability" title="4.5. Cross-Origin Identifier Unlinkability">preceding section on
967
+identifier linkability</a>.
968
+    </p><p>
969 969
 For the most part, however, we do not differentiate between passive or active
970 970
 fingerprinting sources, since many active fingerprinting mechanisms are very
971 971
 rapid, and can be obfuscated or disguised as legitimate functionality.
972
+
973
+   </p><p>
974
+
972 975
 Instead, we believe fingerprinting can only be rationally addressed if we
973 976
 understand where the problem comes from, what sources of issues are the most
974
-severe, and how to study the efficacy of defenses properly.
977
+severe, what types of defenses are suitable for which sources, and have a
978
+consistent strategy for designing defenses that maximizes our ability to study
979
+defense efficacy. The following subsections address these issues from a high
980
+level, and we then conclude with a list of our current specific defenses.
975 981
 
976 982
     </p><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="fingerprinting-scope"></a>Sources of Fingerprinting Issues</h4></div></div></div><p>
977 983
 
... ...
@@ -995,9 +1001,10 @@ identify a user. We believe it is essential to avoid exposing platform
995 1001
 configuration details to website content at all costs. We also discourage
996 1002
 excessive fine-grained customization of Tor Browser by minimizing and
997 1003
 aggregating user-facing privacy and security options, as well as by
998
-discouraging the use of additional addons. When it is necessary to expose
999
-configuration details in the course of providing functionality, we strive to
1000
-do so only on a per-site basis via site permissions, to avoid linkability.
1004
+discouraging the use of additional plugins and addons. When it is necessary to
1005
+expose configuration details in the course of providing functionality, we
1006
+strive to do so only on a per-site basis via site permissions, to avoid
1007
+linkability.
1001 1008
 
1002 1009
      </p></li><li class="listitem"><span class="command"><strong>Device and Hardware Characteristics</strong></span><p>
1003 1010
 
... ...
@@ -1006,9 +1013,9 @@ be reported explicitly by the browser, they can be inferred through browser
1006 1013
 functionality, or they can be extracted through statistical measurements of
1007 1014
 system performance. We are most concerned with the cases where this
1008 1015
 information is either directly reported or can be determined via a single use
1009
-of an API or feature, and prefer to place such APIs either behind site
1010
-permissions, alter their functionality to prevent exposing the most variable
1011
-aspects of these characteristics, or disable them entirely.
1016
+of an API or feature, and prefer to either alter functionality to prevent
1017
+exposing the most variable aspects of these characteristics, place such
1018
+features behind site permissions, or disable them entirely.
1012 1019
 
1013 1020
       </p><p>
1014 1021
 
... ...
@@ -1040,7 +1047,7 @@ fingerprinted through their behavior while interacting with a website. This
1040 1047
 behavior includes e.g. keystrokes, mouse movements, click speed, and writing
1041 1048
 style. Basic vectors such as keystroke and mouse usage fingerprinting can be
1042 1049
 mitigated by altering Javascript's notion of time. More advanced issues like
1043
-writing style fingerprinting are the domain of <a class="ulink" href="https://github.com/psal/anonymouth" target="_top">other tools</a>.
1050
+writing style fingerprinting are the domain of <a class="ulink" href="https://github.com/psal/anonymouth/blob/master/README.md" target="_top">other tools</a>.
1044 1051
 
1045 1052
       </p></li><li class="listitem"><span class="command"><strong>Browser Vendor and Version Differences</strong></span><p>
1046 1053
 
... ...
@@ -1063,9 +1070,10 @@ defenses for APIs that have already been standardized and deployed. Once an
1063 1070
 API or feature has been standardized and widely deployed, defenses to the
1064 1071
 associated fingerprinting issues tend to have only a few options available to
1065 1072
 compensate for the lack of up-front privacy design. In our experience, so far
1066
-these options have been limited to value spoofing, subsystem reimplementation,
1067
-virtualization, site permissions, and feature removal. We will now describe
1068
-these options and the fingerprinting sources they tend to work best with.
1073
+these options have been limited to value spoofing, subsystem modification or
1074
+reimplementation, virtualization, site permissions, and feature removal. We
1075
+will now describe these options and the fingerprinting sources they tend to
1076
+work best with.
1069 1077
 
1070 1078
     </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><span class="command"><strong>Value Spoofing</strong></span><p>
1071 1079
 
... ...
@@ -1075,17 +1083,17 @@ or operating system directly to a website. It becomes less useful when the
1075 1083
 fingerprinting method relies on behavior to infer aspects of the hardware or
1076 1084
 operating system, rather than obtain them directly.
1077 1085
 
1078
-     </p></li><li class="listitem"><span class="command"><strong>Subsystem Reimplementation</strong></span><p>
1086
+     </p></li><li class="listitem"><span class="command"><strong>Subsystem Modification or Reimplementation</strong></span><p>
1079 1087
 
1080 1088
 In cases where simple spoofing is not enough to properly conceal underlying
1081
-device characteristics or operating system details, the underlying
1082
-subsystem that provides the functionality for a feature or API may need
1083
-to be completely reimplemented. This is most common in cases where
1084
-customizable or version-specific aspects of the user's operating system are
1085
-visible through the browser's featureset or APIs, usually because the browser
1086
-directly exposes OS-provided implementations of underlying features. In these
1087
-cases, such OS-provided implementations must be replaced by a generic
1088
-implementation, or at least an implementation wrapper that makes effort to
1089
+device characteristics or operating system details, the underlying subsystem
1090
+that provides the functionality for a feature or API may need to be modified
1091
+or completely reimplemented. This is most common in cases where customizable
1092
+or version-specific aspects of the user's operating system are visible through
1093
+the browser's featureset or APIs, usually because the browser directly exposes
1094
+OS-provided implementations of underlying features. In these cases, such
1095
+OS-provided implementations must be replaced by a generic implementation, or
1096
+at least modified by an implementation wrapper layer that makes effort to
1089 1097
 conceal any user-customized aspects of the system.
1090 1098
 
1091 1099
    </p></li><li class="listitem"><span class="command"><strong>Virtualization</strong></span><p>
... ...
@@ -1116,12 +1124,12 @@ narrow domain or use case, or when there are alternate ways of accomplishing
1116 1124
 the same task, these features and/or certain aspects of their functionality
1117 1125
 may be simply removed.
1118 1126
 
1119
-   </p></li></ol></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp56040528"></a>Randomization or Uniformity?</h4></div></div></div><p>
1127
+   </p></li></ol></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp69985904"></a>Strategies for Defense: Randomization versus Uniformity</h4></div></div></div><p>
1120 1128
 
1121 1129
 When applying a form of defense to a specific fingerprinting vector or source,
1122
-there are two general strategies available. Either the implementation for all
1130
+there are two general strategies available: either the implementation for all
1123 1131
 users of a single browser version can be made to behave as uniformly as
1124
-possible, or the user agent can attempt to randomize its behavior, so that
1132
+possible, or the user agent can attempt to randomize its behavior so that
1125 1133
 each interaction between a user and a site provides a different fingerprint.
1126 1134
 
1127 1135
     </p><p>
... ...
@@ -1131,7 +1139,28 @@ research suggests</a> that randomization can be effective, so far striving
1131 1139
 for uniformity has generally proved to be a better strategy for Tor Browser
1132 1140
 for the following reasons:
1133 1141
 
1134
-    </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><span class="command"><strong>Randomization is not a shortcut</strong></span><p>
1142
+    </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><span class="command"><strong>Evaluation and measurement difficulties</strong></span><p>
1143
+
1144
+The fact that randomization causes behaviors to differ slightly with every
1145
+site visit makes it appealing at first glance, but this same property makes it
1146
+very difficult to objectively measure its effectiveness. By contrast, an
1147
+implementation that strives for uniformity is very simple to evaluate. Despite
1148
+their current flaws, a properly designed version of <a class="ulink" href="https://panopticlick.eff.org/" target="_top">Panopticlick</a> or <a class="ulink" href="https://amiunique.org/" target="_top">Am I Unique</a> could report the entropy and
1149
+uniqueness rates for all users of a single user agent version, without the
1150
+need for complicated statistics about the variance of the measured behaviors.
1151
+
1152
+      </p><p>
1153
+
1154
+Randomization (especially incomplete randomization) may also provide a false
1155
+sense of security. When a fingerprinting attempt makes naive use of randomized
1156
+information, a fingerprint will appear unstable, but may not actually be
1157
+sufficiently randomized to impede a dedicated adversary.  Sophisticated
1158
+fingerprinting mechanisms may either ignore randomized information, or
1159
+incorporate knowledge of the distribution and range of randomized values into
1160
+the creation of a more stable fingerprint (by either removing the randomness,
1161
+modeling it, or averaging it out).
1162
+
1163
+      </p></li><li class="listitem"><span class="command"><strong>Randomization is not a shortcut</strong></span><p>
1135 1164
 
1136 1165
 While many end-user configuration details that the browser currently exposes
1137 1166
 may be safely replaced by false information, randomization of these details
... ...
@@ -1153,28 +1182,7 @@ multiple reimplementations of the underlying operating system functionality to
1153 1182
 ensure that every operating system version is covered by the range of possible
1154 1183
 behaviors.
1155 1184
 
1156
-     </p></li><li class="listitem"><span class="command"><strong>Evaluation and measurement difficulties</strong></span><p>
1157
-
1158
-The fact that randomization causes behaviors to differ slightly with every
1159
-site visit makes it appealing at first glance, but this same property makes it
1160
-very difficult to objectively measure its effectiveness. By contrast, an
1161
-implementation that strives for uniformity is very simple to measure. Despite
1162
-their current flaws, a properly designed version of <a class="ulink" href="https://panopticlick.eff.org/" target="_top">Panopticlick</a> or <a class="ulink" href="https://amiunique.org/" target="_top">Am I Unique</a> could report the entropy and
1163
-uniqueness rates for all users of a single user agent version, without the
1164
-need for complicated statistics about the variance of the measured behaviors.
1165
-
1166
-      </p><p>
1167
-
1168
-Randomization (especially incomplete randomization) may also provide a false
1169
-sense of security. When a fingerprinting attempt makes naive use of randomized
1170
-information, a fingerprint will appear unstable, but may not actually be
1171
-sufficiently randomized to prevent a dedicated adversary.  Sophisticated
1172
-fingerprinting mechanisms may either ignore randomized information, or
1173
-incorporate knowledge of the distribution and range of randomized values into
1174
-the creation of a more stable fingerprint (by either removing the randomness,
1175
-modeling it, or averaging it out).
1176
-
1177
-      </p></li><li class="listitem"><span class="command"><strong>Usability issues</strong></span><p>
1185
+     </p></li><li class="listitem"><span class="command"><strong>Usability issues</strong></span><p>
1178 1186
 
1179 1187
 When randomization is introduced to features that affect site behavior, it can
1180 1188
 be very distracting for this behavior to change between visits of a given
... ...
@@ -1591,11 +1599,11 @@ In order to avoid long-term linkability, we provide a "New Identity" context
1591 1599
 menu option in Torbutton. This context menu option is active if Torbutton can
1592 1600
 read the environment variables $TOR_CONTROL_PASSWD and $TOR_CONTROL_PORT.
1593 1601
 
1594
-   </p><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp56156768"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote">
1602
+   </p><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp70103376"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote">
1595 1603
 
1596 1604
 All linkable identifiers and browser state MUST be cleared by this feature.
1597 1605
 
1598
-    </blockquote></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp56158016"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p>
1606
+    </blockquote></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp70104624"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p>
1599 1607
 
1600 1608
 First, Torbutton disables Javascript in all open tabs and windows by using
1601 1609
 both the <a class="ulink" href="https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIDocShell#Attributes" target="_top">browser.docShell.allowJavascript</a>
... ...
@@ -1694,7 +1702,7 @@ images (<span class="command"><strong>svg.in-content.enabled</strong></span>).
1694 1702
 Fingerprinting</a> is a statistical attack to attempt to recognize specific
1695 1703
 encrypted website activity.
1696 1704
 
1697
-     </p><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp56192352"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p>
1705
+     </p><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp70138960"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p>
1698 1706
 
1699 1707
 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
1700 1708
 for classification. This mechanism would either impact the true and false
... ...
@@ -1716,7 +1724,7 @@ Congestion-Sensitive BUFLO</a>. It may be also possible to <a class="ulink" href
1716 1724
 defenses</a> such that they only use existing spare Guard bandwidth capacity in the Tor
1717 1725
 network, making them also effectively no-overhead.
1718 1726
 
1719
-     </p></blockquote></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp56199248"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p>
1727
+     </p></blockquote></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp70145856"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p>
1720 1728
 Currently, we patch Firefox to <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0esr-4.5-1&amp;id=20a59cec9886cf2575b1fd8e92b43e31ba053fbd" target="_top">randomize
1721 1729
 pipeline order and depth</a>. Unfortunately, pipelining is very fragile.
1722 1730
 Many sites do not support it, and even sites that advertise support for
... ...
@@ -1781,7 +1789,7 @@ contend with. For this reason, we have deployed a build system
1781 1789
 that allows anyone to use our source code to reproduce byte-for-byte identical
1782 1790
 binary packages to the ones that we distribute.
1783 1791
 
1784
-  </p><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idp56215504"></a>5.1. Achieving Binary Reproducibility</h3></div></div></div><p>
1792
+  </p><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idp70162016"></a>5.1. Achieving Binary Reproducibility</h3></div></div></div><p>
1785 1793
 
1786 1794
 The GNU toolchain has been working on providing reproducible builds for some
1787 1795
 time, however a large software project such as Firefox typically ends up
... ...
@@ -1892,7 +1900,7 @@ but differs under LXC. We are also investigating currently
1892 1900
 <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/12240" target="_top">oddities related to
1893 1901
 time-based dependency tracking</a> that only appear in LXC containers.
1894 1902
 
1895
-   </p></li></ol></div></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idp56237264"></a>5.2. Package Signatures and Verification</h3></div></div></div><p>
1903
+   </p></li></ol></div></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idp70184144"></a>5.2. Package Signatures and Verification</h3></div></div></div><p>
1896 1904
 
1897 1905
 The build process generates a single sha256sums.txt file that contains a sorted
1898 1906
 list of the SHA-256 hashes of every package produced for that build version. Each
... ...
@@ -1925,7 +1933,7 @@ In order to verify package integrity, the signature must be stripped off using
1925 1933
 the osslsigncode tool, as described on the <a class="ulink" href="https://www.torproject.org/docs/verifying-signatures.html.en#BuildVerification" target="_top">Signature
1926 1934
 Verification</a> page.
1927 1935
 
1928
-    </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idp56241792"></a>5.3. Anonymous Verification</h3></div></div></div><p>
1936
+    </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idp70188672"></a>5.3. Anonymous Verification</h3></div></div></div><p>
1929 1937
 
1930 1938
 Due to the fact that bit-identical packages can be produced by anyone, the
1931 1939
 security of this build system extends beyond the security of the official
... ...
@@ -2054,7 +2062,7 @@ possible for us to <a class="ulink" href="https://trac.torproject.org/projects/t
2054 2062
 ourselves</a>, as they are comparatively rare and can be handled with site
2055 2063
 permissions.
2056 2064
 
2057
-   </p></li></ol></div></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="idp56278768"></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>
2065
+   </p></li></ol></div></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="idp70225312"></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>
2058 2066
 
2059 2067
 Web-Send is a browser-based link sharing and federated login widget that is
2060 2068
 designed to operate without relying on third-party tracking or abusing other