Update design doc for TBB 4.0.
Mike Perry

Mike Perry commited on 2014-10-30 06:00:02
Zeige 1 geänderte Dateien mit 401 Einfügungen und 288 Löschungen.

... ...
@@ -1,10 +1,9 @@
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">
3
-<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.76.1" /></head><body><div class="article" title="The Design and Implementation of the Tor Browser [DRAFT]"><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">March 15, 2013</p></div></div><hr /></div><div class="toc"><p><strong>Table of Contents</strong></p><dl><dt><span class="sect1"><a href="#idp2182160">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><dt><span class="sect2"><a href="#firefox-patches">4.9. Description of Firefox Patches</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="#idp5896048">A.2. Promising Standards</a></span></dt></dl></dd></dl></div><div class="sect1" title="1. Introduction"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="idp2182160"></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">October 30th, 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="#idp35210336">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="#idp37001088">5.1. Achieving Binary Reproducibility</a></span></dt><dt><span class="sect2"><a href="#idp37036336">5.2. Package Signatures and Verification</a></span></dt><dt><span class="sect2"><a href="#idp37040272">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="#idp37071376">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="idp35210336"></a>1. Introduction</h2></div></div></div><p>
4 3
 
5 4
 This document describes the <a class="link" href="#adversary" title="3. Adversary Model">adversary model</a>,
6 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
7
-2.3.25-5 and Torbutton 1.5.1.
6
+4.0.
8 7
 
9 8
   </p><p>
10 9
 
... ...
@@ -13,27 +12,39 @@ describe a reference implementation of a Private Browsing Mode that defends
13 12
 against active network adversaries, in addition to the passive forensic local
14 13
 adversary currently addressed by the major browsers.
15 14
 
16
-  </p><div class="sect2" title="1.1. Browser Component Overview"><div class="titlepage"><div><div><h3 class="title"><a id="components"></a>1.1. Browser Component Overview</h3></div></div></div><p>
15
+  </p><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="components"></a>1.1. Browser Component Overview</h3></div></div></div><p>
17 16
 
18 17
 The Tor Browser is based on <a class="ulink" href="https://www.mozilla.org/en-US/firefox/organizations/" target="_top">Mozilla's Extended
19
-Support Release (ESR) Firefox branch</a>. We have a <a class="link" href="#firefox-patches" title="4.9. Description of Firefox Patches">series of patches</a> against this browser to
20
-enhance privacy and security. Browser behavior is additionally augmented
21
-through the <a class="ulink" href="https://gitweb.torproject.org/torbutton.git/tree/master" target="_top">Torbutton
22
-extension</a>, though we are in the process of moving this
23
-functionality into direct Firefox patches. We also <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/HEAD:/build-scripts/config/pound_tor.js" target="_top">change
18
+Support Release (ESR) Firefox branch</a>. We have a <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git" target="_top">series of patches</a>
19
+against this browser to enhance privacy and security. Browser behavior is
20
+additionally augmented through the <a class="ulink" href="https://gitweb.torproject.org/torbutton.git/tree/master" target="_top">Torbutton
21
+extension</a>, though we are in the process of moving this functionality
22
+into direct Firefox patches. We also <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/blob/refs/heads/tor-browser-31.2.0esr-4.x-1:/browser/app/profile/000-tor-browser.js" target="_top">change
24 23
 a number of Firefox preferences</a> from their defaults.
25 24
 
26 25
    </p><p>
26
+Tor process management and configuration is accomplished through the <a class="ulink" href="https://gitweb.torproject.org/tor-launcher.git" target="_top">Tor Launcher</a>
27
+addon, which provides the initial Tor configuration splash screen and
28
+bootstrap progress bar. Tor Launcher is also compatible with Thunderbird,
29
+InstantBird, and XULRunner.
30
+
31
+   </p><p>
27 32
 
28 33
 To help protect against potential Tor Exit Node eavesdroppers, we include
29 34
 <a class="ulink" href="https://www.eff.org/https-everywhere" target="_top">HTTPS-Everywhere</a>. To
30 35
 provide users with optional defense-in-depth against Javascript and other
31
-potential exploit vectors, we also include <a class="ulink" href="http://noscript.net/" target="_top">NoScript</a>. To protect against
32
-PDF-based Tor proxy bypass and to improve usability, we include the <a class="ulink" href="https://addons.mozilla.org/en-us/firefox/addon/pdfjs/" target="_top">PDF.JS</a>
33
-extension. We also modify <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/HEAD:/build-scripts/config/extension-overrides.js" target="_top">several
36
+potential exploit vectors, we also include <a class="ulink" href="http://noscript.net/" target="_top">NoScript</a>. We also modify <a class="ulink" href="https://gitweb.torproject.org/builders/tor-browser-bundle.git/blob/refs/heads/master:/Bundle-Data/linux/Data/Browser/profile.default/preferences/extension-overrides.js" target="_top">several
34 37
 extension preferences</a> from their defaults.
35 38
 
36
-   </p></div></div><div class="sect1" title="2. Design Requirements and Philosophy"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="DesignRequirements"></a>2. Design Requirements and Philosophy</h2></div></div></div><p>
39
+   </p><p>
40
+
41
+To provide censorship circumvention in areas where the public Tor network is
42
+blocked either by IP, or by protocol fingerprint, we include several <a class="ulink" href="https://trac.torproject.org/projects/tor/wiki/doc/AChildsGardenOfPluggableTransports" target="_top">Pluggable
43
+Transports</a> in the distribution. As of this writing, we include <a class="ulink" href="https://gitweb.torproject.org/pluggable-transports/obfsproxy.git/blob/HEAD:/doc/obfs3/obfs3-protocol-spec.txt" target="_top">Obfsproxy</a>,
44
+<a class="ulink" href="https://trac.torproject.org/projects/tor/wiki/doc/meek" target="_top">meek</a>,
45
+<a class="ulink" href="https://fteproxy.org/" target="_top">FTE</a>, and <a class="ulink" href="https://crypto.stanford.edu/flashproxy/" target="_top">FlashProxy</a>.
46
+
47
+   </p></div></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="DesignRequirements"></a>2. Design Requirements and Philosophy</h2></div></div></div><p>
37 48
 
38 49
 The Tor Browser Design Requirements are meant to describe the properties of a
39 50
 Private Browsing Mode that defends against both network and local forensic
... ...
@@ -59,7 +70,7 @@ browser distribution.
59 70
       "OPTIONAL" in this document are to be interpreted as described in
60 71
       <a class="ulink" href="https://www.ietf.org/rfc/rfc2119.txt" target="_top">RFC 2119</a>.
61 72
 
62
-  </p><div class="sect2" title="2.1. Security Requirements"><div class="titlepage"><div><div><h3 class="title"><a id="security"></a>2.1. Security Requirements</h3></div></div></div><p>
73
+  </p><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="security"></a>2.1. Security Requirements</h3></div></div></div><p>
63 74
 
64 75
 The security requirements are primarily concerned with ensuring the safe use
65 76
 of Tor. Violations in these properties typically result in serious risk for
... ...
@@ -100,7 +111,7 @@ to permissions issues with access to swap, implementations MAY choose to leave
100 111
 it out of scope, and/or leave it to the Operating System/platform to implement
101 112
 ephemeral-keyed encrypted swap.
102 113
 
103
-</p></li></ol></div></div><div class="sect2" title="2.2. Privacy Requirements"><div class="titlepage"><div><div><h3 class="title"><a id="privacy"></a>2.2. Privacy Requirements</h3></div></div></div><p>
114
+</p></li></ol></div></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="privacy"></a>2.2. Privacy Requirements</h3></div></div></div><p>
104 115
 
105 116
 The privacy requirements are primarily concerned with reducing linkability:
106 117
 the ability for a user's activity on one site to be linked with their activity
... ...
@@ -144,7 +155,7 @@ its authentication tokens and browser state and obtain a fresh identity.
144 155
 Additionally, the browser SHOULD clear linkable state by default automatically
145 156
 upon browser restart, except at user option.
146 157
 
147
-  </p></li></ol></div></div><div class="sect2" title="2.3. Philosophy"><div class="titlepage"><div><div><h3 class="title"><a id="philosophy"></a>2.3. Philosophy</h3></div></div></div><p>
158
+  </p></li></ol></div></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="philosophy"></a>2.3. Philosophy</h3></div></div></div><p>
148 159
 
149 160
 In addition to the above design requirements, the technology decisions about
150 161
 Tor Browser are also guided by some philosophical positions about technology.
... ...
@@ -207,7 +218,7 @@ url bar origin</a> to eliminate the possibility of linkability
207 218
 between domains. For example, when a plugin object (or a Javascript access of
208 219
 window.plugins) is present in a page, the user should be given the choice of
209 220
 allowing that plugin object for that url bar origin only. The same
210
-goes for exemptions to third party cookie policy, geo-location, and any other
221
+goes for exemptions to third party cookie policy, geolocation, and any other
211 222
 privacy permissions.
212 223
      </p><p>
213 224
 If the user has indicated they wish to record local history storage, these
... ...
@@ -243,18 +254,18 @@ We believe that if we do not stay current with the support of new web
243 254
 technologies, we cannot hope to substantially influence or be involved in
244 255
 their proper deployment or privacy realization. However, we will likely disable
245 256
 high-risk features pending analysis, audit, and mitigation.
246
-      </p></li></ol></div></div></div><div class="sect1" title="3. Adversary Model"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="adversary"></a>3. Adversary Model</h2></div></div></div><p>
257
+      </p></li></ol></div></div></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="adversary"></a>3. Adversary Model</h2></div></div></div><p>
247 258
 
248 259
 A Tor web browser adversary has a number of goals, capabilities, and attack
249 260
 types that can be used to illustrate the design requirements for the
250 261
 Tor Browser. Let's start with the goals.
251 262
 
