Browse code

Update Tor Browser design doc.

Mike Perry authored on06/05/2015 23:00:38
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 5th, 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="#idp64554400">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="#idp66457392">5.1. Achieving Binary Reproducibility</a></span></dt><dt><span class="sect2"><a href="#idp66479152">5.2. Package Signatures and Verification</a></span></dt><dt><span class="sect2"><a href="#idp66483680">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="#idp66520624">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="idp64554400"></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="#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>
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="idp66162928"></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="idp55920416"></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="idp66164288"></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="idp55921776"></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
... ...
@@ -719,7 +719,7 @@ isolation means that all identifier sources and browser state are scoped
719 719
 (isolated) using the URL bar domain. This scoping is performed in
720 720
 combination with any additional third party scope. When first party isolation
721 721
 is used with explicit identifier storage that already has a constrained third
722
-party scope (such as cookies, DOM storage, and cache), this approach is
722
+party scope (such as cookies and DOM storage), this approach is
723 723
 referred to as "double-keying".
724 724
 
725 725
    </p><p>
... ...
@@ -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="idp66186000"></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="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>
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="idp66189424"></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="idp55946896"></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
... ...
@@ -1051,7 +1051,7 @@ is only possible to minimize the differences among different installations of
1051 1051
 the same browser vendor and version. We make no effort to mimic any other
1052 1052
 major browser vendor, and in fact most of our fingerprinting defenses serve to
1053 1053
 differentiate Tor Browser users from normal Firefox users. Because of this,
1054
-any study that lumps browser vendor and version differences in to its analysis
1054
+any study that lumps browser vendor and version differences into its analysis
1055 1055
 of the fingerprintability of a population is largely useless for evaluating
1056 1056
 either attacks or defenses. Unfortunately, this includes popular large-scale
1057 1057
 studies such as <a class="ulink" href="https://panopticlick.eff.org/" target="_top">Panopticlick</a> and <a class="ulink" href="https://amiunique.org/" target="_top">Am I Unique</a>.
... ...
@@ -1059,11 +1059,11 @@ studies such as <a class="ulink" href="https://panopticlick.eff.org/" target="_t
1059 1059
       </p></li></ol></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="fingerprinting-defenses-general"></a>General Fingerprinting Defenses</h4></div></div></div><p>
1060 1060
 
1061 1061
 To date, the Tor Browser team has concerned itself only with developing
1062
-defenses for APIs that have already been standardized and deployed.  Once an
1062
+defenses for APIs that have already been standardized and deployed. Once an
1063 1063
 API or feature has been standardized and widely deployed, defenses to the
1064 1064
 associated fingerprinting issues tend to have only a few options available to
1065
-address the lack up-front privacy design. In our experience, these options
1066
-tend to be limited to value spoofing, subsystem reimplementation,
1065
+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 1067
 virtualization, site permissions, and feature removal. We will now describe
1068 1068
 these options and the fingerprinting sources they tend to work best with.
1069 1069
 
... ...
@@ -1102,12 +1102,12 @@ fingerprinting vector to attain high accuracy.
1102 1102
 In the event that reimplementation or virtualization is too expensive in terms
1103 1103
 of performance or engineering effort, and the relative expected usage of a
1104 1104
 feature is rare, site permissions can be used to prevent the usage of a
1105
-feature except in cases where the user actually wishes to use it.
1106
-Unfortunately, this mechanism becomes less effective once a feature becomes
1107
-widely overused and abused by many websites, as warning fatigue quickly sets
1108
-in for most users.
1105
+feature for cross-site tracking. Unfortunately, site permissions become less
1106
+effective once a feature is already widely overused and abused by many
1107
+websites, since warning fatigue typically sets in for most users after just a
1108
+few permission requests.
1109 1109
 
1110
-   </p></li><li class="listitem"><span class="command"><strong>Feature/Functionality Removal</strong></span><p>
1110
+   </p></li><li class="listitem"><span class="command"><strong>Feature or Functionality Removal</strong></span><p>
1111 1111
 