252
-   </p><div class="sect2" title="3.1. Adversary Goals"><div class="titlepage"><div><div><h3 class="title"><a id="adversary-goals"></a>3.1. Adversary Goals</h3></div></div></div><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><span class="command"><strong>Bypassing proxy settings</strong></span><p>The adversary's primary goal is direct compromise and bypass of 
263
+   </p><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="adversary-goals"></a>3.1. Adversary Goals</h3></div></div></div><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><span class="command"><strong>Bypassing proxy settings</strong></span><p>The adversary's primary goal is direct compromise and bypass of 
253 264
 Tor, causing the user to directly connect to an IP of the adversary's
254 265
 choosing.</p></li><li class="listitem"><span class="command"><strong>Correlation of Tor vs Non-Tor Activity</strong></span><p>If direct proxy bypass is not possible, the adversary will likely
255 266
 happily settle for the ability to correlate something a user did via Tor with
256 267
 their non-Tor activity. This can be done with cookies, cache identifiers,
257
-javascript events, and even CSS. Sometimes the fact that a user uses Tor may
268
+Javascript events, and even CSS. Sometimes the fact that a user uses Tor may
258 269
 be enough for some authorities.</p></li><li class="listitem"><span class="command"><strong>History disclosure</strong></span><p>
259 270
 The adversary may also be interested in history disclosure: the ability to
260 271
 query a user's history to see if they have issued certain censored search
... ...
@@ -282,7 +293,7 @@ In some cases, the adversary may opt for a heavy-handed approach, such as
282 293
 seizing the computers of all Tor users in an area (especially after narrowing
283 294
 the field by the above two pieces of information). History records and cache
284 295
 data are the primary goals here.
285
-     </p></li></ol></div></div><div class="sect2" title="3.2. Adversary Capabilities - Positioning"><div class="titlepage"><div><div><h3 class="title"><a id="adversary-positioning"></a>3.2. Adversary Capabilities - Positioning</h3></div></div></div><p>
296
+     </p></li></ol></div></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="adversary-positioning"></a>3.2. Adversary Capabilities - Positioning</h3></div></div></div><p>
286 297
 The adversary can position themselves at a number of different locations in
287 298
 order to execute their attacks.
288 299
     </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><span class="command"><strong>Exit Node or Upstream Router</strong></span><p>
... ...
@@ -311,7 +322,7 @@ Users in Internet cafes, for example, face such a threat. In addition, in
311 322
 countries where simply using tools like Tor is illegal, users may face
312 323
 confiscation of their computer equipment for excessive Tor usage or just
313 324
 general suspicion.
314
-     </p></li></ol></div></div><div class="sect2" title="3.3. Adversary Capabilities - Attacks"><div class="titlepage"><div><div><h3 class="title"><a id="attacks"></a>3.3. Adversary Capabilities - Attacks</h3></div></div></div><p>
325
+     </p></li></ol></div></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="attacks"></a>3.3. Adversary Capabilities - Attacks</h3></div></div></div><p>
315 326
 
316 327
 The adversary can perform the following attacks from a number of different 
317 328
 positions to accomplish various aspects of their goals. It should be noted
... ...
@@ -340,7 +351,7 @@ with cookies as well.
340 351
 
341 352
      </p><p>
342 353
 
343
-These types of attacks are attempts at subverting our <a class="link" href="#identifier-linkability" title="4.5. Cross-Origin Identifier Unlinkability">Cross-Origin Identifier Unlinkability</a> and <a class="link" href="#new-identity" title="4.7. Long-Term Unlinkability via &quot;New Identity&quot; button">Long-Term Unlikability</a> design requirements.
354
+These types of attacks are attempts at subverting our <a class="link" href="#identifier-linkability" title="4.5. Cross-Origin Identifier Unlinkability">Cross-Origin Identifier Unlinkability</a> and <a class="link" href="#new-identity" title="4.7. Long-Term Unlinkability via &quot;New Identity&quot; button">Long-Term Unlinkability</a> design requirements.
344 355
 
345 356
      </p></li><li class="listitem"><a id="fingerprinting"></a><span class="command"><strong>Fingerprint users based on browser
346 357
 attributes</strong></span><p>
... ...
@@ -350,7 +361,7 @@ of the browser. This information can be used to reduce anonymity set, or even
350 361
 uniquely fingerprint individual users. Attacks of this nature are typically
351 362
 aimed at tracking users across sites without their consent, in an attempt to
352 363
 subvert our <a class="link" href="#fingerprinting-linkability" title="4.6. Cross-Origin Fingerprinting Unlinkability">Cross-Origin
353
-Fingerprinting Unlinkability</a> and <a class="link" href="#new-identity" title="4.7. Long-Term Unlinkability via &quot;New Identity&quot; button">Long-Term Unlikability</a> design requirements.
364
+Fingerprinting Unlinkability</a> and <a class="link" href="#new-identity" title="4.7. Long-Term Unlinkability via &quot;New Identity&quot; button">Long-Term Unlinkability</a> design requirements.
354 365
 
355 366
 </p><p>
356 367
 
... ...
@@ -465,7 +476,7 @@ complexity (and thus hinder a real world adversary who attempts this attack)
465 476
 are large numbers of dynamically generated pages, partially cached content,
466 477
 and also the non-web activity of entire Tor network. This yields an effective
467 478
 number of "web pages" many orders of magnitude larger than even <a class="ulink" href="http://lorre.uni.lu/~andriy/papers/acmccs-wpes11-fingerprinting.pdf" target="_top">Panchenko's
468
-"Open World" scenario</a>, which suffered continous near-constant decline
479
+"Open World" scenario</a>, which suffered continuous near-constant decline
469 480
 in the true positive rate as the "Open World" size grew (see figure 4). This
470 481
 large level of classification complexity is further confounded by a noisy and
471 482
 low resolution featureset - one which is also relatively easy for the defender
... ...
@@ -510,12 +521,12 @@ has taken place. This adversary motivates our
510 521
 
511 522
 An adversary with arbitrary code execution typically has more power, though.
512 523
 It can be quite hard to really significantly limit the capabilities of such an
513
-adversary. <a class="ulink" href="https://tails.boum.org/contribute/design/" target="_top">The Tails system</a> can
524
+adversary. <a class="ulink" href="http://tails.boum.org/contribute/design/" target="_top">The Tails system</a> can
514 525
 provide some defense against this adversary through the use of readonly media
515 526
 and frequent reboots, but even this can be circumvented on machines without
516 527
 Secure Boot through the use of BIOS rootkits.
517 528
 
518
-     </p></li></ol></div></div></div><div class="sect1" title="4. Implementation"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Implementation"></a>4. Implementation</h2></div></div></div><p>
529
+     </p></li></ol></div></div></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Implementation"></a>4. Implementation</h2></div></div></div><p>
519 530
 
520 531
 The Implementation section is divided into subsections, each of which
521 532
 corresponds to a <a class="link" href="#DesignRequirements" title="2. Design Requirements and Philosophy">Design Requirement</a>.
... ...
@@ -531,38 +542,45 @@ between the <span class="command"><strong>Design Goal</strong></span> and the <s
531 542
 Status</strong></span> for each property. Corresponding bugs in the <a class="ulink" href="https://trac.torproject.org/projects/tor/report" target="_top">Tor bug tracker</a>
532 543
 are typically linked for these cases.
533 544
 
534
-  </p><div class="sect2" title="4.1. Proxy Obedience"><div class="titlepage"><div><div><h3 class="title"><a id="proxy-obedience"></a>4.1. Proxy Obedience</h3></div></div></div><p>
545
+  </p><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="proxy-obedience"></a>4.1. Proxy Obedience</h3></div></div></div><p>
535 546
 
536 547
 Proxy obedience is assured through the following:
537 548
    </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem">Firefox proxy settings, patches, and build flags
538 549
  <p>
539
-Our <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/HEAD:/build-scripts/config/pound_tor.js" target="_top">Firefox
540
-preferences file</a> sets the Firefox proxy settings to use Tor directly as a
541
-SOCKS proxy. It sets <span class="command"><strong>network.proxy.socks_remote_dns</strong></span>,
550
+
551
+Our <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/blob/refs/heads/tor-browser-31.2.0esr-4.x-1:/browser/app/profile/000-tor-browser.js" target="_top">Firefox
552
+preferences file</a> sets the Firefox proxy settings to use Tor directly
553
+as a SOCKS proxy. It sets <span class="command"><strong>network.proxy.socks_remote_dns</strong></span>,
542 554
 <span class="command"><strong>network.proxy.socks_version</strong></span>,
543 555
 <span class="command"><strong>network.proxy.socks_port</strong></span>, and
544 556
 <span class="command"><strong>network.dns.disablePrefetch</strong></span>.
557
+
545 558
  </p><p>
546 559
 
547
-We also patch Firefox in order to <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0016-Prevent-WebSocket-DNS-leak.patch" target="_top">prevent
548
-a DNS leak due to a WebSocket rate-limiting check</a>. As stated in the
549
-patch, we believe the direct DNS resolution performed by this check is in
550
-violation of the W3C standard, but <a class="ulink" href="https://bugzilla.mozilla.org/show_bug.cgi?id=751465" target="_top">this DNS proxy leak
551
-remains present in stock Firefox releases</a>.
560
+To prevent proxy bypass by WebRTC calls, we disable WebRTC at compile time
561
+with the <span class="command"><strong>--disable-webrtc</strong></span> configure switch, as well
562
+as set the pref <span class="command"><strong>media.peerconnection.enabled</strong></span> to false.
552 563
 
553 564
  </p><p>
554 565
 
555
-During the transition to Firefox 17-ESR, a code audit was undertaken to verify
556
-that there were no system calls or XPCOM activity in the source tree that did
557
-not use the browser proxy settings. The only violation we found was that
558
-WebRTC was capable of creating UDP sockets and was compiled in by default. We
559
-subsequently disabled it using the Firefox build option
560
-<span class="command"><strong>--disable-webrtc</strong></span>.
566
+We also patch Firefox in order to provide several defense-in-depth mechanisms
567
+for proxy safety. Notably, we <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/8527bec0ad59fb3d885c5639735fb188eefa336f" target="_top">patch
568
+the DNS service</a> to prevent any browser or addon DNS resolution, and we
569
+also <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/04c046e11f6622f44ca010bcb8ecf68cf470a4c0" target="_top">patch
570
+OCSP and PKIX code</a> to prevent any use of the non-proxied command-line
571
+tool utility functions from being functional while linked in to the browser.
572
+In both cases, we could find no direct paths to these routines in the browser,
573
+but it seemed better safe than sorry.
561 574
 
562 575
  </p><p>
563 576
 
577
+During every Extended Support Release transition, we perform <a class="ulink" href="https://gitweb.torproject.org/tor-browser-spec.git/tree/HEAD:/audits" target="_top">in-depth
578
+code audits</a> to verify that there were no system calls or XPCOM
579
+activity in the source tree that did not use the browser proxy settings.
580
+ </p><p>
581
+
564 582
 We have verified that these settings and patches properly proxy HTTPS, OCSP,
565
-HTTP, FTP, gopher (now defunct), DNS, SafeBrowsing Queries, all javascript
583
+HTTP, FTP, gopher (now defunct), DNS, SafeBrowsing Queries, all JavaScript
566 584
 activity, including HTML5 audio and video objects, addon updates, wifi
567 585
 geolocation queries, searchbox queries, XPCOM addon HTTPS/HTTP activity,
568 586
 WebSockets, and live bookmark updates. We have also verified that IPv6
... ...
@@ -590,10 +608,11 @@ If the user does enable plugins in this way, plugin-handled objects are still
590 608
 restricted from automatic load through Firefox's click-to-play preference
591 609
 <span class="command"><strong>plugins.click_to_play</strong></span>.
592 610
  </p><p>
611
+
593 612
 In addition, to reduce any unproxied activity by arbitrary plugins at load
594 613
 time, and to reduce the fingerprintability of the installed plugin list, we
595
-also patch the Firefox source code to <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0005-Block-all-plugins-except-flash.patch" target="_top">prevent the load of any plugins except
596
-for Flash and Gnash</a>.
614
+also patch the Firefox source code to <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/2ecf6c33618ecee554155f735a3e92860f519f9c" target="_top">
615
+prevent the load of any plugins except for Flash and Gnash</a>.
597 616
 
598 617
  </p></li><li class="listitem">External App Blocking and Drag Event Filtering
599 618
   <p>
... ...
@@ -611,9 +630,8 @@ Additionally, modern desktops now pre-emptively fetch any URLs in Drag and
611 630
 Drop events as soon as the drag is initiated. This download happens
612 631
 independent of the browser's Tor settings, and can be triggered by something
613 632
 as simple as holding the mouse button down for slightly too long while
614
-clicking on an image link. We had to patch Firefox to <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0018-Emit-observer-event-to-filter-the-Drag-Drop-url-list.patch" target="_top">emit
615
-an observer event during dragging</a> to allow us to filter the drag
616
-events from Torbutton before the OS downloads the URLs the events contained.
633
+clicking on an image link. We filter drag and drop events events <a class="ulink" href="https://gitweb.torproject.org/torbutton.git/blob_plain/HEAD:/src/components/external-app-blocker.js" target="_top">from
634
+Torbutton</a> before the OS downloads the URLs the events contained.
617 635
 
618 636
   </p></li><li class="listitem">Disabling system extensions and clearing the addon whitelist
619 637
   <p>
... ...
@@ -626,41 +644,39 @@ system-level addons from the browser through the use of
626 644
 <span class="command"><strong>extensions.enabledScopes</strong></span> and
627 645
 <span class="command"><strong>extensions.autoDisableScopes</strong></span>.
628 646
 
629
-  </p></li></ol></div></div><div class="sect2" title="4.2. State Separation"><div class="titlepage"><div><div><h3 class="title"><a id="state-separation"></a>4.2. State Separation</h3></div></div></div><p>
647
+  </p></li></ol></div></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="state-separation"></a>4.2. State Separation</h3></div></div></div><p>
630 648
 
631 649
 Tor Browser State is separated from existing browser state through use of a
632 650
 custom Firefox profile, and by setting the $HOME environment variable to the
633 651
 root of the bundle's directory.  The browser also does not load any
634 652
 system-wide extensions (through the use of
635 653
 <span class="command"><strong>extensions.enabledScopes</strong></span> and
636
-<span class="command"><strong>extensions.autoDisableScopes</strong></span>. Furthermore, plugins are
654
+<span class="command"><strong>extensions.autoDisableScopes</strong></span>). Furthermore, plugins are
637 655
 disabled, which prevents Flash cookies from leaking from a pre-existing Flash
638 656
 directory.
639 657
 
640
-   </p></div><div class="sect2" title="4.3. Disk Avoidance"><div class="titlepage"><div><div><h3 class="title"><a id="disk-avoidance"></a>4.3. Disk Avoidance</h3></div></div></div><div class="sect3" title="Design Goal:"><div class="titlepage"><div><div><h4 class="title"><a id="idp5639136"></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="idp36779392"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote">
641 659
 
642 660
 The User Agent MUST (at user option) prevent all disk records of browser activity.
643 661
 The user should be able to optionally enable URL history and other history
644 662
 features if they so desire. 
645 663
 
646
-    </blockquote></div></div><div class="sect3" title="Implementation Status:"><div class="titlepage"><div><div><h4 class="title"><a id="idp5640496"></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="idp36780752"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote">
647 665
 
648 666
 We achieve this goal through several mechanisms. First, we set the Firefox
649 667
 Private Browsing preference
650 668
 <span class="command"><strong>browser.privatebrowsing.autostart</strong></span>. In addition, four Firefox patches are needed to prevent disk writes, even if
651 669
 Private Browsing Mode is enabled. We need to
652 670
 
653
-<a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0002-Make-Permissions-Manager-memory-only.patch" target="_top">prevent
654
-the permissions manager from recording HTTPS STS state</a>,
655
-<a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0003-Make-Intermediate-Cert-Store-memory-only.patch" target="_top">prevent
656
-intermediate SSL certificates from being recorded</a>,
657
-<a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0013-Make-Download-manager-memory-only.patch" target="_top">prevent
658
-download history from being recorded</a>, and
659
-<a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0006-Make-content-pref-service-memory-only-clearable.patch" target="_top">prevent
660
-the content preferences service from recording site zoom</a>.
661
-
662
-For more details on these patches, <a class="link" href="#firefox-patches" title="4.9. Description of Firefox Patches">see the
663
-Firefox Patches section</a>.
671
+<a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/4ebc3cda4b704c0149fb9e0fdcbb6e5ee3a8e75c" target="_top">prevent
672
+the permissions manager from recording HTTPS STS state</a>, <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/8904bfc10cd537bd35be5ddd23c58fdaa72baa21" target="_top">prevent
673
+intermediate SSL certificates from being recorded</a>, <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/86f6bc9dc28b6f8d7eae7974c7e9b537c3a08e41" target="_top">prevent
674
+the clipboard cache from being written to disk for large pastes</a>, and
675
+<a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/d5da6f8b7de089335e49e2f7dbd2b8d74e4cb613" target="_top">prevent
676
+the content preferences service from recording site zoom</a>. We also had
677
+to disable the media cache with the pref <span class="command"><strong>media.cache_size</strong></span>,
678
+to prevent HTML5 videos from being written to the OS temporary directory,
679
+which happened regardless of the private browsing mode setting.
664 680
 
665 681
     </blockquote></div><div class="blockquote"><blockquote class="blockquote">
666 682
 
... ...
@@ -681,11 +697,7 @@ auditing work to ensure that yet.
681 697
 
682 698
     </blockquote></div><div class="blockquote"><blockquote class="blockquote">
683 699
 
684
-Torbutton also <a class="ulink" href="https://gitweb.torproject.org/torbutton.git/blob/HEAD:/src/components/tbSessionStore.js" target="_top">contains
685
-code</a> to prevent the Firefox session store from writing to disk.
686
-    </blockquote></div><div class="blockquote"><blockquote class="blockquote">
687
-
688
-For more details on disk leak bugs and enhancements, see the <a class="ulink" href="https://trac.torproject.org/projects/tor/query?keywords=~tbb-disk-leak&amp;status=!closed" target="_top">tbb-disk-leak tag in our bugtracker</a></blockquote></div></div></div><div class="sect2" title="4.4. Application Data Isolation"><div class="titlepage"><div><div><h3 class="title"><a id="app-data-isolation"></a>4.4. Application Data Isolation</h3></div></div></div><p>
700
+For more details on disk leak bugs and enhancements, see the <a class="ulink" href="https://trac.torproject.org/projects/tor/query?keywords=~tbb-disk-leak&amp;status=!closed" target="_top">tbb-disk-leak tag in our bugtracker</a></blockquote></div></div></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="app-data-isolation"></a>4.4. Application Data Isolation</h3></div></div></div><p>
689 701
 
690 702
 Tor Browser Bundle MUST NOT cause any information to be written outside of the
691 703
 bundle directory. This is to ensure that the user is able to completely and
... ...
@@ -699,7 +711,7 @@ To ensure TBB directory isolation, we set
699 711
 <span class="command"><strong>browser.shell.checkDefaultBrowser</strong></span>, and
700 712
 <span class="command"><strong>browser.download.manager.addToRecentDocs</strong></span>. We also set the
701 713
 $HOME environment variable to be the TBB extraction directory.
702
-   </p></div><div class="sect2" title="4.5. Cross-Origin Identifier Unlinkability"><div class="titlepage"><div><div><h3 class="title"><a id="identifier-linkability"></a>4.5. Cross-Origin Identifier Unlinkability</h3></div></div></div><p>
714
+   </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="identifier-linkability"></a>4.5. Cross-Origin Identifier Unlinkability</h3></div></div></div><p>
703 715
 
704 716
 The Tor Browser MUST prevent a user's activity on one site from being linked
705 717
 to their activity on another site. When this goal cannot yet be met with an
... ...
@@ -723,7 +735,7 @@ the url bar origin for which browser state exists, possibly with a
723 735
 context-menu option to drill down into specific types of state or permissions.
724 736
 An example of this simplification can be seen in Figure 1.
725 737
 
726
-   </p><div class="figure"><a id="idp5664576"></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
+   </p><div class="figure"><a id="idp36803456"></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>
727 739
 
728 740
 This example UI is a mock-up of how isolating identifiers to the URL bar