1112 1112
 Due to the current bias in favor of invasive APIs that expose the maximum
1113 1113
 amount of platform information, some features and APIs are simply not
... ...
@@ -1116,11 +1116,11 @@ narrow domain or use case, or when there are alternate ways of accomplishing
1116 1116
 the same task, these features and/or certain aspects of their functionality
1117 1117
 may be simply removed.
1118 1118
 
1119
-   </p></li></ol></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp66282416"></a>Randomization or Uniformity?</h4></div></div></div><p>
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>
1120 1120
 
1121
-When applying a form of defense to a specific fingerprinting vector or source, 
1121
+When applying a form of defense to a specific fingerprinting vector or source,
1122 1122
 there are two general strategies available. Either the implementation for all
1123
-users of a single browser implementation can be made to behave as uniformly as
1123
+users of a single browser version can be made to behave as uniformly as
1124 1124
 possible, or the user agent can attempt to randomize its behavior, so that
1125 1125
 each interaction between a user and a site provides a different fingerprint.
1126 1126
 
... ...
@@ -1136,9 +1136,9 @@ for the following reasons:
1136 1136
 While many end-user configuration details that the browser currently exposes
1137 1137
 may be safely replaced by false information, randomization of these details
1138 1138
 must be just as exhaustive as an approach that seeks to make these behaviors
1139
-uniform. In the face of either strategy, the adversary can still make use of
1140
-those features which have not been altered to be either sufficiently uniform
1141
-or sufficiently random.
1139
+uniform. When confronting either strategy, the adversary can still make use of
1140
+any details which have not been altered to be either sufficiently uniform or
1141
+sufficiently random.
1142 1142
 
1143 1143
      </p><p>
1144 1144
 
... ...
@@ -1146,12 +1146,12 @@ Furthermore, the randomization approach seems to break down when it is applied
1146 1146
 to deeper issues where underlying system functionality is directly exposed. In
1147 1147
 particular, it is not clear how to randomize the capabilities of hardware
1148 1148
 attached to a computer in such a way that it either convincingly behaves like
1149
-other hardware, or where the exact properties of the hardware that vary from
1150
-user to user are sufficiently randomized. Similarly, truly concealing operating
1151
-system version differences through randomization may require reimplementation
1152
-of the underlying operating system functionality to ensure that every version
1153
-that your randomization is trying to blend in with is covered by the range of
1154
-possible behaviors.
1149
+other hardware, or such that the exact properties of the hardware that vary
1150
+from user to user are sufficiently randomized. Similarly, truly concealing
1151
+operating system version differences through randomization may require
1152
+multiple reimplementations of the underlying operating system functionality to
1153
+ensure that every operating system version is covered by the range of possible
1154
+behaviors.
1155 1155
 
1156 1156
      </p></li><li class="listitem"><span class="command"><strong>Evaluation and measurement difficulties</strong></span><p>
1157 1157
 
... ...
@@ -1172,16 +1172,16 @@ sufficiently randomized to prevent a dedicated adversary.  Sophisticated
1172 1172
 fingerprinting mechanisms may either ignore randomized information, or
1173 1173
 incorporate knowledge of the distribution and range of randomized values into
1174 1174
 the creation of a more stable fingerprint (by either removing the randomness,
1175
-modeling it, or averaging it).
1175
+modeling it, or averaging it out).
1176 1176
 
1177 1177
       </p></li><li class="listitem"><span class="command"><strong>Usability issues</strong></span><p>
1178 1178
 
1179 1179
 When randomization is introduced to features that affect site behavior, it can
1180 1180
 be very distracting for this behavior to change between visits of a given
1181
-site. For simple cases such as when this information affects layout behavior, 
1182
-this will lead to visual nuisances. However, when this information affects
1183
-reported functionality or hardware characteristics, sometimes a site will
1184
-function one way on one visit, and another way on a subsequent visit.
1181
+site. For the simplest cases, this will lead to minor visual nuisances.
1182
+However, when this information affects reported functionality or hardware
1183
+characteristics, sometimes a site will function one way on one visit, and
1184
+another way on a subsequent visit.
1185 1185
 
1186 1186
       </p></li><li class="listitem"><span class="command"><strong>Performance costs</strong></span><p>
1187 1187
 
... ...
@@ -1591,11 +1591,11 @@ In order to avoid long-term linkability, we provide a "New Identity" context
1591 1591
 menu option in Torbutton. This context menu option is active if Torbutton can
1592 1592
 read the environment variables $TOR_CONTROL_PASSWD and $TOR_CONTROL_PORT.
1593 1593
 
1594
-   </p><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp66398752"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote">
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">
1595 1595
 
1596 1596
 All linkable identifiers and browser state MUST be cleared by this feature.
1597 1597
 
1598
-    </blockquote></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp66400000"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p>
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>
1599 1599
 
1600 1600
 First, Torbutton disables Javascript in all open tabs and windows by using
1601 1601
 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 +1694,7 @@ images (<span class="command"><strong>svg.in-content.enabled</strong></span>).
1694 1694
 Fingerprinting</a> is a statistical attack to attempt to recognize specific
1695 1695
 encrypted website activity.
1696 1696
 
1697
-     </p><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp66434336"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p>
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>
1698 1698
 
1699 1699
 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 1700
 for classification. This mechanism would either impact the true and false
... ...
@@ -1716,7 +1716,7 @@ Congestion-Sensitive BUFLO</a>. It may be also possible to <a class="ulink" href
1716 1716
 defenses</a> such that they only use existing spare Guard bandwidth capacity in the Tor
1717 1717
 network, making them also effectively no-overhead.
1718 1718
 
1719
-     </p></blockquote></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp66441232"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p>
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>
1720 1720
 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 1721
 pipeline order and depth</a>. Unfortunately, pipelining is very fragile.
1722 1722
 Many sites do not support it, and even sites that advertise support for
... ...
@@ -1781,7 +1781,7 @@ contend with. For this reason, we have deployed a build system
1781 1781
 that allows anyone to use our source code to reproduce byte-for-byte identical
1782 1782
 binary packages to the ones that we distribute.
1783 1783
 
1784
-  </p><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idp66457392"></a>5.1. Achieving Binary Reproducibility</h3></div></div></div><p>
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>
1785 1785
 
1786 1786
 The GNU toolchain has been working on providing reproducible builds for some
1787 1787
 time, however a large software project such as Firefox typically ends up
... ...
@@ -1892,7 +1892,7 @@ but differs under LXC. We are also investigating currently
1892 1892
 <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/12240" target="_top">oddities related to
1893 1893
 time-based dependency tracking</a> that only appear in LXC containers.
1894 1894
 
1895
-   </p></li></ol></div></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idp66479152"></a>5.2. Package Signatures and Verification</h3></div></div></div><p>
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>
1896 1896
 
1897 1897
 The build process generates a single sha256sums.txt file that contains a sorted
1898 1898
 list of the SHA-256 hashes of every package produced for that build version. Each
... ...
@@ -1925,7 +1925,7 @@ In order to verify package integrity, the signature must be stripped off using
1925 1925
 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 1926
 Verification</a> page.
1927 1927
 
1928
-    </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idp66483680"></a>5.3. Anonymous Verification</h3></div></div></div><p>
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>
1929 1929
 
1930 1930
 Due to the fact that bit-identical packages can be produced by anyone, the
1931 1931
 security of this build system extends beyond the security of the official
... ...
@@ -2054,7 +2054,7 @@ possible for us to <a class="ulink" href="https://trac.torproject.org/projects/t
2054 2054
 ourselves</a>, as they are comparatively rare and can be handled with site
2055 2055
 permissions.
2056 2056
 
2057
-   </p></li></ol></div></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="idp66520624"></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>
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>
2058 2058
 
2059 2059
 Web-Send is a browser-based link sharing and federated login widget that is
2060 2060
 designed to operate without relying on third-party tracking or abusing other