729 741
 origin can simplify the privacy UI for all data - not just cookies. Once
... ...
@@ -937,7 +949,7 @@ functionality.
937 949
 
938 950
      </p></li></ol></div><p>
939 951
 For more details on identifier linkability bugs and enhancements, see the <a class="ulink" href="https://trac.torproject.org/projects/tor/query?keywords=~tbb-linkability&amp;status=!closed" target="_top">tbb-linkability tag in our bugtracker</a>
940
-  </p></div><div class="sect2" title="4.6. Cross-Origin Fingerprinting Unlinkability"><div class="titlepage"><div><div><h3 class="title"><a id="fingerprinting-linkability"></a>4.6. Cross-Origin Fingerprinting Unlinkability</h3></div></div></div><p>
952
+  </p></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>
941 953
 
942 954
 In order to properly address the fingerprinting adversary on a technical
943 955
 level, we need a metric to measure linkability of the various browser
... ...
@@ -950,11 +962,14 @@ determine how many bits of identifying information each attribute provided.
950 962
 
951 963
    </p><p>
952 964
 
953
-Many browser features have been added since the EFF first ran their experiment
954
-and collected their data. To avoid an infinite sinkhole, we reduce the efforts
955
-for fingerprinting resistance by only concerning ourselves with reducing the
956
-fingerprintable differences <span class="emphasis"><em>among</em></span> Tor Browser users. We
957
-do not believe it is possible to solve cross-browser fingerprinting issues.
965
+Because fingerprinting is problem that potentially touches every aspect of the
966
+browser, we reduce the efforts for fingerprinting resistance by only
967
+concerning ourselves with reducing the fingerprintable differences
968
+<span class="emphasis"><em>among</em></span> Tor Browser users. We do not believe it is possible
969
+to solve cross-browser fingerprinting issues. Similarly, we prioritize issues
970
+that differentiate only MacOS, Windows, and Linux lower than those that
971
+differentiate aspects of the hardware, third party installed software, and
972
+configuration differences in those operating systems.
958 973
 
959 974
    </p><p>
960 975
 
... ...
@@ -970,7 +985,15 @@ contrast to historical data. We have been <a class="ulink" href="https://trac.to
970 985
 the EFF</a> that it is worthwhile to release the source code to
971 986
 Panopticlick to allow us to run our own version for this reason.
972 987
 
973
-   </p><div class="sect3" title="Fingerprinting defenses in the Tor Browser"><div class="titlepage"><div><div><h4 class="title"><a id="fingerprinting-defenses"></a>Fingerprinting defenses in the Tor Browser</h4></div></div></div><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem">Plugins
988
+   </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>
989
+
990
+The following defenses are listed roughly in order of most severe
991
+fingerprinting threat first, though we are desperately in need of updated
992
+measurements to determine this with certainty. Where our actual implementation
993
+differs from an ideal solution, we separately describe our <span class="command"><strong>Design
994
+Goal</strong></span> and our <span class="command"><strong>Implementation Status</strong></span>.
995
+
996
+   </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem">Plugins
974 997
      <p>
975 998
 
976 999
 Plugins add to fingerprinting risk via two main vectors: their mere presence in
... ...
@@ -984,7 +1007,9 @@ be allowed to load objects until the user has clicked through a click-to-play
984 1007
 barrier.  Additionally, version information should be reduced or obfuscated
985 1008
 until the plugin object is loaded. For flash, we wish to <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3974" target="_top">provide a
986 1009
 settings.sol file</a> to disable Flash cookies, and to restrict P2P
987
-features that are likely to bypass proxy settings.
1010
+features that are likely to bypass proxy settings. We'd also like to restrict
1011
+access to fonts and other system information (such as IP address and MAC
1012
+address) in such a sandbox.
988 1013
 
989 1014
      </p><p><span class="command"><strong>Implementation Status:</strong></span>
990 1015
 
... ...
@@ -1015,11 +1040,49 @@ image can be used almost identically to a tracking cookie by the web server.
1015 1040
 
1016 1041
      </p><p>
1017 1042
 
1018
-To reduce the threat from this vector, we have patched Firefox to <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0020-Add-canvas-image-extraction-prompt.patch" target="_top">prompt
1019
-before returning valid image data</a> to the Canvas APIs. If the user
1020
-hasn't previously allowed the site in the URL bar to access Canvas image data,
1021
-pure white image data is returned to the Javascript APIs.
1043
+In some sense, the canvas can be seen as the union of many other
1044
+fingerprinting vectors. If WebGL were normalized through software rendering,
1045
+and the browser shipped a fixed collection of fonts, it might not be necessary
1046
+to create a canvas permission. However, until then, to reduce the threat from
1047
+this vector, we have patched Firefox to <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/3b53f525cfb68880e676e64f13cbc0b928ae3ecf" target="_top">prompt
1048
+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
1049
+to isPointInPath and related functions</a>. If the user hasn't previously
1050
+allowed the site in the URL bar to access Canvas image data, pure white image
1051
+data is returned to the Javascript APIs.
1052
+
1053
+     </p><p>
1054
+     </p></li><li class="listitem">Open TCP Port Fingerprinting
1055
+     <p>
1056
+
1057
+In Firefox, by using either WebSockets or XHR, it is possible for remote
1058
+content to <a class="ulink" href="http://www.andlabs.org/tools/jsrecon.html" target="_top">enumerate
1059
+the list of TCP ports open on 127.0.0.1</a>. In other browsers, this can
1060
+be accomplished by DOM events on image or script tags. This open vs filtered
1061
+vs closed port list can provide a very unique fingerprint of a machine.
1062
+
1063
+     </p><p>In Tor Browser, we prevent access to
1064
+127.0.0.1/localhost by ensuring that even these requests are still sent by
1065
+Firefox to our SOCKS proxy (ie we set
1066
+<span class="command"><strong>network.proxy.no_proxies_on</strong></span> to the empty string). The local
1067
+Tor client then rejects them, since it is configured to proxy for internal IP
1068
+addresses by default.
1069
+     </p></li><li class="listitem">USB Device ID enumeration
1070
+     <p>
1071
+
1072
+The <a class="ulink" href="https://developer.mozilla.org/en-US/docs/Web/Guide/API/Gamepad" target="_top">GamePad
1073
+API</a> provides web pages with the <a class="ulink" href="https://dvcs.w3.org/hg/gamepad/raw-file/default/gamepad.html#widl-Gamepad-id" target="_top">USB
1074
+device id, product id, and driver name</a> of all connected game
1075
+controllers, as well as detailed information about their capabilities. This API
1076
+should be behind a site permission in Private Browsing Modes, or should present a generic 
1077
+controller type (perhaps a two button controller that can be mapped to the keyboard) in all cases.
1078
+We simply disable it via the pref <span class="command"><strong>dom.gamepad.enabled</strong></span>.
1022 1079
 
1080
+     </p></li><li class="listitem">Invasive Authentication Mechanisms (NTLM and SPNEGO)
1081
+     <p>
1082
+Both NTLM and SPNEGO authentication mechanisms can leak the hostname, and in
1083
+some cases the machine username. These authentication mechanisms should either
1084
+be disabled, or placed behind a site permission before their use. We simply
1085
+disable them.
1023 1086
      </p></li><li class="listitem">WebGL
1024 1087
      <p>
1025 1088
 
... ...
@@ -1040,6 +1103,12 @@ provided by the following WebGL API calls: <span class="command"><strong>getPara
1040 1103
 <span class="command"><strong>getSupportedExtensions()</strong></span>, and
1041 1104
 <span class="command"><strong>getExtension()</strong></span>.
1042 1105
 
1106
+     </p><p>
1107
+
1108
+Another option for WebGL might be to use software-only rendering, using a
1109
+library such as <a class="ulink" href="http://www.mesa3d.org/" target="_top">Mesa</a>. The use of
1110
+such a library would avoid hardware-specific rendering differences.
1111
+
1043 1112
      </p></li><li class="listitem">Fonts
1044 1113
      <p>
1045 1114
 
... ...
@@ -1050,28 +1119,33 @@ Javascript to query for the existence of specific fonts. With a large enough
1050 1119
 pre-built list to query, a large amount of fingerprintable information may
1051 1120
 still be available.
1052 1121
 
1053
-     </p><p>
1054
-
1055
-The sure-fire way to address font linkability is to ship the browser with a
1056
-font for every language, typeface, and style in use in the world, and to only
1057
-use those fonts at the exclusion of system fonts.  However, this set may be
1058
-impractically large. It is possible that a smaller <a class="ulink" href="https://secure.wikimedia.org/wikipedia/en/wiki/Unicode_typeface#List_of_Unicode_fonts" target="_top">common
1059
-subset</a> may be found that provides total coverage. However, we believe
1060
-that with strong url bar origin identifier isolation, a simpler approach can reduce the
1061
-number of bits available to the adversary while avoiding the rendering and
1062
-language issues of supporting a global font set.
1063
-
1122
+     </p><p><span class="command"><strong>Design Goal:</strong></span> The sure-fire way to address font
1123
+linkability is to ship the browser with a font for every language, typeface,
1124
+and style, and to only use those fonts at the exclusion of system fonts. We are
1125
+<a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/13313" target="_top">currently
1126
+investigating</a> this approach, and our current favorite font sets for
1127
+this purpose are the <a class="ulink" href="http://www.droidfonts.com/droidfonts/" target="_top">Droid
1128
+fonts</a>, the <a class="ulink" href="http://hangeul.naver.com/" target="_top">Nanum fonts</a>,
1129
+and <a class="ulink" href="https://fedorahosted.org/lohit/" target="_top">Lohit fonts</a>. The Droid
1130
+font set is fairly complete by itself, but Nanum and Lohit have smaller
1131
+versions of many South Asian languages. When combined in a way that chooses the
1132
+smallest font implementations for each locale, these three font sets provide
1133
+which provide coverage for the all languages used on Wikipedia with more than
1134
+10,000 articles, and several others as well, in approximately 3MB of compressed
1135
+overhead. The <a class="ulink" href="https://www.google.com/get/noto/" target="_top">Noto font
1136
+set</a> is another font set that aims for complete coverage, but is
1137
+considerably larger than the combination of the Droid, Nanum, and Lohit fonts.
1064 1138
      </p><p><span class="command"><strong>Implementation Status:</strong></span>
1065 1139
 
1066
-We disable plugins, which prevents font enumeration. Additionally, we limit
1067
-both the number of font queries from CSS, as well as the total number of 
1068
-fonts that can be used in a document <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0011-Limit-the-number-of-fonts-per-document.patch" target="_top">with
1140
+In the meantime while we investigate shipping our own fonts, we disable
1141
+plugins, which prevents font enumeration. Additionally, we limit both the
1142
+number of font queries from CSS, as well as the total number of fonts that can
1143
+be used in a document <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0011-Limit-the-number-of-fonts-per-document.patch" target="_top">with
1069 1144
 a Firefox patch</a>. We create two prefs,
1070 1145
 <span class="command"><strong>browser.display.max_font_attempts</strong></span> and
1071 1146
 <span class="command"><strong>browser.display.max_font_count</strong></span> for this purpose. Once these
1072 1147
 limits are reached, the browser behaves as if
1073
-<span class="command"><strong>browser.display.use_document_fonts</strong></span> was set. We are
1074
-still working to determine optimal values for these prefs.
1148
+<span class="command"><strong>browser.display.use_document_fonts</strong></span> was set.
1075 1149
 
1076 1150
      </p><p>
1077 1151
 
... ...
@@ -1079,12 +1153,12 @@ To improve rendering, we exempt remote <a class="ulink" href="https://developer.
1079 1153
 fonts</a> from these counts, and if a font-family CSS rule lists a remote
1080 1154
 font (in any order), we use that font instead of any of the named local fonts.
1081 1155
 
1082
-     </p></li><li class="listitem">Desktop resolution, CSS Media Queries, and System Colors
1156
+     </p></li><li class="listitem">Monitor and Desktop resolution
1083 1157
      <p>
1084 1158
 
1085 1159
 Both CSS and Javascript have access to a lot of information about the screen
1086 1160
 resolution, usable desktop size, OS widget size, toolbar size, title bar size,
1087
-system theme colors, and other desktop features that are not at all relevant
1161
+screen orientation, and other desktop features that are not at all relevant
1088 1162
 to rendering and serve only to provide information for fingerprinting.
1089 1163
 
1090 1164
      </p><p><span class="command"><strong>Design Goal:</strong></span>
... ...
@@ -1093,29 +1167,55 @@ Our design goal here is to reduce the resolution information down to the bare
1093 1167
 minimum required for properly rendering inside a content window. We intend to
1094 1168
 report all rendering information correctly with respect to the size and
1095 1169
 properties of the content window, but report an effective size of 0 for all
1096
-border material, and also report that the desktop is only as big as the
1097
-inner content window. Additionally, new browser windows are sized such that 
1098
-their content windows are one of a few fixed sizes based on the user's
1099
-desktop resolution. 
1170
+border material, and also report that the desktop is only as big as the inner
1171
+content window. Additionally, new browser windows are sized such that their
1172
+content windows are one of a few fixed sizes based on the user's desktop
1173
+resolution. In addition, to further reduce resolution-based fingerprinting, we
1174
+are <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/7256" target="_top">investigating
1175
+zoom/viewport-based mechanisms</a> that might allow us to always report the
1176
+same desktop resolution regardless of the actual size of the content window,
1177
+and simply scale to make up the difference.  Until then, the user should also
1178
+be informed that maximizing their windows can lead to fingerprintability under
1179
+this scheme. 
1100 1180
 
1101 1181
      </p><p><span class="command"><strong>Implementation Status:</strong></span>
1102 1182
 
1103
-We have implemented the above strategy using a window observer to <a class="ulink" href="https://gitweb.torproject.org/torbutton.git/blob/HEAD:/src/chrome/content/torbutton.js#l2004" target="_top">resize
1183
+
1184
+We have implemented the above strategy using a window observer to <a class="ulink" href="https://gitweb.torproject.org/torbutton.git/blob/HEAD:/src/chrome/content/torbutton.js#l2960" target="_top">resize
1104 1185
 new windows based on desktop resolution</a>. Additionally, we patch
1105
-Firefox to use the client content window size <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0022-Do-not-expose-physical-screen-info.-via-window-and-w.patch" target="_top">for
1106
-window.screen</a> and <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0010-Limit-device-and-system-specific-CSS-Media-Queries.patch" target="_top">for
1107
-CSS Media Queries</a>. Similarly, we <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0021-Return-client-window-coordinates-for-mouse-event-scr.patch" target="_top">patch
1108
-DOM events to return content window relative points</a>. We also patch
1109
-Firefox to <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0023-Do-not-expose-system-colors-to-CSS-or-canvas.patch" target="_top">report
1110
-a fixed set of system colors to content window CSS</a>.
1186
+Firefox to use the client content window size <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/8fc2421becd0ab0cfb5ebbc19af67469552202b2" target="_top">for
1187
+window.screen</a>. Similarly, we <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/81e7fc3a10d27b1d8f0832faf1685899d21f6fef" target="_top">patch
1188
+DOM events to return content window relative points</a>. We also force
1189
+popups to open in new tabs (via
1190
+<span class="command"><strong>browser.link.open_newwindow.restriction</strong></span>), to avoid
1191
+full-screen popups inferring information about the browser resolution. In
1192
+addition, we prevent auto-maximizing on browser start, and are investigating a
1193
+user-friendly way of informing users that maximized windows are detrimental
1194
+to privacy in this mode.
1195
+
1196
+     </p></li><li class="listitem">CSS Media Queries
1197
+     <p>
1111 1198
 
1112
-     </p><p>
1199
+Even without Javascript, CSS has access to a lot of information about the screen
1200
+resolution, usable desktop size, OS widget size, toolbar size, title bar size,
1201
+system theme colors, and other desktop features that are not at all relevant
1202
+to rendering and serve only to provide information for fingerprinting. Most of this information comes from 
1203
+<a class="ulink" href="https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Media_queries" target="_top">CSS Media Queries</a>, but 
1204
+Mozilla has exposed <a class="ulink" href="https://developer.mozilla.org/en-US/docs/Web/CSS/color_value#System_Colors" target="_top">several user and OS theme defined color values</a> to CSS as well.
1205
+
1206
+     </p><p><span class="command"><strong>Design Goal:</strong></span>
1207
+In Private Browsing Mode, CSS should not be able infer anything that the user
1208
+has configured about their computer. Additionally, it should not be able to
1209
+infer machine-specific details such as screen orientation or type.
1210
+
1211
+     </p><p><span class="command"><strong>Implementation Status:</strong></span>
1113 1212
 
1114
-To further reduce resolution-based fingerprinting, we are <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/7256" target="_top">investigating
1115
-zoom/viewport-based mechanisms</a> that might allow us to always report
1116
-the same desktop resolution regardless of the actual size of the content
1117
-window, and simply scale to make up the difference. However, the complexity
1118
-and rendering impact of such a change is not yet known.
1213
+We patch
1214
+Firefox to <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/30dc2c4290698af81ceafae9d628a34c53faabe1" target="_top">report
1215
+a fixed set of system colors to content window CSS</a>, and <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/8f6e979d30598569dea14ac6f4eef4e96543b3d7" target="_top">prevent
1216
+detection of font smoothing on OSX</a>. We also always
1217
+<a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/09561f0e5452305b9efcb4e6169c613c8db33246" target="_top">report
1218
+landscape-primary</a> for the screen orientation.
1119 1219
 
1120 1220
      </p></li><li class="listitem">User Agent and HTTP Headers
1121 1221
      <p><span class="command"><strong>Design Goal:</strong></span>
... ...
@@ -1132,8 +1232,29 @@ which we leverage. We also set similar prefs for controlling the
1132 1232
 Accept-Language and Accept-Charset headers, which we spoof to English by default. Additionally, we
1133 1233
 <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0001-Block-Components.interfaces-from-content.patch" target="_top">remove
1134 1234
 content script access</a> to Components.interfaces, which <a class="ulink" href="http://pseudo-flaw.net/tor/torbutton/fingerprint-firefox.html" target="_top">can be
1135
-used</a> to fingerprint OS, platform, and Firefox minor version.  </p></li><li class="listitem">Timezone and clock offset
1136
-     <p><span class="command"><strong>Design Goal:</strong></span>
1235
+used</a> to fingerprint OS, platform, and Firefox minor version.  </p></li><li class="listitem">Locale Fingerprinting
1236
+     <p>
1237
+
1238
+In Tor Browser, we provide non-English users the option of concealing their OS
1239
+and browser locale from websites. It is debatable if this should be as high of
1240
+a priority as information specific to the user's computer, but for
1241
+completeness, we attempt to maintain this property.
1242
+
1243
+     </p><p><span class="command"><strong>Implementation Status:</strong></span>
1244
+
1245
+We set the fallback character set to set to windows-1252 for all locales, via
1246
+<span class="command"><strong>intl.charset.default</strong></span>.  We also patch Firefox to allow us to
1247
+<a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/fe42a78575df7f460fa0ac48eabb57bc8812c23e" target="_top">instruct
1248
+the JS engine</a> to use en-US as its internal C locale for all Date, Math,
1249
+and exception handling.
1250
+
1251
+     </p></li><li class="listitem">Timezone and clock offset
1252
+     <p>
1253
+
1254
+While the latency in Tor connections varies anywhere from milliseconds to
1255
+several seconds, it is still possible for the remote site to detect large
1256
+differences between the user's clock and an official reference timesource. 
1257
+     </p><p><span class="command"><strong>Design Goal:</strong></span>
1137 1258
 
1138 1259
 All Tor Browser users MUST report the same timezone to websites. Currently, we
1139 1260
 choose UTC for this purpose, although an equally valid argument could be made
... ...
@@ -1141,7 +1262,9 @@ for EDT/EST due to the large English-speaking population density (coupled with
1141 1262
 the fact that we spoof a US English user agent).  Additionally, the Tor
1142 1263
 software should detect if the users clock is significantly divergent from the
1143 1264
 clocks of the relays that it connects to, and use this to reset the clock
1144
-values used in Tor Browser to something reasonably accurate.
1265
+values used in Tor Browser to something reasonably accurate. Alternatively,
1266
+the browser can obtain this clock skew via a mechanism similar to that used in
1267
+<a class="ulink" href="" target="_top">tlsdate</a>.
1145 1268
 
1146 1269
      </p><p><span class="command"><strong>Implementation Status:</strong></span>
1147 1270
 
... ...
@@ -1204,17 +1327,17 @@ fingerprinting: timestamp quantization and jitter.
1204 1327
 We have no implementation as of yet.
1205 1328
      </p></li></ol></div></div><p>
1206 1329
 For more details on identifier linkability 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 bugtracker</a>
1207
-  </p></div><div class="sect2" title="4.7. Long-Term Unlinkability via &quot;New Identity&quot; button"><div class="titlepage"><div><div><h3 class="title"><a id="new-identity"></a>4.7. Long-Term Unlinkability via "New Identity" button</h3></div></div></div><p>
1330
+  </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="new-identity"></a>4.7. Long-Term Unlinkability via "New Identity" button</h3></div></div></div><p>
1208 1331
 
1209 1332
 In order to avoid long-term linkability, we provide a "New Identity" context
1210 1333
 menu option in Torbutton. This context menu option is active if Torbutton can
1211 1334
 read the environment variables $TOR_CONTROL_PASSWD and $TOR_CONTROL_PORT.
1212 1335
 
1213
-   </p><div class="sect3" title="Design Goal:"><div class="titlepage"><div><div><h4 class="title"><a id="idp5782640"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote">
1336
+   </p><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp36963888"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote">
1214 1337
 
1215 1338
 All linkable identifiers and browser state MUST be cleared by this feature.
1216 1339
 
1217
-    </blockquote></div></div><div class="sect3" title="Implementation Status:"><div class="titlepage"><div><div><h4 class="title"><a id="idp5783888"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p>
1340
+    </blockquote></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp36965136"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p>
1218 1341
 
1219 1342
 First, Torbutton disables Javascript in all open tabs and windows by using
1220 1343
 both the <a class="ulink" href="https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIDocShell#Attributes" target="_top">browser.docShell.allowJavascript</a>
... ...
@@ -1232,8 +1355,9 @@ After closing all tabs, we then emit "<a class="ulink" href="https://developer.m
1232 1355
 state), and then manually clear the following state: searchbox and findbox
1233 1356
 text, HTTP auth, SSL state, OCSP state, site-specific content preferences
1234 1357
 (including HSTS state), content and image cache, offline cache, Cookies, DOM
1235
-storage, DOM local storage, the safe browsing key, and the Google wifi geolocation
1236
-token (if it exists). 
1358
+storage, crypto tokens, DOM local storage, the safe browsing key, and the
1359
+Google wifi geolocation token (if it exists). We also clear NoScript's site
1360
+and temporary permissions.
1237 1361
 
1238 1362
      </p><p>
1239 1363
 
... ...
@@ -1246,7 +1370,7 @@ closed (this does not spawn a new Firefox process, only a new window).
1246 1370
      </p></blockquote></div><div class="blockquote"><blockquote class="blockquote">
1247 1371
 If the user chose to "protect" any cookies by using the Torbutton Cookie
1248 1372
 Protections UI, those cookies are not cleared as part of the above.
1249
-    </blockquote></div></div></div><div class="sect2" title="4.8. Other Security Measures"><div class="titlepage"><div><div><h3 class="title"><a id="other-security"></a>4.8. Other Security Measures</h3></div></div></div><p>
1373
+    </blockquote></div></div></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="other-security"></a>4.8. Other Security Measures</h3></div></div></div><p>
1250 1374
 
1251 1375
 In addition to the above mechanisms that are devoted to preserving privacy
1252 1376
 while browsing, we also have a number of technical mechanisms to address other
... ...
@@ -1258,7 +1382,7 @@ privacy and security issues.
1258 1382
 Fingerprinting</a> is a statistical attack to attempt to recognize specific
1259 1383
 encrypted website activity.
1260 1384
 
1261
-     </p><div class="sect3" title="Design Goal:"><div class="titlepage"><div><div><h4 class="title"><a id="idp5797920"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p>
1385
+     </p><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp36979248"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p>
1262 1386
 
1263 1387
 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
1264 1388
 for classification. This mechanism would either impact the true and false
... ...
@@ -1280,7 +1404,7 @@ Congestion-Sensitive BUFLO</a>. It may be also possible to <a class="ulink" href
1280 1404
 defenses</a> such that they only use existing spare Guard bandwidth capacity in the Tor
1281 1405
 network, making them also effectively no-overhead.
1282 1406
 
1283
-     </p></blockquote></div></div><div class="sect3" title="Implementation Status:"><div class="titlepage"><div><div><h4 class="title"><a id="idp5804816"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p>
1407
+     </p></blockquote></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp36986144"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p>
1284 1408
 Currently, we patch Firefox to <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0017-Randomize-HTTP-request-order-and-pipeline-depth.patch" target="_top">randomize
1285 1409
 pipeline order and depth</a>. Unfortunately, pipelining is very fragile.
1286 1410
 Many sites do not support it, and even sites that advertise support for
... ...
@@ -1330,199 +1454,188 @@ homepage to point to a <a class="ulink" href="https://check.torproject.org/?lang
1330 1454
 informs the user</a> that their browser is out of
1331 1455
 date.
1332 1456
 
1333
-     </p></li></ol></div></div><div class="sect2" title="4.9. Description of Firefox Patches"><div class="titlepage"><div><div><h3 class="title"><a id="firefox-patches"></a>4.9. Description of Firefox Patches</h3></div></div></div><p>
1334
-
1335
-The set of patches we have against Firefox can be found in the <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/tree/maint-2.4:/src/current-patches/firefox" target="_top">current-patches directory of the torbrowser git repository</a>. They are:
1336
-
1337
-   </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0001-Block-Components.interfaces-from-content.patch" target="_top">Block
1338
-Components.interfaces</a><p>
1339
-
1340
-In order to reduce fingerprinting, we block access to this interface from
1341
-content script. Components.interfaces can be used for fingerprinting the
1342
-platform, OS, and Firebox version, but not much else.
1343
-
1344
-     </p></li><li class="listitem"><a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0002-Make-Permissions-Manager-memory-only.patch" target="_top">Make
1345
-Permissions Manager memory only</a><p>
1346
-
1347
-This patch exposes a pref 'permissions.memory_only' that properly isolates the
1348
-permissions manager to memory, which is responsible for all user specified
1349
-site permissions, as well as stored <a class="ulink" href="https://secure.wikimedia.org/wikipedia/en/wiki/HTTP_Strict_Transport_Security" target="_top">HSTS</a>
1350
-policy from visited sites.
1351
-
1352
-The pref does successfully clear the permissions manager memory if toggled. It
1353
-does not need to be set in prefs.js, and can be handled by Torbutton.
1354
-
1355
-     </p></li><li class="listitem"><a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0003-Make-Intermediate-Cert-Store-memory-only.patch" target="_top">Make
1356
-Intermediate Cert Store memory-only</a><p>
1357
-
1358
-The intermediate certificate store records the intermediate SSL certificates
1359
-the browser has seen to date. Because these intermediate certificates are used 
1360
-by a limited number of domains (and in some cases, only a single domain),
1361
-the intermediate certificate store can serve as a low-resolution record of
1362
-browsing history.
1363
-
1364
-     </p><p><span class="command"><strong>Design Goal:</strong></span>
1365
-
1366
-As an additional design goal, we would like to later alter this patch to allow this
1367
-information to be cleared from memory. The implementation does not currently
1368
-allow this.
1369
-
1370
-     </p></li><li class="listitem"><a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0004-Add-a-string-based-cacheKey.patch" target="_top">Add
1371
-a string-based cacheKey property for domain isolation</a><p>
1372
-
1373
-To <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3666" target="_top">increase the
1374
-security of cache isolation</a> and to <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3754" target="_top">solve strange and
1375
-unknown conflicts with OCSP</a>, we had to patch
1376
-Firefox to provide a cacheDomain cache attribute. We use the url bar
1377
-FQDN as input to this field.
1378
-
1379
-     </p></li><li class="listitem"><a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0005-Block-all-plugins-except-flash.patch" target="_top">Block
1380
-all plugins except flash</a><p>
1381
-We cannot use the <a class="ulink" href="http://www.oxymoronical.com/experiments/xpcomref/applications/Firefox/3.5/components/@mozilla.org/extensions/blocklist%3B1" target="_top">
1382
-@mozilla.org/extensions/blocklist;1</a> service, because we
1383
-actually want to stop plugins from ever entering the browser's process space
1384
-and/or executing code (for example, AV plugins that collect statistics/analyze
1385
-URLs, magical toolbars that phone home or "help" the user, Skype buttons that
1386
-ruin our day, and censorship filters). Hence we rolled our own.
1387
-     </p></li><li class="listitem"><a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0006-Make-content-pref-service-memory-only-clearable.patch" target="_top">Make content-prefs service memory only</a><p>
1388
-This patch prevents random URLs from being inserted into content-prefs.sqlite in
1389
-the profile directory as content prefs change (includes site-zoom and perhaps
1390
-other site prefs?).
1391
-     </p></li><li class="listitem"><a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0007-Make-Tor-Browser-exit-when-not-launched-from-Vidalia.patch" target="_top">Make Tor Browser exit when not launched from Vidalia</a><p>
1392
-
1393
-It turns out that on Windows 7 and later systems, the Taskbar attempts to
1394
-automatically learn the most frequent apps used by the user, and it recognizes
1395
-Tor Browser as a separate app from Vidalia. This can cause users to try to
1396
-launch Tor Browser without Vidalia or a Tor instance running. Worse, the Tor
1397
-Browser will automatically find their default Firefox profile, and properly
1398
-connect directly without using Tor. This patch is a simple hack to cause Tor
1399
-Browser to immediately exit in this case.
1457
+     </p></li></ol></div></div></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="BuildSecurity"></a>5. Build Security and Package Integrity</h2></div></div></div><p>
1400 1458
 
1401
-     </p></li><li class="listitem"><a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0008-Disable-SSL-Session-ID-tracking.patch" target="_top">Disable SSL Session ID tracking</a><p>
1459
+In the age of state-sponsored malware, <a class="ulink" href="https://blog.torproject.org/blog/deterministic-builds-part-one-cyberwar-and-global-compromise" target="_top">we
1460
+believe</a> it is impossible to expect to keep a single build machine or
1461
+software signing key secure, given the class of adversaries that Tor has to
1462
+contend with. For this reason, we have deployed a build system
1463
+that allows anyone to use our source code to reproduce byte-for-byte identical
1464
+binary packages to the ones that we distribute.
1402 1465
 
1403
-This patch is a simple 1-line hack to prevent SSL connections from caching
1404
-(and then later transmitting) their Session IDs. There was no preference to
1405
-govern this behavior, so we had to hack it by altering the SSL new connection
1406
-defaults.
1466
+  </p><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idp37001088"></a>5.1. Achieving Binary Reproducibility</h3></div></div></div><p>
1407 1467
 
1408
-     </p></li><li class="listitem"><a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0009-Provide-an-observer-event-to-close-persistent-connec.patch" target="_top">Provide an observer event to close persistent connections</a><p>
1468
+The GNU toolchain has been working on providing reproducible builds for some
1469
+time, however a large software project such as Firefox typically ends up
1470
+embedding a large number of details about the machine it was built on, both
1471
+intentionally and inadvertently. Additionally, manual changes to the build
1472
+machine configuration can accumulate over time and are difficult for others to
1473
+replicate externally, which leads to difficulties with binary reproducibility. 
1409 1474
 
1410
-This patch creates an observer event in the HTTP connection manager to close
1411
-all keep-alive connections that still happen to be open. This event is emitted
1412
-by the <a class="link" href="#new-identity" title="4.7. Long-Term Unlinkability via &quot;New Identity&quot; button">New Identity</a> button.
1413
-
1414
-     </p></li><li class="listitem"><a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0010-Limit-device-and-system-specific-CSS-Media-Queries.patch" target="_top">Limit Device and System Specific Media Queries</a><p>
1415
-
1416
-<a class="ulink" href="https://developer.mozilla.org/en-US/docs/CSS/Media_queries" target="_top">CSS
1417
-Media Queries</a> have a fingerprinting capability approaching that of
1418
-Javascript. This patch causes such Media Queries to evaluate as if the device
1419
-resolution was equal to the content window resolution.
1420
-
1421
-     </p></li><li class="listitem"><a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0011-Limit-the-number-of-fonts-per-document.patch" target="_top">Limit the number of fonts per document</a><p>
1422
-
1423
-Font availability can be <a class="ulink" href="http://flippingtypical.com/" target="_top">queried by
1424
-CSS and Javascript</a> and is a fingerprinting vector. This patch limits
1425
-the number of times CSS and Javascript can cause font-family rules to
1426
-evaluate. Remote @font-face fonts are exempt from the limits imposed by this
1427
-patch, and remote fonts are given priority over local fonts whenever both
1428
-appear in the same font-family rule. We do this by explicitly altering the
1429
-nsRuleNode rule represenation itself to remove the local font families before
1430
-the rule hits the font renderer.
1475
+   </p><p>
1476
+For this reason, we decided to leverage the work done by the <a class="ulink" href="http://gitian.org/" target="_top">Gitian Project</a> from the Bitcoin community.
1477
+Gitian is a wrapper around Ubuntu's virtualization tools that allows you to
1478
+specify an Ubuntu version, architecture, a set of additional packages, a set
1479
+of input files, and a bash build scriptlet in an YAML document called a
1480
+"Gitian Descriptor". This document is used to install a qemu-kvm image, and
1481
+execute your build scriptlet inside it.
1482
+   </p><p>
1431 1483
 
1432
-     </p></li><li class="listitem"><a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0012-Rebrand-Firefox-to-TorBrowser.patch" target="_top">Rebrand Firefox to Tor Browser</a><p>
1484
+We have created a <a class="ulink" href="https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/refs/heads/master" target="_top">set
1485
+of wrapper scripts</a> around Gitian to automate dependency download and
1486
+authentication, as well as transfer intermediate build outputs between the
1487
+stages of the build process. Because Gitian creates an Ubuntu build
1488
+environment, we must use cross-compilation to create packages for Windows and
1489
+Mac OS. For Windows, we use mingw-w64 as our cross compiler. For Mac OS, we
1490
+use toolchain4 in combination with a binary redistribution of the Mac OS 10.6
1491
+SDK.
1433 1492
 
1434
-This patch updates our branding in compliance with Mozilla's trademark policy.
1493
+   </p><p>
1435 1494
 
1436
-     </p></li><li class="listitem"><a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0013-Make-Download-manager-memory-only.patch" target="_top">Make Download Manager Memory Only</a><p>
1495
+The use of the Gitian system eliminates build non-determinism by normalizing
1496
+the build environment's hostname, username, build path, uname output,
1497
+toolchain versions, and time. On top of what Gitian provides, we also had to
1498
+address the following additional sources of non-determinism:
1437 1499
 
1438
-This patch prevents disk leaks from the download manager. The original
1439
-behavior is to write the download history to disk and then delete it, even if
1440
-you disable download history from your Firefox preferences.
1500
+   </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem">Filesystem and archive reordering
1501
+    <p>
1441 1502
 
1442
-     </p></li><li class="listitem"><a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0014-Add-DDG-and-StartPage-to-Omnibox.patch" target="_top">Add DDG and StartPage to Omnibox</a><p>
1503
+The most prevalent source of non-determinism in the components of Tor Browser
1504
+by far was various ways that archives (such as zip, tar, jar/ja, DMG, and
1505
+Firefox manifest lists) could be reordered. Many file archivers walk the
1506
+filesystem in inode structure order by default, which will result in ordering
1507
+differences between two different archive invocations, especially on machines
1508
+of different disk and hardware configurations.
1443 1509
 
1444
-This patch adds DuckDuckGo and StartPage to the Search Box, and sets our
1445
-default search engine to StartPage. We deployed this patch due to excessive
1446
-Captchas and complete 403 bans from Google.
1510
+    </p><p>
1447 1511
 
1448
-     </p></li><li class="listitem"><a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0015-Make-nsICacheService.EvictEntries-synchronous.patch" target="_top">Make nsICacheService.EvictEntries() Synchronous</a><p>
1512
+The fix for this is to perform an additional sorting step on the input list
1513
+for archives, but care must be taken to instruct libc and other sorting routines
1514
+to use a fixed locale to determine lexicographic ordering, or machines with
1515
+different locale settings will produce different sort results. We chose the
1516
+'C' locale for this purpose. We created wrapper scripts for <a class="ulink" href="https://gitweb.torproject.org/builders/tor-browser-bundle.git/blob/HEAD:/gitian/build-helpers/dtar.sh" target="_top">tar</a>,
1517
+<a class="ulink" href="https://gitweb.torproject.org/builders/tor-browser-bundle.git/blob/HEAD:/gitian/build-helpers/dzip.sh" target="_top">zip</a>,
1518
+and <a class="ulink" href="https://gitweb.torproject.org/builders/tor-browser-bundle.git/blob/HEAD:/gitian/build-helpers/ddmg.sh" target="_top">DMG</a>
1519
+to aid in reproducible archive creation.
1449 1520
 
1450
-This patch eliminates a race condition with "New Identity". Without it,
1451
-cache-based Evercookies survive for up to a minute after clearing the cache
1452
-on some platforms.
1521
+    </p></li><li class="listitem">Uninitialized memory in toolchain/archivers
1522
+    <p>
1453 1523
 
1454
-     </p></li><li class="listitem"><a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0016-Prevent-WebSocket-DNS-leak.patch" target="_top">Prevent WebSockets DNS Leak</a><p>
1524
+We ran into difficulties with both binutils and the DMG archive script using
1525
+uninitialized memory in certain data structures that ended up written to disk.
1526
+Our binutils fixes were merged upstream, but the DMG archive fix remains an
1527
+<a class="ulink" href="https://gitweb.torproject.org/builders/tor-browser-bundle.git/blob/HEAD:/gitian/patches/libdmg.patch" target="_top">independent
1528
+patch</a>.
1455 1529
 
1456
-This patch prevents a DNS leak when using WebSockets. It also prevents other
1457
-similar types of DNS leaks.
1530
+    </p></li><li class="listitem">Fine-grained timestamps and timezone leaks
1531
+    <p>
1458 1532
 
1459
-     </p></li><li class="listitem"><a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0017-Randomize-HTTP-request-order-and-pipeline-depth.patch" target="_top">Randomize HTTP pipeline order and depth</a><p>
1460
-As an 
1461
-<a class="ulink" href="https://blog.torproject.org/blog/experimental-defense-website-traffic-fingerprinting" target="_top">experimental
1462
-defense against Website Traffic Fingerprinting</a>, we patch the standard
1463
-HTTP pipelining code to randomize the number of requests in a
1464
-pipeline, as well as their order.
1465
-     </p></li><li class="listitem"><a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0018-Emit-observer-event-to-filter-the-Drag-Drop-url-list.patch" target="_top">Emit
1466
-an observer event to filter the Drag and Drop URL list</a><p>
1533
+The standard way of controlling timestamps in Gitian is to use libfaketime,
1534
+which hooks time-related library calls to provide a fixed timestamp. However,
1535
+libfaketime does not spoof the millisecond and microsecond components of
1536
+timestamps, which found their way into pyc files and also in explicit Firefox
1537
+build process timestamp embedding.
1538
+    </p><p>
1467 1539
 
1468
-This patch allows us to block external Drag and Drop events from Torbutton.
1469
-We need to block Drag and Drop because Mac OS and Ubuntu both immediately load
1470
-any URLs they find in your drag buffer before you even drop them (without
1471
-using your browser's proxy settings, of course). This can lead to proxy bypass
1472
-during user activity that is as basic as holding down the mouse button for
1473
-slightly too long while clicking on an image link.
1540
+We addressed the Firefox issues with direct patches to their build process,
1541
+which have since been merged. However, pyc timestamps had to be address with 
1542
+an additional <a class="ulink" href="https://gitweb.torproject.org/builders/tor-browser-bundle.git/blob/HEAD:/gitian/build-helpers/pyc-timestamp.sh" target="_top">helper
1543
+script</a>.
1544
+    </p><p>
1474 1545
 
1475
-     </p></li><li class="listitem"><a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0019-Add-mozIThirdPartyUtil.getFirstPartyURI-API.patch" target="_top">Add mozIThirdPartyUtil.getFirstPartyURI() API</a><p>
1546
+The timezone leaks were addressed by setting the <span class="command"><strong>TZ</strong></span>
1547
+environment variable to UTC in our descriptors.
1476 1548
 
1477
-This patch provides an API that allows us to more easily isolate identifiers
1478
-to the URL bar domain.
1549
+    </p></li><li class="listitem">Deliberately generated entropy
1550
+    <p>
1479 1551
 
1480
-     </p></li><li class="listitem"><a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0020-Add-canvas-image-extraction-prompt.patch" target="_top">Add canvas image extraction prompt</a><p>
1552
+In two circumstances, deliberately generated entropy was introduced in various
1553
+components of the build process. First, the BuildID Debuginfo identifier
1554
+(which associates detached debug files with their corresponding stripped
1555
+executables) was introducing entropy from some unknown source. We removed this
1556
+header using objcopy invocations in our build scriptlets, and opted to use GNU
1557
+DebugLink instead of BuildID for this association.
1481 1558
 
1482
-This patch prompts the user before returning canvas image data. Canvas image
1483
-data can be used to create an extremely stable, high-entropy fingerprint based
1484
-on the unique rendering behavior of video cards, OpenGL behavior,
1485
-system fonts, and supporting library versions.
1559
+    </p><p>
1486 1560
 
1487
-     </p></li><li class="listitem"><a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0021-Return-client-window-coordinates-for-mouse-event-scr.patch" target="_top">Return client window coordinates for mouse events</a><p>
1561
+Second, on Linux, Firefox builds detached signatures of its cryptographic
1562
+libraries using a temporary key for FIPS-140 certification. A rather insane
1563
+subsection of the FIPS-140 certification standard requires that you distribute
1564
+signatures for all of your cryptographic libraries. The Firefox build process
1565
+meets this requirement by generating a temporary key, using it to sign the
1566
+libraries, and discarding the private portion of that key. Because there are
1567
+many other ways to intercept the crypto outside of modifying the actual DLL
1568
+images, we opted to simply remove these signature files from distribution.
1569
+There simply is no way to verify code integrity on a running system without
1570
+both OS and co-processor assistance. Download package signatures make sense of
1571
+course, but we handle those another way (as mentioned above).
1488 1572
 
1489
-This patch causes mouse events to return coordinates relative to the content
1490
-window instead of the desktop.
1491 1573
 
1492
-     </p></li><li class="listitem"><a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0022-Do-not-expose-physical-screen-info.-via-window-and-w.patch" target="_top">Do not expose physical screen info to window.screen</a><p>
1574
+    </p></li><li class="listitem">LXC-specific leaks
1575
+   <p>
1493 1576
 
1494
-This patch causes window.screen to return the display resolution size of the
1495
-content window instead of the desktop resolution size.
1577
+Gitian provides an option to use LXC containers instead of full qemu-kvm
1578
+virtualization. Unfortunately, these containers can allow additional details
1579
+about the host OS to leak. In particular, umask settings as well as the
1580
+hostname and Linux kernel version can leak from the host OS into the LXC
1581
+container. We addressed umask by setting it explicitly in our Gitian
1582
+descriptor scriptlet, and addressed the hostname and kernel version leaks by
1583
+directly patching the aspects of the Firefox build process that included this
1584
+information into the build.
1585
+   </p></li></ol></div></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idp37036336"></a>5.2. Package Signatures and Verification</h3></div></div></div><p>
1586
+
1587
+The build process produces a single sha256sums.txt file that contains a sorted
1588
+list the SHA-256 hashes of every package produced for that build version. Each
1589
+official builder uploads this file and a GPG signature of it to a directory
1590
+on a Tor Project's web server. The build scripts have an optional matching
1591
+step that downloads these signatures, verifies them, and ensures that the
1592
+local builds match this file.
1496 1593
 
1497
-     </p></li><li class="listitem"><a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0023-Do-not-expose-system-colors-to-CSS-or-canvas.patch" target="_top">Do not expose system colors to CSS or canvas</a><p>
1594
+    </p><p>
1498 1595
 
1499
-This patch prevents CSS and Javascript from discovering your desktop color
1500
-scheme and/or theme.
1596
+When builds are published officially, the single sha256sums.txt file is
1597
+accompanied by a detached GPG signature from each official builder that
1598
+produced a matching build. The packages are additionally signed with detached
1599
+GPG signatures from an official signing key.
1501 1600
 
1502
-     </p></li><li class="listitem"><a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0024-Isolate-the-Image-Cache-per-url-bar-domain.patch" target="_top">Isolate the Image Cache per url bar domain</a><p>
1601
+    </p><p>
1503 1602
 
1504
-This patch prevents cached images from being used to store third party tracking
1505
-identifiers.
1603
+The fact that the entire set of packages for a given version can be
1604
+authenticated by a single hash of the sha256sums.txt file will also allow us
1605
+to create a number of auxiliary authentication mechanisms for our packages,
1606
+beyond just trusting a single offline build machine and a single cryptographic
1607
+key's integrity. Interesting examples include providing multiple independent
1608
+cryptographic signatures for packages, listing the package hashes in the Tor
1609
+consensus, and encoding the package hashes in the Bitcoin blockchain.
1506 1610
 
1507
-     </p></li><li class="listitem"><a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0025-nsIHTTPChannel.redirectTo-API.patch" target="_top">nsIHTTPChannel.redirectTo() API</a><p>
1611
+     </p><p>
1508 1612
 
1509
-This patch provides HTTPS-Everywhere with an API to perform redirections more
1510
-securely and without addon conflicts.
1613
+At the time of this writing, we do not yet support native code signing for Mac
1614
+OS or Windows. Because these signatures are embedded in the actual packages,
1615
+and by their nature are based on non-public key material, providing native
1616
+code-signed packages while still preserving ease of reproducibility
1617
+verification has not yet been achieved.
1511 1618
 
1512
-     </p></li><li class="listitem"><a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0026-Isolate-DOM-storage-to-first-party-URI.patch" target="_top">Isolate DOM Storage to first party URI</a><p>
1619
+    </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idp37040272"></a>5.3. Anonymous Verification</h3></div></div></div><p>
1513 1620
 
1514
-This patch prevents DOM Storage from being used to store third party tracking
1515
-identifiers.
1621
+Due to the fact that bit-identical packages can be produced by anyone, the
1622
+security of this build system extends beyond the security of the official
1623
+build machines. In fact, it is still possible for build integrity to be
1624
+achieved even if all official build machines are compromised. 
1516 1625
 
1517
-     </p></li><li class="listitem"><a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0027-Remove-This-plugin-is-disabled-barrier.patch" target="_top">Remove
1518
-"This plugin is disabled" barrier</a><p>
1626
+    </p><p>
1519 1627
 
1520
-This patch removes a barrier that was informing users that plugins were
1521
-disabled and providing them with a link to enable them. We felt this was poor
1522
-user experience, especially since the barrier was displayed even for sites
1523
-with dual Flash+HTML5 video players, such as YouTube.
1628
+By default, all tor-specific dependencies and inputs to the build process are
1629
+downloaded over Tor, which allows build verifiers to remain anonymous and
1630
+hidden. Because of this, any individual can use our anonymity network to
1631
+privately download our source code, verify it against public signed, audited,
1632
+and mirrored git repositories, and reproduce our builds exactly, without being
1633
+subject to targeted attacks. If they notice any differences, they can alert
1634
+the public builders/signers, hopefully using a pseudonym or our anonymous
1635
+bugtracker account, to avoid revealing the fact that they are a build
1636
+verifier.
1524 1637
 
1525
-     </p></li></ol></div></div></div><div class="appendix" title="A. Towards Transparency in Navigation Tracking"><h2 class="title" style="clear: both"><a id="Transparency"></a>A. Towards Transparency in Navigation Tracking</h2><p>
1638
+   </p></div></div><div class="appendix"><h2 class="title" style="clear: both"><a id="Transparency"></a>A. Towards Transparency in Navigation Tracking</h2><p>
1526 1639
 
1527 1640
 The <a class="link" href="#privacy" title="2.2. Privacy Requirements">privacy properties</a> of Tor Browser are based
1528 1641
 upon the assumption that link-click navigation indicates user consent to
... ...
@@ -1554,7 +1667,7 @@ also describe auditable alternatives and promising web draft standards that woul
1554 1667
 preserve this functionality while still providing transparency when tracking is
1555 1668
 occurring. 
1556 1669
 
1557
-</p><div class="sect1" title="A.1. Deprecation Wishlist"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="deprecate"></a>A.1. Deprecation Wishlist</h2></div></div></div><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem">The Referer Header
1670
+</p><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="deprecate"></a>A.1. Deprecation Wishlist</h2></div></div></div><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem">The Referer Header
1558 1671
   <p>
1559 1672
 
1560 1673
 We haven't disabled or restricted the Referer ourselves because of the
... ...
@@ -1617,7 +1730,7 @@ possible for us to <a class="ulink" href="https://trac.torproject.org/projects/t
1617 1730
 ourselves</a>, as they are comparatively rare and can be handled with site
1618 1731
 permissions.
1619 1732
 
1620
-   </p></li></ol></div></div><div class="sect1" title="A.2. Promising Standards"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="idp5896048"></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>
1733
+   </p></li></ol></div></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="idp37071376"></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>
1621 1734
 
1622 1735
 Web-Send is a browser-based link sharing and federated login widget that is
1623 1736
 designed to operate without relying on third-party tracking or abusing other
1624 1737