Update design doc with FF17-ESR changes.
Mike Perry

Mike Perry commited on 2013-02-23 05:06:58
Zeige 2 geänderte Dateien mit 781 Einfügungen und 549 Löschungen.

... ...
@@ -1,12 +1,10 @@
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.75.2" /></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">Dec 28 2011</p></div></div><hr /></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="#id2619754">1. Introduction</a></span></dt><dd><dl><dt><span class="sect2"><a href="#adversary">1.1. Adversary Model</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="#Implementation">3. Implementation</a></span></dt><dd><dl><dt><span class="sect2"><a href="#proxy-obedience">3.1. Proxy Obedience</a></span></dt><dt><span class="sect2"><a href="#state-separation">3.2. State Separation</a></span></dt><dt><span class="sect2"><a href="#disk-avoidance">3.3. Disk Avoidance</a></span></dt><dt><span class="sect2"><a href="#app-data-isolation">3.4. Application Data Isolation</a></span></dt><dt><span class="sect2"><a href="#identifier-linkability">3.5. Cross-Origin Identifier Unlinkability</a></span></dt><dt><span class="sect2"><a href="#fingerprinting-linkability">3.6. Cross-Origin Fingerprinting Unlinkability</a></span></dt><dt><span class="sect2"><a href="#new-identity">3.7. Long-Term Unlinkability via "New Identity" button</a></span></dt><dt><span class="sect2"><a href="#click-to-play">3.8. Click-to-play for plugins and invasive content</a></span></dt><dt><span class="sect2"><a href="#firefox-patches">3.9. Description of Firefox Patches</a></span></dt></dl></dd><dt><span class="sect1"><a href="#Packaging">4. Packaging</a></span></dt><dd><dl><dt><span class="sect2"><a href="#build-security">4.1. Build Process Security</a></span></dt><dt><span class="sect2"><a href="#addons">4.2. External Addons</a></span></dt><dt><span class="sect2"><a href="#prefs">4.3. Pref Changes</a></span></dt><dt><span class="sect2"><a href="#update-mechanism">4.4. Update Security</a></span></dt></dl></dd><dt><span class="sect1"><a href="#Testing">5. Testing</a></span></dt><dd><dl><dt><span class="sect2"><a href="#SingleStateTesting">5.1. Single state testing</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="id2619754"></a>1. Introduction</h2></div></div></div><p>
2
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
3
+<html xmlns="http://www.w3.org/1999/xhtml"><head><title>The Design and Implementation of the Tor Browser [DRAFT]</title><meta name="generator" content="DocBook XSL Stylesheets V1.75.2"/></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"/>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">Feb 23 2013</p></div></div><hr/></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="#idp3348944">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="#adversarygoals">3.1. Adversary Goals</a></span></dt><dt><span class="sect2"><a href="#adversarypositioning">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="#firefox-patches">4.8. 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></dl></div><div class="sect1" title="1. Introduction"><div class="titlepage"><div><div><h2 class="title"><a id="idp3348944"/>1. Introduction</h2></div></div></div><p>
4 4
 
5
-This document describes the <a class="link" href="#adversary" title="1.1. Adversary Model">adversary model</a>,
6
-<a class="link" href="#DesignRequirements" title="2. Design Requirements and Philosophy">design requirements</a>,
7
-<a class="link" href="#Implementation" title="3. Implementation">implementation</a>, <a class="link" href="#Packaging" title="4. Packaging">packaging</a> and <a class="link" href="#Testing" title="5. Testing">testing
8
-procedures</a> of the Tor Browser. It is
9
-current as of Tor Browser 2.2.35-1 and Torbutton 1.4.5.
5
+This document describes the <a class="link" href="#adversary" title="3. Adversary Model">adversary model</a>,
6
+<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 2.3.25-4
7
+and Torbutton 1.5.0.
10 8
 
11 9
   </p><p>
12 10
 
... ...
@@ -15,182 +13,27 @@ describe a reference implementation of a Private Browsing Mode that defends
15 13
 against active network adversaries, in addition to the passive forensic local
16 14
 adversary currently addressed by the major browsers.
17 15
 
18
-  </p><div class="sect2" title="1.1. Adversary Model"><div class="titlepage"><div><div><h3 class="title"><a id="adversary"></a>1.1. Adversary Model</h3></div></div></div><p>
16
+  </p><div class="sect2" title="1.1. Browser Component Overview"><div class="titlepage"><div><div><h3 class="title"><a id="components"/>1.1. Browser Component Overview</h3></div></div></div><p>
19 17
 
20
-A Tor web browser adversary has a number of goals, capabilities, and attack
21
-types that can be used to guide us towards a set of requirements for the
22
-Tor Browser. Let's start with the goals.
23
-
24
-   </p><div class="sect3" title="Adversary Goals"><div class="titlepage"><div><div><h4 class="title"><a id="adversarygoals"></a>Adversary Goals</h4></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 
25
-Tor, causing the user to directly connect to an IP of the adversary's
26
-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
27
-happily settle for the ability to correlate something a user did via Tor with
28
-their non-Tor activity. This can be done with cookies, cache identifiers,
29
-javascript events, and even CSS. Sometimes the fact that a user uses Tor may
30
-be enough for some authorities.</p></li><li class="listitem"><span class="command"><strong>History disclosure</strong></span><p>
31
-The adversary may also be interested in history disclosure: the ability to
32
-query a user's history to see if they have issued certain censored search
33
-queries, or visited censored sites.
34
-     </p></li><li class="listitem"><span class="command"><strong>Location information</strong></span><p>
35
-
36
-Location information such as timezone and locality can be useful for the
37
-adversary to determine if a user is in fact originating from one of the
38
-regions they are attempting to control, or to zero-in on the geographical
39
-location of a particular dissident or whistleblower.
40
-
41
-     </p></li><li class="listitem"><span class="command"><strong>Miscellaneous anonymity set reduction</strong></span><p>
42
-
43
-Anonymity set reduction is also useful in attempting to zero in on a
44
-particular individual. If the dissident or whistleblower is using a rare build
45
-of Firefox for an obscure operating system, this can be very useful
46
-information for tracking them down, or at least <a class="link" href="#fingerprinting">tracking their activities</a>.
47
-
48
-     </p></li><li class="listitem"><span class="command"><strong>History records and other on-disk
49
-information</strong></span><p>
50
-In some cases, the adversary may opt for a heavy-handed approach, such as
51
-seizing the computers of all Tor users in an area (especially after narrowing
52
-the field by the above two pieces of information). History records and cache
53
-data are the primary goals here.
54
-     </p></li></ol></div></div><div class="sect3" title="Adversary Capabilities - Positioning"><div class="titlepage"><div><div><h4 class="title"><a id="adversarypositioning"></a>Adversary Capabilities - Positioning</h4></div></div></div><p>
55
-The adversary can position themselves at a number of different locations in
56
-order to execute their attacks.
57
-    </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><span class="command"><strong>Exit Node or Upstream Router</strong></span><p>
58
-The adversary can run exit nodes, or alternatively, they may control routers
59
-upstream of exit nodes. Both of these scenarios have been observed in the
60
-wild.
61
-     </p></li><li class="listitem"><span class="command"><strong>Ad servers and/or Malicious Websites</strong></span><p>
62
-The adversary can also run websites, or more likely, they can contract out
63
-ad space from a number of different ad servers and inject content that way. For
64
-some users, the adversary may be the ad servers themselves. It is not
65
-inconceivable that ad servers may try to subvert or reduce a user's anonymity 
66
-through Tor for marketing purposes.
67
-     </p></li><li class="listitem"><span class="command"><strong>Local Network/ISP/Upstream Router</strong></span><p>
68
-The adversary can also inject malicious content at the user's upstream router
69
-when they have Tor disabled, in an attempt to correlate their Tor and Non-Tor
70
-activity.
71
-     </p></li><li class="listitem"><span class="command"><strong>Physical Access</strong></span><p>
72
-Some users face adversaries with intermittent or constant physical access.
73
-Users in Internet cafes, for example, face such a threat. In addition, in
74
-countries where simply using tools like Tor is illegal, users may face
75
-confiscation of their computer equipment for excessive Tor usage or just
76
-general suspicion.
77
-     </p></li></ol></div></div><div class="sect3" title="Adversary Capabilities - Attacks"><div class="titlepage"><div><div><h4 class="title"><a id="attacks"></a>Adversary Capabilities - Attacks</h4></div></div></div><p>
78
-
79
-The adversary can perform the following attacks from a number of different 
80
-positions to accomplish various aspects of their goals. It should be noted
81
-that many of these attacks (especially those involving IP address leakage) are
82
-often performed by accident by websites that simply have Javascript, dynamic 
83
-CSS elements, and plugins. Others are performed by ad servers seeking to
84
-correlate users' activity across different IP addresses, and still others are
85
-performed by malicious agents on the Tor network and at national firewalls.
86
-
87
-    </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><span class="command"><strong>Read and insert identifiers</strong></span><p>
88
-
89
-The browser contains multiple facilities for storing identifiers that the
90
-adversary creates for the purposes of tracking users. These identifiers are
91
-most obviously cookies, but also include HTTP auth, DOM storage, cached
92
-scripts and other elements with embedded identifiers, client certificates, and
93
-even TLS Session IDs.
94
-
95
-     </p><p>
96
-
97
-An adversary in a position to perform MITM content alteration can inject
98
-document content elements to both read and inject cookies for arbitrary
99
-domains. In fact, even many "SSL secured" websites are vulnerable to this sort of
100
-<a class="ulink" href="http://seclists.org/bugtraq/2007/Aug/0070.html" target="_top">active
101
-sidejacking</a>. In addition, the ad networks of course perform tracking
102
-with cookies as well.
103
-
104
-     </p></li><li class="listitem"><a id="fingerprinting"></a><span class="command"><strong>Fingerprint users based on browser
105
-attributes</strong></span><p>
106
-
107
-There is an absurd amount of information available to websites via attributes
108
-of the browser. This information can be used to reduce anonymity set, or even
109
-uniquely fingerprint individual users. Fingerprinting is an intimidating
110
-problem to attempt to tackle, especially without a metric to determine or at
111
-least intuitively understand and estimate which features will most contribute
112
-to linkability between visits.
113
-
114
-</p><p>
115
-
116
-The <a class="ulink" href="https://panopticlick.eff.org/about.php" target="_top">Panopticlick study
117
-done</a> by the EFF uses the actual entropy - the number of identifying
118
-bits of information encoded in browser properties - as this metric. Their
119
-<a class="ulink" href="https://wiki.mozilla.org/Fingerprinting#Data" target="_top">result data</a>
120
-is definitely useful, and the metric is probably the appropriate one for
121
-determining how identifying a particular browser property is. However, some
122
-quirks of their study means that they do not extract as much information as
123
-they could from display information: they only use desktop resolution and do
124
-not attempt to infer the size of toolbars. In the other direction, they may be
125
-over-counting in some areas, as they did not compute joint entropy over
126
-multiple attributes that may exhibit a high degree of correlation. Also, new
127
-browser features are added regularly, so the data should not be taken as
128
-final.
18
+The Tor Browser is based on <a class="ulink" href="https://www.mozilla.org/en-US/firefox/organizations/">Mozilla's Extended
19
+Support Release (ESR) Firefox branch</a>. We have a <a class="link" href="#firefox-patches" title="4.8. 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">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">change
24
+a number of Firefox preferences</a> from their defaults.
129 25
 
130 26
    </p><p>
131 27
 
132
-Despite the uncertainty, all fingerprinting attacks leverage the following
133
-attack vectors:
134
-
135
-     </p><div class="orderedlist"><ol class="orderedlist" type="a"><li class="listitem"><span class="command"><strong>Observing Request Behavior</strong></span><p>
136
-
137
-Properties of the user's request behavior comprise the bulk of low-hanging
138
-fingerprinting targets. These include: User agent, Accept-* headers, pipeline
139
-usage, and request ordering. Additionally, the use of custom filters such as
140
-AdBlock and other privacy filters can be used to fingerprint request patterns
141
-(as an extreme example).
142
-
143
-     </p></li><li class="listitem"><span class="command"><strong>Inserting Javascript</strong></span><p>
144
-
145
-Javascript can reveal a lot of fingerprinting information. It provides DOM
146
-objects such as window.screen and window.navigator to extract information
147
-about the useragent. 
148
-
149
-Also, Javascript can be used to query the user's timezone via the
150
-<code class="function">Date()</code> object, <a class="ulink" href="https://www.khronos.org/registry/webgl/specs/1.0/#5.13" target="_top">WebGL</a> can
151
-reveal information about the video card in use, and high precision timing
152
-information can be used to <a class="ulink" href="http://w2spconf.com/2011/papers/jspriv.pdf" target="_top">fingerprint the CPU and
153
-interpreter speed</a>. In the future, new JavaScript features such as
154
-<a class="ulink" href="http://w3c-test.org/webperf/specs/ResourceTiming/" target="_top">Resource
155
-Timing</a> may leak an unknown amount of network timing related
156
-information.
157
-
158
-
159
-
160
-     </p></li><li class="listitem"><span class="command"><strong>Inserting Plugins</strong></span><p>
161
-
162
-The Panopticlick project found that the mere list of installed plugins (in
163
-navigator.plugins) was sufficient to provide a large degree of
164
-fingerprintability. Additionally, plugins are capable of extracting font lists,
165
-interface addresses, and other machine information that is beyond what the
166
-browser would normally provide to content. In addition, plugins can be used to
167
-store unique identifiers that are more difficult to clear than standard
168
-cookies.  <a class="ulink" href="http://epic.org/privacy/cookies/flash.html" target="_top">Flash-based
169
-cookies</a> fall into this category, but there are likely numerous other
170
-examples. Beyond fingerprinting, plugins are also abysmal at obeying the proxy
171
-settings of the browser. 
172
-
173
-
174
-     </p></li><li class="listitem"><span class="command"><strong>Inserting CSS</strong></span><p>
28
+To help protect against potential Tor Exit Node eavesdroppers, we include
29
+<a class="ulink" href="https://www.eff.org/https-everywhere">HTTPS-Everywhere</a>. To
30
+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/">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/">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">several
34
+extension preferences</a> from their defaults.
175 35
 
176
-<a class="ulink" href="https://developer.mozilla.org/En/CSS/Media_queries" target="_top">CSS media
177
-queries</a> can be inserted to gather information about the desktop size,
178
-widget size, display type, DPI, user agent type, and other information that
179
-was formerly available only to Javascript.
180
-
181
-     </p></li></ol></div></li><li class="listitem"><span class="command"><strong>Remotely or locally exploit browser and/or
182
-OS</strong></span><p>
183
-
184
-Last, but definitely not least, the adversary can exploit either general
185
-browser vulnerabilities, plugin vulnerabilities, or OS vulnerabilities to
186
-install malware and surveillance software. An adversary with physical access
187
-can perform similar actions. Regrettably, this last attack capability is
188
-outside of our ability to defend against, but it is worth mentioning for
189
-completeness. <a class="ulink" href="http://tails.boum.org/contribute/design/" target="_top">The Tails
190
-system</a> however can provide some limited defenses against this
191
-adversary.
192
-
193
-     </p></li></ol></div></div></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>
36
+   </p></div></div><div class="sect1" title="2. Design Requirements and Philosophy"><div class="titlepage"><div><div><h2 class="title"><a id="DesignRequirements"/>2. Design Requirements and Philosophy</h2></div></div></div><p>
194 37
 
195 38
 The Tor Browser Design Requirements are meant to describe the properties of a
196 39
 Private Browsing Mode that defends against both network and local forensic
... ...
@@ -214,9 +57,9 @@ browser distribution.
214 57
       The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
215 58
       NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
216 59
       "OPTIONAL" in this document are to be interpreted as described in
217
-      <a class="ulink" href="https://www.ietf.org/rfc/rfc2119.txt" target="_top">RFC 2119</a>.
60
+      <a class="ulink" href="https://www.ietf.org/rfc/rfc2119.txt">RFC 2119</a>.
218 61
 
219
-  </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>
62
+  </p><div class="sect2" title="2.1. Security Requirements"><div class="titlepage"><div><div><h3 class="title"><a id="security"/>2.1. Security Requirements</h3></div></div></div><p>
220 63
 
221 64
 The security requirements are primarily concerned with ensuring the safe use
222 65
 of Tor. Violations in these properties typically result in serious risk for
... ...
@@ -224,13 +67,13 @@ the user in terms of immediate deanonymization and/or observability. With
224 67
 respect to browser support, security requirements are the minimum properties
225 68
 in order for Tor to support the use of a particular browser.
226 69
 
227
-   </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><a class="link" href="#proxy-obedience" title="3.1. Proxy Obedience"><span class="command"><strong>Proxy
70
+   </p><div class="orderedlist"><ol class="orderedlist"><li class="listitem"><a class="link" href="#proxy-obedience" title="4.1. Proxy Obedience"><span class="command"><strong>Proxy
228 71
 Obedience</strong></span></a><p>The browser
229
-MUST NOT bypass Tor proxy settings for any content.</p></li><li class="listitem"><a class="link" href="#state-separation" title="3.2. State Separation"><span class="command"><strong>State
72
+MUST NOT bypass Tor proxy settings for any content.</p></li><li class="listitem"><a class="link" href="#state-separation" title="4.2. State Separation"><span class="command"><strong>State
230 73
 Separation</strong></span></a><p>The browser MUST NOT provide any stored state to the content window
231 74
 from other browsers or other browsing modes, including shared state from
232 75
 plugins, machine identifiers, and TLS session state.
233
-</p></li><li class="listitem"><a class="link" href="#disk-avoidance" title="3.3. Disk Avoidance"><span class="command"><strong>Disk
76
+</p></li><li class="listitem"><a class="link" href="#disk-avoidance" title="4.3. Disk Avoidance"><span class="command"><strong>Disk
234 77
 Avoidance</strong></span></a><p>
235 78
 
236 79
 The browser MUST NOT write any information that is derived from or that
... ...
@@ -238,7 +81,7 @@ reveals browsing activity to the disk, or store it in memory beyond the
238 81
 duration of one browsing session, unless the user has explicitly opted to
239 82
 store their browsing history information to disk.
240 83
 
241
-</p></li><li class="listitem"><a class="link" href="#app-data-isolation" title="3.4. Application Data Isolation"><span class="command"><strong>Application Data
84
+</p></li><li class="listitem"><a class="link" href="#app-data-isolation" title="4.4. Application Data Isolation"><span class="command"><strong>Application Data
242 85
 Isolation</strong></span></a><p>
243 86
 
244 87
 The components involved in providing private browsing MUST be self-contained,
... ...
@@ -253,7 +96,7 @@ to permissions issues with access to swap, implementations MAY choose to leave
253 96
 it out of scope, and/or leave it to the Operating System/platform to implement
254 97
 ephemeral-keyed encrypted swap.
255 98
 
256
-</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>
99
+</p></li></ol></div></div><div class="sect2" title="2.2. Privacy Requirements"><div class="titlepage"><div><div><h3 class="title"><a id="privacy"/>2.2. Privacy Requirements</h3></div></div></div><p>
257 100
 
258 101
 The privacy requirements are primarily concerned with reducing linkability:
259 102
 the ability for a user's activity on one site to be linked with their activity
... ...
@@ -264,13 +107,13 @@ to prefer one browser over another.
264 107
    </p><p>
265 108
 
266 109
 For the purposes of the unlinkability requirements of this section as well as
267
-the descriptions in the <a class="link" href="#Implementation" title="3. Implementation">implementation
110
+the descriptions in the <a class="link" href="#Implementation" title="4. Implementation">implementation
268 111
 section</a>, a <span class="command"><strong>url bar origin</strong></span> means at least the
269 112
 second-level DNS name.  For example, for mail.google.com, the origin would be
270 113
 google.com. Implementations MAY, at their option, restrict the url bar origin
271 114
 to be the entire fully qualified domain name.
272 115
 
273
-   </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><a class="link" href="#identifier-linkability" title="3.5. Cross-Origin Identifier Unlinkability"><span class="command"><strong>Cross-Origin
116
+   </p><div class="orderedlist"><ol class="orderedlist"><li class="listitem"><a class="link" href="#identifier-linkability" title="4.5. Cross-Origin Identifier Unlinkability"><span class="command"><strong>Cross-Origin
274 117
 Identifier Unlinkability</strong></span></a><p>
275 118
 
276 119
 User activity on one url bar origin MUST NOT be linkable to their activity in
... ...
@@ -279,16 +122,17 @@ interaction or approval. This requirement specifically applies to linkability
279 122
 from stored browser identifiers, authentication tokens, and shared state. The
280 123
 requirement does not apply to linkable information the user manually submits
281 124
 to sites, or due to information submitted during manual link traversal. This
282
-functionality SHOULD NOT interfere with federated login in a substantial way.
125
+functionality SHOULD NOT interfere with interactive, click-driven federated
126
+login in a substantial way.
283 127
 
284
-  </p></li><li class="listitem"><a class="link" href="#fingerprinting-linkability" title="3.6. Cross-Origin Fingerprinting Unlinkability"><span class="command"><strong>Cross-Origin
128
+  </p></li><li class="listitem"><a class="link" href="#fingerprinting-linkability" title="4.6. Cross-Origin Fingerprinting Unlinkability"><span class="command"><strong>Cross-Origin
285 129
 Fingerprinting Unlinkability</strong></span></a><p>
286 130
 
287 131
 User activity on one url bar origin MUST NOT be linkable to their activity in
288 132
 any other url bar origin by any third party. This property specifically applies to
289 133
 linkability from fingerprinting browser behavior.
290 134
 
291
-  </p></li><li class="listitem"><a class="link" href="#new-identity" title="3.7. Long-Term Unlinkability via &quot;New Identity&quot; button"><span class="command"><strong>Long-Term
135
+  </p></li><li class="listitem"><a class="link" href="#new-identity" title="4.7. Long-Term Unlinkability via &quot;New Identity&quot; button"><span class="command"><strong>Long-Term
292 136
 Unlinkability</strong></span></a><p>
293 137
 
294 138
 The browser SHOULD provide an obvious, easy way to remove all of its
... ...
@@ -296,12 +140,12 @@ authentication tokens and browser state and obtain a fresh identity.
296 140
 Additionally, the browser SHOULD clear linkable state by default automatically
297 141
 upon browser restart, except at user option.
298 142
 
299
-  </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>
143
+  </p></li></ol></div></div><div class="sect2" title="2.3. Philosophy"><div class="titlepage"><div><div><h3 class="title"><a id="philosophy"/>2.3. Philosophy</h3></div></div></div><p>
300 144
 
301 145
 In addition to the above design requirements, the technology decisions about
302 146
 Tor Browser are also guided by some philosophical positions about technology.
303 147
 
304
-   </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><span class="command"><strong>Preserve existing user model</strong></span><p>
148
+   </p><div class="orderedlist"><ol class="orderedlist"><li class="listitem"><span class="command"><strong>Preserve existing user model</strong></span><p>
305 149
 
306 150
 The existing way that the user expects to use a browser must be preserved. If
307 151
 the user has to maintain a different mental model of how the sites they are
... ...
@@ -312,7 +156,7 @@ result. Worse, they may just stop using the browser, assuming it is broken.
312 156
 
313 157
       </p><p>
314 158
 
315
-User model breakage was one of the <a class="ulink" href="https://blog.torproject.org/blog/toggle-or-not-toggle-end-torbutton" target="_top">failures
159
+User model breakage was one of the <a class="ulink" href="https://blog.torproject.org/blog/toggle-or-not-toggle-end-torbutton">failures
316 160
 of Torbutton</a>: Even if users managed to install everything properly,
317 161
 the toggle model was too hard for the average user to understand, especially
318 162
 in the face of accumulating tabs from multiple states crossed with the current
... ...
@@ -340,20 +184,20 @@ be restricted from running automatically on every page (via click-to-play
340 184
 placeholders), and/or be sandboxed to restrict the types of system calls they
341 185
 can execute. If the user decides to craft an exemption to allow a plugin to be
342 186
 used, it MUST only apply to the top level url bar domain, and not to all sites,
343
-to reduce linkability.
187
+to reduce cross-origin fingerprinting linkability.
344 188
 
345 189
        </p></li><li class="listitem"><span class="command"><strong>Minimize Global Privacy Options</strong></span><p>
346 190
 
347
-<a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3100" target="_top">Another
348
-failure of Torbutton</a> was (and still is) the options panel. Each option
191
+<a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3100">Another
192
+failure of Torbutton</a> was the options panel. Each option
349 193
 that detectably alters browser behavior can be used as a fingerprinting tool.
350
-Similarly, all extensions <a class="ulink" href="http://blog.chromium.org/2010/06/extensions-in-incognito.html" target="_top">SHOULD be
194
+Similarly, all extensions <a class="ulink" href="http://blog.chromium.org/2010/06/extensions-in-incognito.html">SHOULD be
351 195
 disabled in the mode</a> except as an opt-in basis. We SHOULD NOT load
352
-system-wide addons or plugins.
196
+system-wide and/or Operating System provided addons or plugins.
353 197
 
354 198
      </p><p>
355 199
 Instead of global browser privacy options, privacy decisions SHOULD be made
356
-<a class="ulink" href="https://wiki.mozilla.org/Privacy/Features/Site-based_data_management_UI" target="_top">per
200
+<a class="ulink" href="https://wiki.mozilla.org/Privacy/Features/Site-based_data_management_UI">per
357 201
 url bar origin</a> to eliminate the possibility of linkability
358 202
 between domains. For example, when a plugin object (or a Javascript access of
359 203
 window.plugins) is present in a page, the user should be given the choice of
... ...
@@ -361,16 +205,18 @@ allowing that plugin object for that url bar origin only. The same
361 205
 goes for exemptions to third party cookie policy, geo-location, and any other
362 206
 privacy permissions.
363 207
      </p><p>
364
-If the user has indicated they do not care about local history storage, these
365
-permissions can be written to disk. Otherwise, they should remain memory-only. 
208
+If the user has indicated they wish to record local history storage, these
209
+permissions can be written to disk. Otherwise, they MUST remain memory-only. 
366 210
      </p></li><li class="listitem"><span class="command"><strong>No filters</strong></span><p>
367 211
 
368
-Filter-based addons such as <a class="ulink" href="https://addons.mozilla.org/en-US/firefox/addon/adblock-plus/" target="_top">AdBlock
369
-Plus</a>, <a class="ulink" href="http://requestpolicy.com/" target="_top">Request Policy</a>,
370
-<a class="ulink" href="http://www.ghostery.com/about" target="_top">Ghostery</a>, <a class="ulink" href="http://priv3.icsi.berkeley.edu/" target="_top">Priv3</a>, and <a class="ulink" href="http://sharemenot.cs.washington.edu/" target="_top">Sharemenot</a> are to be
212
+Site-specific or filter-based addons such as <a class="ulink" href="https://addons.mozilla.org/en-US/firefox/addon/adblock-plus/">AdBlock
213
+Plus</a>, <a class="ulink" href="http://requestpolicy.com/">Request Policy</a>,
214
+<a class="ulink" href="http://www.ghostery.com/about">Ghostery</a>, <a class="ulink" href="http://priv3.icsi.berkeley.edu/">Priv3</a>, and <a class="ulink" href="http://sharemenot.cs.washington.edu/">Sharemenot</a> are to be
371 215
 avoided. We believe that these addons do not add any real privacy to a proper
372
-<a class="link" href="#Implementation" title="3. Implementation">implementation</a> of the above <a class="link" href="#privacy" title="2.2. Privacy Requirements">privacy requirements</a>, as all third parties are
373
-prevented from tracking users between sites by the implementation.
216
+<a class="link" href="#Implementation" title="4. Implementation">implementation</a> of the above <a class="link" href="#privacy" title="2.2. Privacy Requirements">privacy requirements</a>, and that development efforts
217
+should be focused on general solutions that prevent tracking by all
218
+third parties, rather than a list of specific URLs or hosts.
219
+     </p><p>
374 220
 Filter-based addons can also introduce strange breakage and cause usability
375 221
 nightmares, and will also fail to do their job if an adversary simply
376 222
 registers a new domain or creates a new url path. Worse still, the unique
... ...
@@ -382,7 +227,7 @@ fingerprinting targets.
382 227
 As a general matter, we are also generally opposed to shipping an always-on Ad
383 228
 blocker with Tor Browser. We feel that this would damage our credibility in
384 229
 terms of demonstrating that we are providing privacy through a sound design
385
-alone, as well as damage the acceptance of Tor users by sites who support
230
+alone, as well as damage the acceptance of Tor users by sites that support
386 231
 themselves through advertising revenue.
387 232
 
388 233
       </p><p>
... ...
@@ -393,7 +238,202 @@ We believe that if we do not stay current with the support of new web
393 238
 technologies, we cannot hope to substantially influence or be involved in
394 239
 their proper deployment or privacy realization. However, we will likely disable
395 240
 high-risk features pending analysis, audit, and mitigation.
396
-      </p></li></ol></div></div></div><div class="sect1" title="3. Implementation"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Implementation"></a>3. Implementation</h2></div></div></div><p>
241
+      </p></li></ol></div></div></div><div class="sect1" title="3. Adversary Model"><div class="titlepage"><div><div><h2 class="title"><a id="adversary"/>3. Adversary Model</h2></div></div></div><p>
242
+
243
+A Tor web browser adversary has a number of goals, capabilities, and attack
244
+types that can be used to illustrate the design requirements for the
245
+Tor Browser. Let's start with the goals.
246
+
247
+   </p><div class="sect2" title="3.1. Adversary Goals"><div class="titlepage"><div><div><h3 class="title"><a id="adversarygoals"/>3.1. Adversary Goals</h3></div></div></div><div class="orderedlist"><ol class="orderedlist"><li class="listitem"><span class="command"><strong>Bypassing proxy settings</strong></span><p>The adversary's primary goal is direct compromise and bypass of 
248
+Tor, causing the user to directly connect to an IP of the adversary's
249
+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
250
+happily settle for the ability to correlate something a user did via Tor with
251
+their non-Tor activity. This can be done with cookies, cache identifiers,
252
+javascript events, and even CSS. Sometimes the fact that a user uses Tor may
253
+be enough for some authorities.</p></li><li class="listitem"><span class="command"><strong>History disclosure</strong></span><p>
254
+The adversary may also be interested in history disclosure: the ability to
255
+query a user's history to see if they have issued certain censored search
256
+queries, or visited censored sites.
257
+     </p></li><li class="listitem"><span class="command"><strong>Location information</strong></span><p>
258
+
259
+Location information such as timezone and locality can be useful for the
260
+adversary to determine if a user is in fact originating from one of the
261
+regions they are attempting to control, or to zero-in on the geographical
262
+location of a particular dissident or whistleblower.
263
+
264
+     </p></li><li class="listitem"><span class="command"><strong>Correlate activity across multiple sites</strong></span><p>
265
+
266
+The primary goal of the advertising networks is to know that the user who
267
+visited siteX.com is the same user that visited siteY.com to serve them
268
+targeted ads. The advertising networks become our adversary insofar as they
269
+attempt to perform this correlation without the user's explicit consent.
270
+
271
+     </p></li><li class="listitem"><span class="command"><strong>Fingerprinting/anonymity set reduction</strong></span><p>
272
+
273
+Fingerprinting (more generally: "anonymity set reduction") is used to attempt
274
+to zero in on a particular individual without the use of tracking identifiers.
275
+If the dissident or whistleblower is using a rare build of Firefox for an
276
+obscure operating system, this can be very useful information for tracking
277
+them down, or at least <a class="link" href="#fingerprinting">tracking their
278
+activities</a>.
279
+
280
+     </p></li><li class="listitem"><span class="command"><strong>History records and other on-disk
281
+information</strong></span><p>
282
+In some cases, the adversary may opt for a heavy-handed approach, such as
283
+seizing the computers of all Tor users in an area (especially after narrowing
284
+the field by the above two pieces of information). History records and cache
285
+data are the primary goals here.
286
+     </p></li></ol></div></div><div class="sect2" title="3.2. Adversary Capabilities - Positioning"><div class="titlepage"><div><div><h3 class="title"><a id="adversarypositioning"/>3.2. Adversary Capabilities - Positioning</h3></div></div></div><p>
287
+The adversary can position themselves at a number of different locations in
288
+order to execute their attacks.
289
+    </p><div class="orderedlist"><ol class="orderedlist"><li class="listitem"><span class="command"><strong>Exit Node or Upstream Router</strong></span><p>
290
+The adversary can run exit nodes, or alternatively, they may control routers
291
+upstream of exit nodes. Both of these scenarios have been observed in the
292
+wild.
293
+     </p></li><li class="listitem"><span class="command"><strong>Ad servers and/or Malicious Websites</strong></span><p>
294
+The adversary can also run websites, or more likely, they can contract out
295
+ad space from a number of different ad servers and inject content that way. For
296
+some users, the adversary may be the ad servers themselves. It is not
297
+inconceivable that ad servers may try to subvert or reduce a user's anonymity 
298
+through Tor for marketing purposes.
299
+     </p></li><li class="listitem"><span class="command"><strong>Local Network/ISP/Upstream Router</strong></span><p>
300
+The adversary can also inject malicious content at the user's upstream router
301
+when they have Tor disabled, in an attempt to correlate their Tor and Non-Tor
302
+activity.
303
+     </p></li><li class="listitem"><span class="command"><strong>Physical Access</strong></span><p>
304
+Some users face adversaries with intermittent or constant physical access.
305
+Users in Internet cafes, for example, face such a threat. In addition, in
306
+countries where simply using tools like Tor is illegal, users may face
307
+confiscation of their computer equipment for excessive Tor usage or just
308
+general suspicion.
309
+     </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"/>3.3. Adversary Capabilities - Attacks</h3></div></div></div><p>
310
+
311
+The adversary can perform the following attacks from a number of different 
312
+positions to accomplish various aspects of their goals. It should be noted
313
+that many of these attacks (especially those involving IP address leakage) are
314
+often performed by accident by websites that simply have Javascript, dynamic 
315
+CSS elements, and plugins. Others are performed by ad servers seeking to
316
+correlate users' activity across different IP addresses, and still others are
317
+performed by malicious agents on the Tor network and at national firewalls.
318
+
319
+    </p><div class="orderedlist"><ol class="orderedlist"><li class="listitem"><span class="command"><strong>Read and insert identifiers</strong></span><p>
320
+
321
+The browser contains multiple facilities for storing identifiers that the
322
+adversary creates for the purposes of tracking users. These identifiers are
323
+most obviously cookies, but also include HTTP auth, DOM storage, cached
324
+scripts and other elements with embedded identifiers, client certificates, and
325
+even TLS Session IDs.
326
+
327
+     </p><p>
328
+
329
+An adversary in a position to perform MITM content alteration can inject
330
+document content elements to both read and inject cookies for arbitrary
331
+domains. In fact, even many "SSL secured" websites are vulnerable to this sort of
332
+<a class="ulink" href="http://seclists.org/bugtraq/2007/Aug/0070.html">active
333
+sidejacking</a>. In addition, the ad networks of course perform tracking
334
+with cookies as well.
335
+
336
+     </p><p>
337
+
338
+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.
339
+
340
+     </p></li><li class="listitem"><a id="fingerprinting"/><span class="command"><strong>Fingerprint users based on browser
341
+attributes</strong></span><p>
342
+
343
+There is an absurd amount of information available to websites via attributes
344
+of the browser. This information can be used to reduce anonymity set, or even
345
+uniquely fingerprint individual users. Attacks of this nature are typically
346
+aimed at tracking users across sites without their consent, in an attempt to
347
+subvert our <a class="link" href="#fingerprinting-linkability" title="4.6. Cross-Origin Fingerprinting Unlinkability">Cross-Origin
348
+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.
349
+
350
+</p><p>
351
+
352
+Fingerprinting is an intimidating
353
+problem to attempt to tackle, especially without a metric to determine or at
354
+least intuitively understand and estimate which features will most contribute
355
+to linkability between visits.
356
+
357
+</p><p>
358
+
359
+The <a class="ulink" href="https://panopticlick.eff.org/about.php">Panopticlick study
360
+done</a> by the EFF uses the <a class="ulink" href="https://en.wikipedia.org/wiki/Entropy_%28information_theory%29">Shannon
361
+entropy</a> - the number of identifying bits of information encoded in
362
+browser properties - as this metric. Their <a class="ulink" href="https://wiki.mozilla.org/Fingerprinting#Data">result data</a> is
363
+definitely useful, and the metric is probably the appropriate one for
364
+determining how identifying a particular browser property is. However, some
365
+quirks of their study means that they do not extract as much information as
366
+they could from display information: they only use desktop resolution and do
367
+not attempt to infer the size of toolbars. In the other direction, they may be
368
+over-counting in some areas, as they did not compute joint entropy over
369
+multiple attributes that may exhibit a high degree of correlation. Also, new
370
+browser features are added regularly, so the data should not be taken as
371
+final.
372
+
373
+      </p><p>
374
+
375
+Despite the uncertainty, all fingerprinting attacks leverage the following
376
+attack vectors:
377
+
378
+     </p><div class="orderedlist"><ol class="orderedlist"><li class="listitem"><span class="command"><strong>Observing Request Behavior</strong></span><p>
379
+
380
+Properties of the user's request behavior comprise the bulk of low-hanging
381
+fingerprinting targets. These include: User agent, Accept-* headers, pipeline
382
+usage, and request ordering. Additionally, the use of custom filters such as
383
+AdBlock and other privacy filters can be used to fingerprint request patterns
384
+(as an extreme example).
385
+
386
+     </p></li><li class="listitem"><span class="command"><strong>Inserting Javascript</strong></span><p>
387
+
388
+Javascript can reveal a lot of fingerprinting information. It provides DOM
389
+objects such as window.screen and window.navigator to extract information
390
+about the useragent. 
391
+
392
+Also, Javascript can be used to query the user's timezone via the
393
+<code class="function">Date()</code> object, <a class="ulink" href="https://www.khronos.org/registry/webgl/specs/1.0/#5.13">WebGL</a> can
394
+reveal information about the video card in use, and high precision timing
395
+information can be used to <a class="ulink" href="http://w2spconf.com/2011/papers/jspriv.pdf">fingerprint the CPU and
396
+interpreter speed</a>. In the future, new JavaScript features such as
397
+<a class="ulink" href="http://w3c-test.org/webperf/specs/ResourceTiming/">Resource
398
+Timing</a> may leak an unknown amount of network timing related
399
+information.
400
+
401
+
402
+
403
+     </p></li><li class="listitem"><span class="command"><strong>Inserting Plugins</strong></span><p>
404
+
405
+The Panopticlick project found that the mere list of installed plugins (in
406
+navigator.plugins) was sufficient to provide a large degree of
407
+fingerprintability. Additionally, plugins are capable of extracting font lists,
408
+interface addresses, and other machine information that is beyond what the
409
+browser would normally provide to content. In addition, plugins can be used to
410
+store unique identifiers that are more difficult to clear than standard
411
+cookies.  <a class="ulink" href="http://epic.org/privacy/cookies/flash.html">Flash-based
412
+cookies</a> fall into this category, but there are likely numerous other
413
+examples. Beyond fingerprinting, plugins are also abysmal at obeying the proxy
414
+settings of the browser. 
415
+
416
+
417
+     </p></li><li class="listitem"><span class="command"><strong>Inserting CSS</strong></span><p>
418
+
419
+<a class="ulink" href="https://developer.mozilla.org/En/CSS/Media_queries">CSS media
420
+queries</a> can be inserted to gather information about the desktop size,
421
+widget size, display type, DPI, user agent type, and other information that
422
+was formerly available only to Javascript.
423
+
424
+     </p></li></ol></div></li><li class="listitem"><span class="command"><strong>Remotely or locally exploit browser and/or
425
+OS</strong></span><p>
426
+
427
+Last, but definitely not least, the adversary can exploit either general
428
+browser vulnerabilities, plugin vulnerabilities, or OS vulnerabilities to
429
+install malware and surveillance software. An adversary with physical access
430
+can perform similar actions. Regrettably, this last attack capability is
431
+outside of the browser's ability to defend against, but it is worth mentioning
432
+for completeness. In fact, <a class="ulink" href="http://tails.boum.org/contribute/design/">The Tails system</a> can
433
+provide some defense against this adversary, and it does include the Tor
434
+Browser.
435
+
436
+     </p></li></ol></div></div></div><div class="sect1" title="4. Implementation"><div class="titlepage"><div><div><h2 class="title"><a id="Implementation"/>4. Implementation</h2></div></div></div><p>
397 437
 
398 438
 The Implementation section is divided into subsections, each of which
399 439
 corresponds to a <a class="link" href="#DesignRequirements" title="2. Design Requirements and Philosophy">Design Requirement</a>.
... ...
@@ -406,121 +446,153 @@ In some cases, the implementation meets the design requirements in a non-ideal
406 446
 way (for example, by disabling features). In rare cases, there may be no
407 447
 implementation at all. Both of these cases are denoted by differentiating
408 448
 between the <span class="command"><strong>Design Goal</strong></span> and the <span class="command"><strong>Implementation
409
-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>
449
+Status</strong></span> for each property. Corresponding bugs in the <a class="ulink" href="https://trac.torproject.org/projects/tor/report">Tor bug tracker</a>
410 450
 are typically linked for these cases.
411 451
 
412
-  </p><div class="sect2" title="3.1. Proxy Obedience"><div class="titlepage"><div><div><h3 class="title"><a id="proxy-obedience"></a>3.1. Proxy Obedience</h3></div></div></div><p>
452
+  </p><div class="sect2" title="4.1. Proxy Obedience"><div class="titlepage"><div><div><h3 class="title"><a id="proxy-obedience"/>4.1. Proxy Obedience</h3></div></div></div><p>
413 453
 
414 454
 Proxy obedience is assured through the following:
415
-   </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem">Firefox Proxy settings
455
+   </p><div class="orderedlist"><ol class="orderedlist"><li class="listitem">Firefox proxy settings, patches, and build flags
416 456
  <p>
417
-  The Torbutton xpi sets the Firefox proxy settings to use Tor directly as a
457
+Our <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/HEAD:/build-scripts/config/pound_tor.js">Firefox
458
+preferences file</a> sets the Firefox proxy settings to use Tor directly as a
418 459
 SOCKS proxy. It sets <span class="command"><strong>network.proxy.socks_remote_dns</strong></span>,
419
-<span class="command"><strong>network.proxy.socks_version</strong></span>, and
420
-<span class="command"><strong>network.proxy.socks_port</strong></span>.
460
+<span class="command"><strong>network.proxy.socks_version</strong></span>,
461
+<span class="command"><strong>network.proxy.socks_port</strong></span>, and
462
+<span class="command"><strong>network.dns.disablePrefetch</strong></span>.
463
+ </p><p>
464
+
465
+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">prevent
466
+a DNS leak due to a WebSocket rate-limiting check</a>. As stated in the
467
+patch, we believe the direct DNS resolution performed by this check is in
468
+violation of the W3C standard, but <a class="ulink" href="https://bugzilla.mozilla.org/show_bug.cgi?id=751465">this DNS proxy leak
469
+remains present in stock Firefox releases</a>.
470
+
421 471
  </p><p>
422 472
 
423
-We have verified that these settings properly proxy HTTPS, OCSP, HTTP, FTP,
424
-gopher (now defunct), DNS, SafeBrowsing Queries, all javascript activity,
425
-including HTML5 audio and video objects, addon updates, wifi geolocation
426
-queries, searchbox queries, XPCOM addon HTTPS/HTTP activity, and live bookmark
427
-updates. We have also verified that IPv6 connections are not attempted,
428
-through the proxy or otherwise (Tor does not yet support IPv6). We have also
429
-verified that external protocol helpers, such as smb urls and other custom
430
-protocol handers are all blocked.
473
+During the transition to Firefox 17-ESR, a code audit was undertaken to verify
474
+that there were no system calls or XPCOM activity in the source tree that did
475
+not use the browser proxy settings. The only violation we found was that
476
+WebRTC was capable of creating UDP sockets and was compiled in by default. We
477
+subsequently disabled it using the Firefox build option
478
+<span class="command"><strong>--disable-webrtc</strong></span>.
431 479
 
432 480
  </p><p>
433 481
 
434
-Numerous other third parties have also reviewed and <a class="link" href="#SingleStateTesting" title="5.1. Single state testing">tested</a> the proxy settings
435
-and have provided test cases based on their work. See in particular <a class="ulink" href="http://decloak.net/" target="_top">decloak.net</a>. 
482
+We have verified that these settings and patches properly proxy HTTPS, OCSP,
483
+HTTP, FTP, gopher (now defunct), DNS, SafeBrowsing Queries, all javascript
484
+activity, including HTML5 audio and video objects, addon updates, wifi
485
+geolocation queries, searchbox queries, XPCOM addon HTTPS/HTTP activity,
486
+WebSockets, and live bookmark updates. We have also verified that IPv6
487
+connections are not attempted, through the proxy or otherwise (Tor does not
488
+yet support IPv6). We have also verified that external protocol helpers, such
489
+as smb urls and other custom protocol handlers are all blocked.
490
+
491
+ </p><p>
492
+
493
+Numerous other third parties have also reviewed and tested the proxy settings
494
+and have provided test cases based on their work. See in particular <a class="ulink" href="http://decloak.net/">decloak.net</a>. 
436 495
 
437 496
  </p></li><li class="listitem">Disabling plugins
438 497
 
439
- <p>Plugins have the ability to make arbitrary OS system calls and  <a class="ulink" href="http://decloak.net/" target="_top">bypass proxy settings</a>. This includes
498
+ <p>Plugins have the ability to make arbitrary OS system calls and  <a class="ulink" href="http://decloak.net/">bypass proxy settings</a>. This includes
440 499
 the ability to make UDP sockets and send arbitrary data independent of the
441 500
 browser proxy settings.
442 501
  </p><p>
443 502
 Torbutton disables plugins by using the
444 503
 <span class="command"><strong>@mozilla.org/plugin/host;1</strong></span> service to mark the plugin tags
445
-as disabled. Additionally, we set
446
-<span class="command"><strong>plugin.disable_full_page_plugin_for_types</strong></span> to the list of
447
-supported mime types for all currently installed plugins.
504
+as disabled. This block can be undone through both the Torbutton Security UI,
505
+and the Firefox Plugin Preferences.
448 506
  </p><p>
449
-In addition, to prevent any unproxied activity by plugins at load time, we
450
-also patch the Firefox source code to <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.2:/src/current-patches/firefox/0007-Block-all-plugins-except-flash.patch" target="_top">prevent the load of any plugins except
451
-for Flash and Gnash</a>.
452
-
507
+If the user does enable plugins in this way, plugin-handled objects are still
508
+restricted from automatic load through Firefox's click-to-play preference
509
+<span class="command"><strong>plugins.click_to_play</strong></span>.
453 510
  </p><p>
454
-
455
-Finally, even if the user alters their browser settings to re-enable the Flash
456
-plugin, we have configured NoScript to provide click-to-play placeholders, so
457
-that only desired objects will be loaded, and only after user confirmation.
511
+In addition, to reduce any unproxied activity by arbitrary plugins at load
512
+time, and to reduce the fingerprintability of the installed plugin list, we
513
+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">prevent the load of any plugins except
514
+for Flash and Gnash</a>.
458 515
 
459 516
  </p></li><li class="listitem">External App Blocking
460 517
   <p>
461 518
 External apps, if launched automatically, can be induced to load files that
462 519
 perform network activity. In order to prevent this, Torbutton installs a
463 520
 component to 
464
-<a class="ulink" href="https://gitweb.torproject.org/torbutton.git/blob_plain/HEAD:/src/components/external-app-blocker.js" target="_top">
521
+<a class="ulink" href="https://gitweb.torproject.org/torbutton.git/blob_plain/HEAD:/src/components/external-app-blocker.js">
465 522
 provide the user with a popup</a> whenever the browser attempts to
466 523
 launch a helper app. 
467 524
 
468
-Additionally, due primarily to an issue with Ubuntu Unity, url-based drag and drop is
525
+Additionally, due to an issue with Ubuntu Unity, url-based drag and drop is
469 526
 filtered by this component. Unity was pre-fetching URLs without using the
470 527
 browser's proxy settings during a drag action, even if the drop was ultimately
471
-canceled by the user.
472
-  </p></li></ol></div></div><div class="sect2" title="3.2. State Separation"><div class="titlepage"><div><div><h3 class="title"><a id="state-separation"></a>3.2. State Separation</h3></div></div></div><p>
528
+canceled by the user. A similar issue was discovered on Mac OS.
529
+  </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"/>4.2. State Separation</h3></div></div></div><p>
473 530
 Tor Browser State is separated from existing browser state through use of a
474 531
 custom Firefox profile. Furthermore, plugins are disabled, which prevents
475 532
 Flash cookies from leaking from a pre-existing Flash directory.
476
-   </p></div><div class="sect2" title="3.3. Disk Avoidance"><div class="titlepage"><div><div><h3 class="title"><a id="disk-avoidance"></a>3.3. Disk Avoidance</h3></div></div></div><div class="sect3" title="Design Goal:"><div class="titlepage"><div><div><h4 class="title"><a id="id2652153"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote">
477
-Tor Browser MUST (at user option) prevent all disk records of browser activity.
533
+   </p></div><div class="sect2" title="4.3. Disk Avoidance"><div class="titlepage"><div><div><h3 class="title"><a id="disk-avoidance"/>4.3. Disk Avoidance</h3></div></div></div><div class="sect3" title="Design Goal:"><div class="titlepage"><div><div><h4 class="title"><a id="idp5523344"/>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote">
534
+
535
+The User Agent MUST (at user option) prevent all disk records of browser activity.
478 536
 The user should be able to optionally enable URL history and other history
479
-features if they so desire. Once we <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3100" target="_top">simplify the
480
-preferences interface</a>, we will likely just enable Private Browsing
481
-mode by default to handle this goal.
482
-    </blockquote></div></div><div class="sect3" title="Implementation Status:"><div class="titlepage"><div><div><h4 class="title"><a id="id2650204"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote">
483
-For now, Tor Browser blocks write access to the disk through Torbutton
484
-using several Firefox preferences. 
537
+features if they so desire. 
538
+
539
+    </blockquote></div></div><div class="sect3" title="Implementation Status:"><div class="titlepage"><div><div><h4 class="title"><a id="idp5524704"/>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote">
540
+
541
+We achieve this goal through several mechanisms. First, we set the Firefox
542
+Private Browsing preference
543
+<span class="command"><strong>browser.privatebrowsing.autostart</strong></span>. In addition, four Firefox patches are needed to prevent disk writes, even if
544
+Private Browsing Mode is enabled. We need to
545
+
546
+<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">prevent
547
+the permissions manager from recording HTTPS STS state</a>,
548
+<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">prevent
549
+intermediate SSL certificates from being recorded</a>,
550
+<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">prevent
551
+download history from being recorded</a>, and
552
+<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">prevent
553
+the content preferences service from recording site zoom</a>.
485 554
 
555
+For more details on these patches, <a class="link" href="#firefox-patches" title="4.8. Description of Firefox Patches">see the
556
+Firefox Patches section</a>.
486 557
 
558
+    </blockquote></div><div class="blockquote"><blockquote class="blockquote">
487 559
 
488
-The set of prefs is:
489
-<span class="command"><strong>dom.storage.enabled</strong></span>,
490
-<span class="command"><strong>browser.cache.memory.enable</strong></span>,
491
-<span class="command"><strong>network.http.use-cache</strong></span>,
560
+As an additional defense-in-depth measure, we set the following preferences:
561
+<span class="command"><strong/></span>,
492 562
 <span class="command"><strong>browser.cache.disk.enable</strong></span>,
493 563
 <span class="command"><strong>browser.cache.offline.enable</strong></span>,
494
-<span class="command"><strong>general.open_location.last_url</strong></span>,
495
-<span class="command"><strong>places.history.enabled</strong></span>,
496
-<span class="command"><strong>browser.formfill.enable</strong></span>,
564
+<span class="command"><strong>dom.indexedDB.enabled</strong></span>,
565
+<span class="command"><strong>network.cookie.lifetimePolicy</strong></span>,
497 566
 <span class="command"><strong>signon.rememberSignons</strong></span>,
567
+<span class="command"><strong>browser.formfill.enable</strong></span>,
498 568
 <span class="command"><strong>browser.download.manager.retention</strong></span>,
499
-and <span class="command"><strong>network.cookie.lifetimePolicy</strong></span>.
500
-    </blockquote></div></div><p>
501
-In addition, three Firefox patches are needed to prevent disk writes, even if
502
-Private Browsing Mode is enabled. We need to
569
+<span class="command"><strong>browser.sessionstore.privacy_level</strong></span>,
570
+and <span class="command"><strong>network.cookie.lifetimePolicy</strong></span>. Many of these
571
+preferences are likely redundant with
572
+<span class="command"><strong>browser.privatebrowsing.autostart</strong></span>, but we have not done the
573
+auditing work to ensure that yet.
503 574
 
504
-<a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.2:/src/current-patches/firefox/0002-Make-Permissions-Manager-memory-only.patch" target="_top">prevent
505
-the permissions manager from recording HTTPS STS state</a>,
506
-<a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.2:/src/current-patches/firefox/0003-Make-Intermediate-Cert-Store-memory-only.patch" target="_top">prevent
507
-intermediate SSL certificates from being recorded</a>, and
508
-<a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.2:/src/current-patches/firefox/0008-Make-content-pref-service-memory-only-clearable.patch" target="_top">prevent
509
-the content preferences service from recording site zoom</a>.
575
+    </blockquote></div><div class="blockquote"><blockquote class="blockquote">
510 576
 
511
-For more details on these patches, <a class="link" href="#firefox-patches" title="3.9. Description of Firefox Patches">see the
512
-Firefox Patches section</a>.
577
+Torbutton also <a class="ulink" href="https://gitweb.torproject.org/torbutton.git/blob/HEAD:/src/components/tbSessionStore.js">contains
578
+code</a> to prevent the Firefox session store from writing to disk.
579
+    </blockquote></div><div class="blockquote"><blockquote class="blockquote">
513 580
 
514
-   </p></div><div class="sect2" title="3.4. Application Data Isolation"><div class="titlepage"><div><div><h3 class="title"><a id="app-data-isolation"></a>3.4. Application Data Isolation</h3></div></div></div><p>
581
+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">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"/>4.4. Application Data Isolation</h3></div></div></div><p>
515 582
 
516 583
 Tor Browser Bundle MUST NOT cause any information to be written outside of the
517 584
 bundle directory. This is to ensure that the user is able to completely and
518 585
 safely remove the bundle without leaving other traces of Tor usage on their
519 586
 computer.
520 587
 
521
-   </p><p>FIXME: sjmurdoch, Erinn: explain what magic we do to satisfy this,
522
-and/or what additional work or auditing needs to be done.
523
-   </p></div><div class="sect2" title="3.5. Cross-Origin Identifier Unlinkability"><div class="titlepage"><div><div><h3 class="title"><a id="identifier-linkability"></a>3.5. Cross-Origin Identifier Unlinkability</h3></div></div></div><p>
588
+   </p><p>
589
+
590
+To ensure TBB directory isolation, we set
591
+<span class="command"><strong>browser.download.useDownloadDir</strong></span>,
592
+<span class="command"><strong>browser.shell.checkDefaultBrowser</strong></span>, and
593
+<span class="command"><strong>browser.download.manager.addToRecentDocs</strong></span>. We also set the
594
+$HOME environment variable to be the TBB extraction directory.
595
+   </p></div><div class="sect2" title="4.5. Cross-Origin Identifier Unlinkability"><div class="titlepage"><div><div><h3 class="title"><a id="identifier-linkability"/>4.5. Cross-Origin Identifier Unlinkability</h3></div></div></div><p>
524 596
 
525 597
 The Tor Browser MUST prevent a user's activity on one site from being linked
526 598
 to their activity on another site. When this goal cannot yet be met with an
... ...
@@ -544,21 +616,19 @@ the url bar origin for which browser state exists, possibly with a
544 616
 context-menu option to drill down into specific types of state or permissions.
545 617
 An example of this simplification can be seen in Figure 1.
546 618
 
547
-   </p><div class="figure"><a id="id2634370"></a><p class="title"><b>Figure 1. Improving the Privacy UI</b></p><div class="figure-contents"><div class="mediaobject" align="center"><img src="CookieManagers.png" align="middle" alt="Improving the Privacy UI" /></div><div class="caption"><p></p>
619
+   </p><div class="figure"><a id="idp5548704"/><p class="title"><b>Figure 1. Improving the Privacy UI</b></p><div class="figure-contents"><div class="mediaobject" style="text-align: center"><img src="NewCookieManager.png" style="text-align: middle" alt="Improving the Privacy UI"/></div><div class="caption"><p/>
548 620
 
549
-On the left is the standard Firefox cookie manager. On the right is a mock-up
550
-of how isolating identifiers to the URL bar origin might simplify the privacy
551
-UI for all data - not just cookies. Both windows represent the set of
552
-Cookies accumulated after visiting just five sites, but the window on the
553
-right has the option of also representing history, DOM Storage, HTTP Auth,
554
-search form history, login values, and so on within a context menu for each
555
-site.
621
+This example UI is a mock-up of how isolating identifiers to the URL bar
622
+origin can simplify the privacy UI for all data - not just cookies. Once
623
+browser identifiers and site permissions operate on a url bar basis, the same
624
+privacy window can represent browsing history, DOM Storage, HTTP Auth, search
625
+form history, login values, and so on within a context menu for each site.
556 626
 
557
-</div></div></div><br class="figure-break" /><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem">Cookies
627
+</div></div></div><br class="figure-break"/><div class="orderedlist"><ol class="orderedlist"><li class="listitem">Cookies
558 628
      <p><span class="command"><strong>Design Goal:</strong></span>
559 629
 
560 630
 All cookies MUST be double-keyed to the url bar origin and third-party
561
-origin. There exists a <a class="ulink" href="https://bugzilla.mozilla.org/show_bug.cgi?id=565965" target="_top">Mozilla bug</a>
631
+origin. There exists a <a class="ulink" href="https://bugzilla.mozilla.org/show_bug.cgi?id=565965">Mozilla bug</a>
562 632
 that contains a prototype patch, but it lacks UI, and does not apply to modern
563 633
 Firefoxes.
564 634
 
... ...
@@ -574,17 +644,17 @@ unlinkability trumps that desire.
574 644
      <p>
575 645
 
576 646
 Cache is isolated to the url bar origin by using a technique pioneered by
577
-Colin Jackson et al, via their work on <a class="ulink" href="http://www.safecache.com/" target="_top">SafeCache</a>. The technique re-uses the
578
-<a class="ulink" href="https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsICachingChannel" target="_top">nsICachingChannel.cacheKey</a>
647
+Colin Jackson et al, via their work on <a class="ulink" href="http://www.safecache.com/">SafeCache</a>. The technique re-uses the
648
+<a class="ulink" href="https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsICachingChannel">nsICachingChannel.cacheKey</a>
579 649
 attribute that Firefox uses internally to prevent improper caching and reuse
580 650
 of HTTP POST data.  
581 651
 
582 652
      </p><p>
583 653
 
584
-However, to <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3666" target="_top">increase the
585
-security of the isolation</a> and to <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3754" target="_top">solve conflicts
654
+However, to <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3666">increase the
655
+security of the isolation</a> and to <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3754">solve conflicts
586 656
 with OCSP relying the cacheKey property for reuse of POST requests</a>, we
587
-had to <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.2:/src/current-patches/firefox/0005-Add-a-string-based-cacheKey.patch" target="_top">patch
657
+had to <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">patch
588 658
 Firefox to provide a cacheDomain cache attribute</a>. We use the fully
589 659
 qualified url bar domain as input to this field.
590 660
 
... ...
@@ -599,49 +669,49 @@ opposed to relying solely on the referer property.
599 669
 
600 670
      </p><p>
601 671
 
602
-Therefore, <a class="ulink" href="http://crypto.stanford.edu/sameorigin/safecachetest.html" target="_top">the original
672
+Therefore, <a class="ulink" href="http://crypto.stanford.edu/sameorigin/safecachetest.html">the original
603 673
 Stanford test cases</a> are expected to fail. Functionality can still be
604
-verified by navigating to <a class="ulink" href="about:cache" target="_top">about:cache</a> and
674
+verified by navigating to <a class="ulink" href="about:cache">about:cache</a> and
605 675
 viewing the key used for each cache entry. Each third party element should
606 676
 have an additional "domain=string" property prepended, which will list the
607 677
 FQDN that was used to source the third party element.
608 678
 
679
+     </p><p>
680
+
681
+Additionally, because the image cache is a separate entity from the content
682
+cache, we had to patch Firefox to also <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">isolate
683
+this cache per url bar domain</a>.
684
+
609 685
      </p></li><li class="listitem">HTTP Auth
610 686
      <p>
611 687
 
612 688
 HTTP authentication tokens are removed for third party elements using the
613
-<a class="ulink" href="https://developer.mozilla.org/en/Setting_HTTP_request_headers#Observers" target="_top">http-on-modify-request
614
-observer</a> to remove the Authorization headers to prevent <a class="ulink" href="http://jeremiahgrossman.blogspot.com/2007/04/tracking-users-without-cookies.html" target="_top">silent
615
-linkability between domains</a>.  We also needed to <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.2:/src/current-patches/firefox/0004-Add-HTTP-auth-headers-before-the-modify-request-obse.patch" target="_top">patch
616
-Firefox to cause the headers to get added early enough</a> to allow the
617
-observer to modify it.
618
-
689
+<a class="ulink" href="https://developer.mozilla.org/en/Setting_HTTP_request_headers#Observers">http-on-modify-request
690
+observer</a> to remove the Authorization headers to prevent <a class="ulink" href="http://jeremiahgrossman.blogspot.com/2007/04/tracking-users-without-cookies.html">silent
691
+linkability between domains</a>. 
619 692
      </p></li><li class="listitem">DOM Storage
620
-     <p><span class="command"><strong>Design Goal:</strong></span>
693
+     <p>
621 694
 
622 695
 DOM storage for third party domains MUST be isolated to the url bar origin,
623
-to prevent linkability between sites.
624
-
625
-     </p><p><span class="command"><strong>Implementation Status:</strong></span>
626
-
627
-Because it is isolated to third party domain as opposed to top level url bar
628
-origin, we entirely disable DOM storage as a stopgap to ensure unlinkability.
696
+to prevent linkability between sites. This functionality is provided through a
697
+<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">patch
698
+to Firefox</a>.
629 699
 
630 700
      </p></li><li class="listitem">Flash cookies
631 701
      <p><span class="command"><strong>Design Goal:</strong></span>
632 702
 
633 703
 Users should be able to click-to-play flash objects from trusted sites. To
634 704
 make this behavior unlinkable, we wish to include a settings file for all platforms that disables flash
635
-cookies using the <a class="ulink" href="http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager03.html" target="_top">Flash
705
+cookies using the <a class="ulink" href="http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager03.html">Flash
636 706
 settings manager</a>.
637 707
 
638 708
      </p><p><span class="command"><strong>Implementation Status:</strong></span>
639 709
 
640
-We are currently <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3974" target="_top">having
710
+We are currently <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3974">having
641 711
 difficulties</a> causing Flash player to use this settings
642 712
 file on Windows, so Flash remains difficult to enable.
643 713
 
644
-     </p></li><li class="listitem">SSL+TLS session resumption and HTTP Keep-Alive
714
+     </p></li><li class="listitem">SSL+TLS session resumption, HTTP Keep-Alive and SPDY
645 715
      <p><span class="command"><strong>Design Goal:</strong></span>
646 716
 
647 717
 TLS session resumption tickets and SSL Session IDs MUST be limited to the url
... ...
@@ -650,24 +720,28 @@ origin MUST NOT be reused for that same third party in another url bar origin.
650 720
 
651 721
      </p><p><span class="command"><strong>Implementation Status:</strong></span>
652 722
 
653
-We currently clear SSL Session IDs upon <a class="link" href="#new-identity" title="3.7. Long-Term Unlinkability via &quot;New Identity&quot; button">New
723
+We currently clear SSL Session IDs upon <a class="link" href="#new-identity" title="4.7. Long-Term Unlinkability via &quot;New Identity&quot; button">New
654 724
 Identity</a>, we disable TLS Session Tickets via the Firefox Pref
655 725
 <span class="command"><strong>security.enable_tls_session_tickets</strong></span>. We disable SSL Session
656
-IDs via a <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.2:/src/current-patches/firefox/0010-Disable-SSL-Session-ID-tracking.patch" target="_top">patch
726
+IDs via a <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">patch
657 727
 to Firefox</a>. To compensate for the increased round trip latency from disabling
658 728
 these performance optimizations, we also enable
659
-<a class="ulink" href="https://tools.ietf.org/html/draft-bmoeller-tls-falsestart-00" target="_top">TLS
729
+<a class="ulink" href="https://tools.ietf.org/html/draft-bmoeller-tls-falsestart-00">TLS
660 730
 False Start</a> via the Firefox Pref 
661 731
 <span class="command"><strong>security.ssl.enable_false_start</strong></span>.
662 732
     </p><p>
663 733
 
664
-Becuase of the extreme performance benefits of HTTP Keep-Alive for interactive
734
+Because of the extreme performance benefits of HTTP Keep-Alive for interactive
665 735
 web apps, and because of the difficulties of conveying urlbar origin
666 736
 information down into the Firefox HTTP layer, as a compromise we currently
667 737
 merely reduce the HTTP Keep-Alive timeout to 20 seconds (which is measured
668 738
 from the last packet read on the connection) using the Firefox preference
669 739
 <span class="command"><strong>network.http.keep-alive.timeout</strong></span>.
670 740
 
741
+     </p><p>
742
+However, because SPDY can store identifiers and has extremely long keepalive
743
+duration, it is disabled through the Firefox preference
744
+<span class="command"><strong>network.http.spdy.enabled</strong></span>.
671 745
      </p></li><li class="listitem">Automated cross-origin redirects MUST NOT store identifiers
672 746
     <p><span class="command"><strong>Design Goal:</strong></span>
673 747
 
... ...
@@ -687,33 +761,34 @@ federated login systems) SHOULD still allow identifiers to persist.
687 761
     </p><p><span class="command"><strong>Implementation status:</strong></span>
688 762
 
689 763
 There are numerous ways for the user to be redirected, and the Firefox API
690
-support to detect each of them is poor. We have a <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3600" target="_top">trac bug
764
+support to detect each of them is poor. We have a <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3600">trac bug
691 765
 open</a> to implement what we can.
692 766
 
693 767
     </p></li><li class="listitem">window.name
694 768
      <p>
695 769
 
696
-<a class="ulink" href="https://developer.mozilla.org/En/DOM/Window.name" target="_top">window.name</a> is
770
+<a class="ulink" href="https://developer.mozilla.org/En/DOM/Window.name">window.name</a> is
697 771
 a magical DOM property that for some reason is allowed to retain a persistent value
698 772
 for the lifespan of a browser tab. It is possible to utilize this property for
699
-<a class="ulink" href="http://www.thomasfrank.se/sessionvars.html" target="_top">identifier
773
+<a class="ulink" href="http://www.thomasfrank.se/sessionvars.html">identifier
700 774
 storage</a>.
701 775
 
702 776
      </p><p>
703 777
 
704
-In order to eliminate linkability but still allow for sites that utilize this
705
-property to function, we reset the window.name property of tabs in Torbutton every
706
-time we encounter a blank referer. This behavior allows window.name to persist
707
-for the duration of a link-driven navigation session, but as soon as the user
708
-enters a new URL or navigates between https/http schemes, the property is cleared.
778
+In order to eliminate non-consensual linkability but still allow for sites
779
+that utilize this property to function, we reset the window.name property of
780
+tabs in Torbutton every time we encounter a blank referer. This behavior
781
+allows window.name to persist for the duration of a click-driven navigation
782
+session, but as soon as the user enters a new URL or navigates between
783
+https/http schemes, the property is cleared.
709 784
 
710 785
      </p></li><li class="listitem">Auto form-fill
711 786
      <p>
712 787
 
713 788
 We disable the password saving functionality in the browser as part of our
714
-<a class="link" href="#disk-avoidance" title="3.3. Disk Avoidance">Disk Avoidance</a> requirement. However,
789
+<a class="link" href="#disk-avoidance" title="4.3. Disk Avoidance">Disk Avoidance</a> requirement. However,
715 790
 since users may decide to re-enable disk history records and password saving,
716
-we also set the <a class="ulink" href="http://kb.mozillazine.org/Signon.autofillForms" target="_top">signon.autofillForms</a>
791
+we also set the <a class="ulink" href="http://kb.mozillazine.org/Signon.autofillForms">signon.autofillForms</a>
717 792
 preference to false to prevent saved values from immediately populating
718 793
 fields upon page load. Since Javascript can read these values as soon as they
719 794
 appear, setting this preference prevents automatic linkability from stored passwords.
... ...
@@ -721,7 +796,7 @@ appear, setting this preference prevents automatic linkability from stored passw
721 796
      </p></li><li class="listitem">HSTS supercookies
722 797
       <p>
723 798
 
724
-An extreme (but not impossible) attack to mount is the creation of <a class="ulink" href="http://www.leviathansecurity.com/blog/archives/12-The-Double-Edged-Sword-of-HSTS-Persistence-and-Privacy.html" target="_top">HSTS
799
+An extreme (but not impossible) attack to mount is the creation of <a class="ulink" href="http://www.leviathansecurity.com/blog/archives/12-The-Double-Edged-Sword-of-HSTS-Persistence-and-Privacy.html">HSTS
725 800
 supercookies</a>. Since HSTS effectively stores one bit of information per domain
726 801
 name, an adversary in possession of numerous domains can use them to construct
727 802
 cookies based on stored HSTS state.
... ...
@@ -735,7 +810,7 @@ Restrict the number of HSTS-enabled third parties allowed per url bar origin.
735 810
 the best approach.
736 811
 
737 812
       </p><p><span class="command"><strong>Implementation Status:</strong></span> Currently, HSTS state is
738
-cleared by <a class="link" href="#new-identity" title="3.7. Long-Term Unlinkability via &quot;New Identity&quot; button">New Identity</a>, but we don't
813
+cleared by <a class="link" href="#new-identity" title="4.7. Long-Term Unlinkability via &quot;New Identity&quot; button">New Identity</a>, but we don't
739 814
 defend against the creation of these cookies between <span class="command"><strong>New
740 815
 Identity</strong></span> invocations.
741 816
       </p></li><li class="listitem">Exit node usage
... ...
@@ -748,39 +823,46 @@ observers from linking concurrent browsing activity.
748 823
      </p><p><span class="command"><strong>Implementation Status:</strong></span>
749 824
 
750 825
 The Tor feature that supports this ability only exists in the 0.2.3.x-alpha
751
-series. <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3455" target="_top">Ticket
826
+series. <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3455">Ticket
752 827
 #3455</a> is the Torbutton ticket to make use of the new Tor
753 828
 functionality.
754 829
 
755
-     </p></li></ol></div></div><div class="sect2" title="3.6. Cross-Origin Fingerprinting Unlinkability"><div class="titlepage"><div><div><h3 class="title"><a id="fingerprinting-linkability"></a>3.6. Cross-Origin Fingerprinting Unlinkability</h3></div></div></div><p>
830
+     </p></li></ol></div><p>
831
+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">tbb-linkability tag in our bugtracker</a>
832
+  </p></div><div class="sect2" title="4.6. Cross-Origin Fingerprinting Unlinkability"><div class="titlepage"><div><div><h3 class="title"><a id="fingerprinting-linkability"/>4.6. Cross-Origin Fingerprinting Unlinkability</h3></div></div></div><p>
756 833
 
757 834
 In order to properly address the fingerprinting adversary on a technical
758 835
 level, we need a metric to measure linkability of the various browser
759
-properties beyond any stored origin-related state. <a class="ulink" href="https://panopticlick.eff.org/about.php" target="_top">The Panopticlick Project</a>
760
-by the EFF provides us with exactly this metric. The researchers conducted a
761
-survey of volunteers who were asked to visit an experiment page that harvested
762
-many of the above components. They then computed the Shannon Entropy of the
763
-resulting distribution of each of several key attributes to determine how many
764
-bits of identifying information each attribute provided.
836
+properties beyond any stored origin-related state. <a class="ulink" href="https://panopticlick.eff.org/about.php">The Panopticlick Project</a>
837
+by the EFF provides us with a prototype of such a metric. The researchers
838
+conducted a survey of volunteers who were asked to visit an experiment page
839
+that harvested many of the above components. They then computed the Shannon
840
+Entropy of the resulting distribution of each of several key attributes to
841
+determine how many bits of identifying information each attribute provided.
765 842
 
766 843
    </p><p>
767 844
 
768
-The study is not exhaustive, though. In particular, the test does not take in
769
-all aspects of resolution information. It did not calculate the size of
770
-widgets, window decoration, or toolbar size, which we believe may add high
771
-amounts of entropy. It also did not measure clock offset and other time-based
772
-fingerprints. Furthermore, as new browser features are added, this experiment
773
-should be repeated to include them.
845
+Many browser features have been added since the EFF first ran their experiment
846
+and collected their data. To avoid an infinite sinkhole, we reduce the efforts
847
+for fingerprinting resistance by only concerning ourselves with reducing the
848
+fingerprintable differences <span class="emphasis"><em>among</em></span> Tor Browser users. We
849
+do not believe it is possible to solve cross-browser fingerprinting issues.
774 850
 
775 851
    </p><p>
776 852
 
777
-On the other hand, to avoid an infinite sinkhole, we reduce the efforts for
778
-fingerprinting resistance by only concerning ourselves with reducing the
779
-fingerprintable differences <span class="emphasis"><em>among</em></span> Tor Browser users. We
780
-do not believe it is productive to concern ourselves with cross-browser
781
-fingerprinting issues, at least not at this stage.
782
-
783
-   </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem">Plugins
853
+Unfortunately, the unsolvable nature of the cross-browser fingerprinting
854
+problem means that the Panopticlick test website itself is not useful for
855
+evaluating the actual effectiveness of our defenses, or the fingerprinting
856
+defenses of any other web browser. Because the Panopticlick dataset is based
857
+on browser data spanning a number of widely deployed browsers over a number of
858
+years, any fingerprinting defenses attempted by browsers today are very likely
859
+to cause Panopticlick to report an <span class="emphasis"><em>increase</em></span> in
860
+fingerprintability and entropy, because those defenses will stand out in sharp
861
+contrast to historical data. We have been <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/6119">working to convince
862
+the EFF</a> that it is worthwhile to release the source code to
863
+Panopticlick to allow us to run our own version for this reason.
864
+
865
+   </p><div class="sect3" title="Fingerprinting defenses in the Tor Browser"><div class="titlepage"><div><div><h4 class="title"><a id="fingerprinting-defenses"/>Fingerprinting defenses in the Tor Browser</h4></div></div></div><div class="orderedlist"><ol class="orderedlist"><li class="listitem">Plugins
784 866
      <p>
785 867
 
786 868
 Plugins add to fingerprinting risk via two main vectors: their mere presence in
... ...
@@ -792,17 +874,63 @@ All plugins that have not been specifically audited or sandboxed MUST be
792 874
 disabled. To reduce linkability potential, even sandboxed plugins should not
793 875
 be allowed to load objects until the user has clicked through a click-to-play
794 876
 barrier.  Additionally, version information should be reduced or obfuscated
795
-until the plugin object is loaded.
877
+until the plugin object is loaded. For flash, we wish to <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3974">provide a
878
+settings.sol file</a> to disable Flash cookies, and to restrict P2P
879
+features that are likely to bypass proxy settings.
796 880
 
797 881
      </p><p><span class="command"><strong>Implementation Status:</strong></span>
798 882
 
799 883
 Currently, we entirely disable all plugins in Tor Browser. However, as a
800
-compromise due to the popularity of Flash, we intend to <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3974" target="_top">work
801
-towards</a> a
802
-click-to-play barrier using NoScript that is available only after the user has
803
-specifically enabled plugins. Flash will be the only plugin available, and we
804
-will ship a settings.sol file to disable Flash cookies, and to restrict P2P
805
-features that likely bypass proxy settings.
884
+compromise due to the popularity of Flash, we allow users to re-enable Flash,
885
+and flash objects are blocked behind a click-to-play barrier that is available
886
+only after the user has specifically enabled plugins. Flash is the only plugin
887
+available, the rest are <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">entirely
888
+blocked from loading by a Firefox patch</a>. We also set the Firefox
889
+preference <span class="command"><strong>plugin.expose_full_path</strong></span> to false, to avoid
890
+leaking plugin installation information.
891
+
892
+     </p></li><li class="listitem">HTML5 Canvas Image Extraction
893
+     <p>
894
+
895
+The <a class="ulink" href="https://developer.mozilla.org/en-US/docs/HTML/Canvas">HTML5
896
+Canvas</a> is a feature that has been added to major browsers after the
897
+EFF developed their Panopticlick study. After plugins and plugin-provided
898
+information, we believe that the HTML5 Canvas is the single largest
899
+fingerprinting threat browsers face today. <a class="ulink" href="http://www.w2spconf.com/2012/papers/w2sp12-final4.pdf">Initial
900
+studies</a> show that the Canvas can provide an easy-access fingerprinting
901
+target: The adversary simply renders WebGL, font, and named color data to a
902
+Canvas element, extracts the image buffer, and computes a hash of that image
903
+data. Subtle differences in the video card, font packs, and even font and
904
+graphics library versions allow the adversary to produce a stable, simple,
905
+high-entropy fingerprint of a computer. In fact, the hash of the rendered
906
+image can be used almost identically to a tracking cookie by the web server.
907
+
908
+     </p><p>
909
+
910
+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">prompt
911
+before returning valid image data</a> to the Canvas APIs. If the user
912
+hasn't previously allowed the site in the URL bar to access Canvas image data,
913
+pure white image data is returned to the Javascript APIs.
914
+
915
+     </p></li><li class="listitem">WebGL
916
+     <p>
917
+
918
+WebGL is fingerprintable both through information that is exposed about the
919
+underlying driver and optimizations, as well as through performance
920
+fingerprinting.
921
+
922
+     </p><p>
923
+
924
+Because of the large amount of potential fingerprinting vectors and the <a class="ulink" href="http://www.contextis.com/resources/blog/webgl/">previously unexposed
925
+vulnerability surface</a>, we deploy a similar strategy against WebGL as
926
+for plugins. First, WebGL Canvases have click-to-play placeholders (provided
927
+by NoScript), and do not run until authorized by the user. Second, we
928
+obfuscate driver information by setting the Firefox preferences
929
+<span class="command"><strong>webgl.disable-extensions</strong></span> and
930
+<span class="command"><strong>webgl.min_capability_mode</strong></span>, which reduce the information
931
+provided by the following WebGL API calls: <span class="command"><strong>getParameter()</strong></span>,
932
+<span class="command"><strong>getSupportedExtensions()</strong></span>, and
933
+<span class="command"><strong>getExtension()</strong></span>.
806 934
 
807 935
      </p></li><li class="listitem">Fonts
808 936
      <p>
... ...
@@ -819,7 +947,7 @@ still be available.
819 947
 The sure-fire way to address font linkability is to ship the browser with a
820 948
 font for every language, typeface, and style in use in the world, and to only
821 949
 use those fonts at the exclusion of system fonts.  However, this set may be
822
-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
950
+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">common
823 951
 subset</a> may be found that provides total coverage. However, we believe
824 952
 that with strong url bar origin identifier isolation, a simpler approach can reduce the
825 953
 number of bits available to the adversary while avoiding the rendering and
... ...
@@ -829,35 +957,27 @@ language issues of supporting a global font set.
829 957
 
830 958
 We disable plugins, which prevents font enumeration. Additionally, we limit
831 959
 both the number of font queries from CSS, as well as the total number of 
832
-fonts that can be used in a document by patching Firefox. We create two prefs,
960
+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">with
961
+a Firefox patch</a>. We create two prefs,
833 962
 <span class="command"><strong>browser.display.max_font_attempts</strong></span> and
834 963
 <span class="command"><strong>browser.display.max_font_count</strong></span> for this purpose. Once these
835 964
 limits are reached, the browser behaves as if
836 965
 <span class="command"><strong>browser.display.use_document_fonts</strong></span> was reached. We are
837 966
 still working to determine optimal values for these prefs.
838 967
 
839
-     </p></li><li class="listitem">User Agent and HTTP Headers
840
-     <p><span class="command"><strong>Design Goal:</strong></span>
841
-
842
-All Tor Browser users MUST provide websites with an identical user agent and
843
-HTTP header set for a given request type. We omit the Firefox minor revision,
844
-and report a popular Windows platform. If the software is kept up to date,
845
-these headers should remain identical across the population even when updated.
968
+     </p><p>
846 969
 
847
-     </p><p><span class="command"><strong>Implementation Status:</strong></span>
970
+To improve rendering, we exempt remote <a class="ulink" href="https://developer.mozilla.org/en-US/docs/CSS/@font-face">@font-face
971
+fonts</a> from these counts, and if a font-family CSS rule lists a remote
972
+font (in any order), we use that font instead of any of the named local fonts.
848 973
 
849
-Firefox provides several options for controlling the browser user agent string
850
-which we leverage. We also set similar prefs for controlling the
851
-Accept-Language and Accept-Charset headers, which we spoof to English by default. Additionally, we
852
-<a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.2:/src/current-patches/firefox/0001-Block-Components.interfaces-lookupMethod-from-conten.patch" target="_top">remove
853
-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
854
-used</a> to fingerprint OS, platform, and Firefox minor version.  </p></li><li class="listitem">Desktop resolution and CSS Media Queries
974
+     </p></li><li class="listitem">Desktop resolution, CSS Media Queries, and System Colors
855 975
      <p>
856 976
 
857
-Both CSS and Javascript have a lot of irrelevant information about the screen
858
-resolution, usable desktop size, OS widget size, toolbar size, title bar size, and
859
-other desktop features that are not at all relevant to rendering and serve
860
-only to provide information for fingerprinting.
977
+Both CSS and Javascript have access to a lot of information about the screen
978
+resolution, usable desktop size, OS widget size, toolbar size, title bar size,
979
+system theme colors, and other desktop features that are not at all relevant
980
+to rendering and serve only to provide information for fingerprinting.
861 981
 
862 982
      </p><p><span class="command"><strong>Design Goal:</strong></span>
863 983
 
... ...
@@ -867,23 +987,36 @@ report all rendering information correctly with respect to the size and
867 987
 properties of the content window, but report an effective size of 0 for all
868 988
 border material, and also report that the desktop is only as big as the
869 989
 inner content window. Additionally, new browser windows are sized such that 
870
-their content windows are one of ~5 fixed sizes based on the user's
990
+their content windows are one of a few fixed sizes based on the user's
871 991
 desktop resolution.
872 992
 
873 993
      </p><p><span class="command"><strong>Implementation Status:</strong></span>
874 994
 
875
-We have implemented the above strategy for Javascript using Torbutton's <a class="ulink" href="https://gitweb.torproject.org/torbutton.git/blob/HEAD:/src/chrome/content/jshooks4.js" target="_top">JavaScript
876
-hooks</a> as well as a window observer to <a class="ulink" href="https://gitweb.torproject.org/torbutton.git/blob/HEAD:/src/chrome/content/torbutton.js#l4002" target="_top">resize
995
+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">resize
877 996
 new windows based on desktop resolution</a>. Additionally, we patch
878
-Firefox to cause CSS Media Queries to use the client content window size
879
-for all desktop size related media queries.  
997
+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">for
998
+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">for
999
+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">patch
1000
+DOM events to return content window relative points</a>. We also patch
1001
+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">report
1002
+a fixed set of system colors to content window CSS</a>.
880 1003
 
881
-     </p><p>
1004
+     </p></li><li class="listitem">User Agent and HTTP Headers
1005
+     <p><span class="command"><strong>Design Goal:</strong></span>
1006
+
1007
+All Tor Browser users MUST provide websites with an identical user agent and
1008
+HTTP header set for a given request type. We omit the Firefox minor revision,
1009
+and report a popular Windows platform. If the software is kept up to date,
1010
+these headers should remain identical across the population even when updated.
882 1011
 
883
-As far as we know, this fully satisfies our design goals for desktop
884
-resolution information.
1012
+     </p><p><span class="command"><strong>Implementation Status:</strong></span>
885 1013
 
886
-     </p></li><li class="listitem">Timezone and clock offset
1014
+Firefox provides several options for controlling the browser user agent string
1015
+which we leverage. We also set similar prefs for controlling the
1016
+Accept-Language and Accept-Charset headers, which we spoof to English by default. Additionally, we
1017
+<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">remove
1018
+content script access</a> to Components.interfaces, which <a class="ulink" href="http://pseudo-flaw.net/tor/torbutton/fingerprint-firefox.html">can be
1019
+used</a> to fingerprint OS, platform, and Firefox minor version.  </p></li><li class="listitem">Timezone and clock offset
887 1020
      <p><span class="command"><strong>Design Goal:</strong></span>
888 1021
 
889 1022
 All Tor Browser users MUST report the same timezone to websites. Currently, we
... ...
@@ -897,26 +1030,26 @@ values used in Tor Browser to something reasonably accurate.
897 1030
      </p><p><span class="command"><strong>Implementation Status:</strong></span>
898 1031
 
899 1032
 We set the timezone using the TZ environment variable, which is supported on
900
-all platforms. Additionally, we plan to <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3652" target="_top">obtain a clock
1033
+all platforms. Additionally, we plan to <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3652">obtain a clock
901 1034
 offset from Tor</a>, but this won't be available until Tor 0.2.3.x is in
902 1035
 use.
903 1036
 
904 1037
      </p></li><li class="listitem">Javascript performance fingerprinting
905 1038
      <p>
906 1039
 
907
-<a class="ulink" href="http://w2spconf.com/2011/papers/jspriv.pdf" target="_top">Javascript performance
1040
+<a class="ulink" href="http://w2spconf.com/2011/papers/jspriv.pdf">Javascript performance
908 1041
 fingerprinting</a> is the act of profiling the performance
909 1042
 of various Javascript functions for the purpose of fingerprinting the
910 1043
 Javascript engine and the CPU.
911 1044
 
912 1045
      </p><p><span class="command"><strong>Design Goal:</strong></span>
913 1046
 
914
-We have <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3059" target="_top">several potential
1047
+We have <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3059">several potential
915 1048
 mitigation approaches</a> to reduce the accuracy of performance
916 1049
 fingerprinting without risking too much damage to functionality. Our current
917 1050
 favorite is to reduce the resolution of the Event.timeStamp and the Javascript
918 1051
 Date() object, while also introducing jitter. Our goal is to increase the
919
-amount of time it takes to mount a successful attack. <a class="ulink" href="http://w2spconf.com/2011/papers/jspriv.pdf" target="_top">Mowery et al</a> found that
1052
+amount of time it takes to mount a successful attack. <a class="ulink" href="http://w2spconf.com/2011/papers/jspriv.pdf">Mowery et al</a> found that
920 1053
 even with the default precision in most browsers, they required up to 120
921 1054
 seconds of amortization and repeated trials to get stable results from their
922 1055
 feature set. We intend to work with the research community to establish the
... ...
@@ -925,7 +1058,20 @@ optimum trade-off between quantization+jitter and amortization time.
925 1058
 
926 1059
      </p><p><span class="command"><strong>Implementation Status:</strong></span>
927 1060
 
928
-We have no implementation as of yet.
1061
+Currently, the only mitigation against performance fingerprinting is to
1062
+disable <a class="ulink" href="http://www.w3.org/TR/navigation-timing/">Navigation
1063
+Timing</a> through the Firefox preference
1064
+<span class="command"><strong>dom.enable_performance</strong></span>.
1065
+
1066
+     </p></li><li class="listitem">Non-Uniform HTML5 API Implementations
1067
+     <p>
1068
+
1069
+At least two HTML5 features have different implementation status across the
1070
+major OS vendors: the <a class="ulink" href="https://developer.mozilla.org/en-US/docs/DOM/window.navigator.battery">Battery
1071
+API</a> and the <a class="ulink" href="https://developer.mozilla.org/en-US/docs/DOM/window.navigator.connection">Network
1072
+Connection API</a>. We disable these APIs
1073
+through the Firefox preferences <span class="command"><strong>dom.battery.enabled</strong></span> and
1074
+<span class="command"><strong>dom.network.enabled</strong></span>. 
929 1075
 
930 1076
      </p></li><li class="listitem">Keystroke fingerprinting
931 1077
      <p>
... ...
@@ -940,90 +1086,71 @@ fingerprinting: timestamp quantization and jitter.
940 1086
 
941 1087
      </p><p><span class="command"><strong>Implementation Status:</strong></span>
942 1088
 We have no implementation as of yet.
943
-     </p></li><li class="listitem">WebGL
944
-     <p>
1089
+     </p></li></ol></div></div><p>
1090
+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">tbb-fingerprinting tag in our bugtracker</a>
1091
+  </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"/>4.7. Long-Term Unlinkability via "New Identity" button</h3></div></div></div><p>
945 1092
 
946
-WebGL is fingerprintable both through information that is exposed about the
947
-underlying driver and optimizations, as well as through performance
948
-fingerprinting.
1093
+In order to avoid long-term linkability, we provide a "New Identity" context
1094
+menu option in Torbutton. This context menu option is active if Torbutton can
1095
+read the environment variables $TOR_CONTROL_PASSWD and $TOR_CONTROL_PORT.
949 1096
 
950
-     </p><p><span class="command"><strong>Design Goal:</strong></span>
1097
+   </p><div class="sect3" title="Design Goal:"><div class="titlepage"><div><div><h4 class="title"><a id="idp5665856"/>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote">
951 1098
 
952
-Because of the large amount of potential fingerprinting vectors, we intend to
953
-deploy a similar strategy against WebGL as for plugins. First, WebGL canvases
954
-will have click-to-play placeholders, and will not run until authorized by the
955
-user. Second, we intend to <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3323" target="_top">obfuscate driver
956
-information</a> by hooking
957
-<span class="command"><strong>getParameter()</strong></span>,
958
-<span class="command"><strong>getSupportedExtensions()</strong></span>,
959
-<span class="command"><strong>getExtension()</strong></span>, and
960
-<span class="command"><strong>getContextAttributes()</strong></span> to provide standard minimal,
961
-driver-neutral information.
1099
+All linkable identifiers and browser state MUST be cleared by this feature.
962 1100
 
963
-     </p><p><span class="command"><strong>Implementation Status:</strong></span>
1101
+    </blockquote></div></div><div class="sect3" title="Implementation Status:"><div class="titlepage"><div><div><h4 class="title"><a id="idp5667104"/>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p>
964 1102
 
965
-Currently we simply disable WebGL. 
1103
+First, Torbutton disables Javascript in all open tabs and windows by using
1104
+both the <a class="ulink" href="https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIDocShell#Attributes">browser.docShell.allowJavascript</a>
1105
+attribute as well as <a class="ulink" href="https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIDOMWindowUtils#suppressEventHandling%28%29">nsIDOMWindowUtil.suppressEventHandling()</a>.
1106
+We then stop all page activity for each tab using <a class="ulink" href="https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIWebNavigation#stop%28%29">browser.webNavigation.stop(nsIWebNavigation.STOP_ALL)</a>.
1107
+We then clear the site-specific Zoom by temporarily disabling the preference
1108
+<span class="command"><strong>browser.zoom.siteSpecific</strong></span>, and clear the GeoIP wiki token
1109
+URL and the last opened URL prefs (if they exist). Each tab is then closed.
966 1110
 
967
-     </p></li></ol></div></div><div class="sect2" title="3.7. Long-Term Unlinkability via &quot;New Identity&quot; button"><div class="titlepage"><div><div><h3 class="title"><a id="new-identity"></a>3.7. Long-Term Unlinkability via "New Identity" button</h3></div></div></div><p>
968
-In order to avoid long-term linkability, we provide a "New Identity" context
969
-menu option in Torbutton.
970
-   </p><div class="sect3" title="Design Goal:"><div class="titlepage"><div><div><h4 class="title"><a id="id2637889"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote">
1111
+     </p><p>
971 1112
 
972
-All linkable identifiers and browser state MUST be cleared by this feature.
1113
+After closing all tabs, we then clear the following state: searchbox and
1114
+findbox text, HTTP auth, SSL state, OCSP state, site-specific content
1115
+preferences (including HSTS state), content and image cache, Cookies, DOM
1116
+storage, safe browsing key, and the Google wifi geolocation token (if it
1117
+exists). 
973 1118
 
974
-    </blockquote></div></div><div class="sect3" title="Implementation Status:"><div class="titlepage"><div><div><h4 class="title"><a id="id2630536"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote">
975
-
976
-First, Torbutton disables all open tabs and windows by tagging them and
977
-blocking them via the nsIContentPolicy, and then closes each tab and
978
-window. The extra step for blocking tabs is done as a precaution to ensure
979
-that any asynchronous Javascript is in fact properly disabled. After closing
980
-all of the windows, we then clear the following state: OCSP (by toggling
981
-security.OCSP.enabled), cache, site-specific zoom and content preferences,
982
-Cookies, DOM storage, safe browsing key, the Google wifi geolocation token (if
983
-exists), HTTP auth, SSL Session IDs, HSTS state, close all remaining HTTP
984
-keep-alive connections, and clear the last opened URL field (via the pref
985
-general.open_location.last_url).  After clearing the browser state, we then
986
-send the NEWNYM signal to the Tor control port to cause a new circuit to be
987
-created.
1119
+     </p><p>
988 1120
 
989
-    </blockquote></div><div class="blockquote"><blockquote class="blockquote">
990
-Additionally, the user is allowed to "protect" cookies of their choosing from
991
-deletion during New Identity by using the Torbutton Cookie Protections UI to
992
-protect the cookies they would like to keep across New Identity invocations.
993
-    </blockquote></div></div></div><div class="sect2" title="3.8. Click-to-play for plugins and invasive content"><div class="titlepage"><div><div><h3 class="title"><a id="click-to-play"></a>3.8. Click-to-play for plugins and invasive content</h3></div></div></div><p>
994
-Some content types are too invasive and/or too opaque for us to properly
995
-eliminate their linkability properties. For these content types, we use
996
-NoScript to provide click-to-play placeholders that do not activate the
997
-content until the user clicks on it. This will eliminate the ability for an
998
-adversary to use such content types to link users in a dragnet fashion across
999
-arbitrary sites.
1121
+After the state is cleared, we then close all remaining HTTP keep-alive
1122
+connections and then send the NEWNYM signal to the Tor control port to cause a
1123
+new circuit to be created.
1000 1124
      </p><p>
1001
-Currently, the content types isolated in this way include Flash, WebGL, and
1002
-audio and video objects.
1003
-   </p></div><div class="sect2" title="3.9. Description of Firefox Patches"><div class="titlepage"><div><div><h3 class="title"><a id="firefox-patches"></a>3.9. Description of Firefox Patches</h3></div></div></div><p>
1004
-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.2:/src/current-patches/firefox" target="_top">current-patches directory of the torbrowser git repository</a>. They are:
1005
-   </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem">Block Components.interfaces and Components.lookupMethod
1006
-     <p>
1125
+Finally, a fresh browser window is opened, and the current browser window is
1126
+closed.
1127
+     </p></blockquote></div><div class="blockquote"><blockquote class="blockquote">
1128
+If the user chose to "protect" any cookies by using the Torbutton Cookie
1129
+Protections UI, those cookies are not cleared as part of the above.
1130
+    </blockquote></div></div></div><div class="sect2" title="4.8. Description of Firefox Patches"><div class="titlepage"><div><div><h3 class="title"><a id="firefox-patches"/>4.8. Description of Firefox Patches</h3></div></div></div><p>
1007 1131
 
1008
-In order to reduce fingerprinting, we block access to these two interfaces
1009
-from content script. Components.lookupMethod can undo our <a class="ulink" href="https://gitweb.torproject.org/torbutton.git/blob/HEAD:/src/chrome/content/jshooks4.js" target="_top">Javascript
1010
-hooks</a>,
1011
-and Components.interfaces can be used for fingerprinting the platform, OS, and
1012
-Firebox version, but not much else.
1132
+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">current-patches directory of the torbrowser git repository</a>. They are:
1013 1133
 
1014
-     </p></li><li class="listitem">Make Permissions Manager memory only
1015
-     <p>
1134
+   </p><div class="orderedlist"><ol class="orderedlist"><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">Block
1135
+Components.interfaces</a><p>
1136
+
1137
+In order to reduce fingerprinting, we block access to this interface from
1138
+content script. Components.interfaces can be used for fingerprinting the
1139
+platform, OS, and Firebox version, but not much else.
1140
+
1141
+     </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">Make
1142
+Permissions Manager memory only</a><p>
1016 1143
 
1017 1144
 This patch exposes a pref 'permissions.memory_only' that properly isolates the
1018 1145
 permissions manager to memory, which is responsible for all user specified
1019
-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>
1146
+site permissions, as well as stored <a class="ulink" href="https://secure.wikimedia.org/wikipedia/en/wiki/HTTP_Strict_Transport_Security">HSTS</a>
1020 1147
 policy from visited sites.
1021 1148
 
1022 1149
 The pref does successfully clear the permissions manager memory if toggled. It
1023 1150
 does not need to be set in prefs.js, and can be handled by Torbutton.
1024 1151
 
1025
-     </p></li><li class="listitem">Make Intermediate Cert Store memory-only
1026
-     <p>
1152
+     </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">Make
1153
+Intermediate Cert Store memory-only</a><p>
1027 1154
 
1028 1155
 The intermediate certificate store records the intermediate SSL certificates
1029 1156
 the browser has seen to date. Because these intermediate certificates are used 
... ...
@@ -1037,153 +1164,257 @@ As an additional design goal, we would like to later alter this patch to allow t
1037 1164
 information to be cleared from memory. The implementation does not currently
1038 1165
 allow this.
1039 1166
 
1040
-     </p></li><li class="listitem">Add HTTP auth headers before on-modify-request fires
1041
-     <p>
1042
-
1043
-This patch provides a trivial modification to allow us to properly remove HTTP
1044
-auth for third parties. This patch allows us to defend against an adversary
1045
-attempting to use <a class="ulink" href="http://jeremiahgrossman.blogspot.com/2007/04/tracking-users-without-cookies.html" target="_top">HTTP
1046
-auth to silently track users between domains</a>.
1167
+     </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">Add
1168
+a string-based cacheKey property for domain isolation</a><p>
1047 1169
 
1048
-     </p></li><li class="listitem">Add a string-based cacheKey property for domain isolation
1049
-     <p>
1050
-
1051
-To <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3666" target="_top">increase the
1052
-security of cache isolation</a> and to <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3754" target="_top">solve strange and
1053
-unknown conflicts with OCSP</a>, we had to <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/refs/heads/maint-2.2:/src/current-patches/0005-Add-a-string-based-cacheKey.patch" target="_top">patch
1054
-Firefox to provide a cacheDomain cache attribute</a>. We use the url bar
1170
+To <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3666">increase the
1171
+security of cache isolation</a> and to <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3754">solve strange and
1172
+unknown conflicts with OCSP</a>, we had to patch
1173
+Firefox to provide a cacheDomain cache attribute. We use the url bar
1055 1174
 FQDN as input to this field.
1056 1175
 
1057
-     </p></li><li class="listitem">Randomize HTTP pipeline order and depth
1058
-     <p>
1059
-As an 
1060
-<a class="ulink" href="https://blog.torproject.org/blog/experimental-defense-website-traffic-fingerprinting" target="_top">experimental
1061
-defense against Website Traffic Fingerprinting</a>, we patch the standard
1062
-HTTP pipelining code to randomize the number of requests in a
1063
-pipeline, as well as their order.
1064
-     </p></li><li class="listitem">Block all plugins except flash
1065
-     <p>
1066
-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">
1176
+     </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">Block
1177
+all plugins except flash</a><p>
1178
+We cannot use the <a class="ulink" href="http://www.oxymoronical.com/experiments/xpcomref/applications/Firefox/3.5/components/@mozilla.org/extensions/blocklist%3B1">
1067 1179
 @mozilla.org/extensions/blocklist;1</a> service, because we
1068 1180
 actually want to stop plugins from ever entering the browser's process space
1069 1181
 and/or executing code (for example, AV plugins that collect statistics/analyze
1070
-URLs, magical toolbars that phone home or "help" the user, skype buttons that
1182
+URLs, magical toolbars that phone home or "help" the user, Skype buttons that
1071 1183
 ruin our day, and censorship filters). Hence we rolled our own.
1072
-     </p></li><li class="listitem">Make content-prefs service memory only
1073
-     <p>
1074
-This patch prevents random URLs from being inserted into content-prefs.sqllite in
1184
+     </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">Make content-prefs service memory only</a><p>
1185
+This patch prevents random URLs from being inserted into content-prefs.sqlite in
1075 1186
 the profile directory as content prefs change (includes site-zoom and perhaps
1076 1187
 other site prefs?).
1077
-     </p></li><li class="listitem">Make Tor Browser exit when not launched from Vidalia
1078
-     <p>
1188
+     </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">Make Tor Browser exit when not launched from Vidalia</a><p>
1079 1189
 
1080 1190
 It turns out that on Windows 7 and later systems, the Taskbar attempts to
1081 1191
 automatically learn the most frequent apps used by the user, and it recognizes
1082
-Tor Browser as a seperate app from Vidalia. This can cause users to try to
1083
-launch Tor Brower without Vidalia or a Tor instance running. Worse, the Tor
1192
+Tor Browser as a separate app from Vidalia. This can cause users to try to
1193
+launch Tor Browser without Vidalia or a Tor instance running. Worse, the Tor
1084 1194
 Browser will automatically find their default Firefox profile, and properly
1085 1195
 connect directly without using Tor. This patch is a simple hack to cause Tor
1086 1196
 Browser to immediately exit in this case.
1087 1197
 
1088
-     </p></li><li class="listitem">Disable SSL Session ID tracking
1089
-     <p>
1198
+     </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">Disable SSL Session ID tracking</a><p>
1090 1199
 
1091 1200
 This patch is a simple 1-line hack to prevent SSL connections from caching
1092 1201
 (and then later transmitting) their Session IDs. There was no preference to
1093 1202
 govern this behavior, so we had to hack it by altering the SSL new connection
1094 1203
 defaults.
1095 1204
 
1096
-     </p></li><li class="listitem">Provide an observer event to close persistent connections
1097
-     <p>
1205
+     </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">Provide an observer event to close persistent connections</a><p>
1098 1206
 
1099 1207
 This patch creates an observer event in the HTTP connection manager to close
1100 1208
 all keep-alive connections that still happen to be open. This event is emitted
1101
-by the <a class="link" href="#new-identity" title="3.7. Long-Term Unlinkability via &quot;New Identity&quot; button">New Identity</a> button.
1209
+by the <a class="link" href="#new-identity" title="4.7. Long-Term Unlinkability via &quot;New Identity&quot; button">New Identity</a> button.
1210
+
1211
+     </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">Limit Device and System Specific Media Queries</a><p>
1212
+
1213
+<a class="ulink" href="https://developer.mozilla.org/en-US/docs/CSS/Media_queries">CSS
1214
+Media Queries</a> have a fingerprinting capability approaching that of
1215
+Javascript. This patch causes such Media Queries to evaluate as if the device
1216
+resolution was equal to the content window resolution.
1217
+
1218
+     </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">Limit the number of fonts per document</a><p>
1219
+
1220
+Font availability can be <a class="ulink" href="http://flippingtypical.com/">queried by
1221
+CSS and Javascript</a> and is a fingerprinting vector. This patch limits
1222
+the number of times CSS and Javascript can cause font-family rules to
1223
+evaluate. Remote @font-face fonts are exempt from the limits imposed by this
1224
+patch, and remote fonts are given priority over local fonts whenever both
1225
+appear in the same font-family rule.
1226
+
1227
+     </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">Rebrand Firefox to Tor Browser</a><p>
1228
+
1229
+This patch updates our branding in compliance with Mozilla's trademark policy.
1230
+
1231
+     </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">Make Download Manager Memory Only</a><p>
1232
+
1233
+This patch prevents disk leaks from the download manager. The original
1234
+behavior is to write the download history to disk and then delete it, even if
1235
+you disable download history from your Firefox preferences.
1236
+
1237
+     </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">Add DDG and StartPage to Omnibox</a><p>
1238
+
1239
+This patch adds DuckDuckGo and StartPage to the Search Box, and sets our
1240
+default search engine to StartPage. We deployed this patch due to excessive
1241
+Captchas and complete 403 bans from Google.
1242
+
1243
+     </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">Make nsICacheService.EvictEntries() Synchronous</a><p>
1244
+
1245
+This patch eliminates a race condition with "New Identity". Without it,
1246
+cache-based Evercookies survive for up to a minute after clearing the cache
1247
+on some platforms.
1248
+
1249
+     </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">Prevent WebSockets DNS Leak</a><p>
1250
+
1251
+This patch prevents a DNS leak when using WebSockets. It also prevents other
1252
+similar types of DNS leaks.
1253
+
1254
+     </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">Randomize HTTP pipeline order and depth</a><p>
1255
+As an 
1256
+<a class="ulink" href="https://blog.torproject.org/blog/experimental-defense-website-traffic-fingerprinting">experimental
1257
+defense against Website Traffic Fingerprinting</a>, we patch the standard
1258
+HTTP pipelining code to randomize the number of requests in a
1259
+pipeline, as well as their order.
1260
+     </p></li><li class="listitem"><a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0018-Adapt-Steven-Michaud-s-Mac-crashfix-patch.patch">Adapt Steve Michaud's Mac crashfix patch</a><p>
1261
+
1262
+This patch allows us to block Drag and Drop without causing crashes on Mac OS.
1263
+We need to block Drag and Drop because Mac OS and Ubuntu both immediately load
1264
+any URLs they find in your drag buffer before you even drop them (without
1265
+using your browser's proxy settings, of course).
1266
+
1267
+     </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">Add mozIThirdPartyUtil.getFirstPartyURI() API</a><p>
1102 1268
 
1103
-     </p></li></ol></div></div></div><div class="sect1" title="4. Packaging"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Packaging"></a>4. Packaging</h2></div></div></div><p> </p><div class="sect2" title="4.1. Build Process Security"><div class="titlepage"><div><div><h3 class="title"><a id="build-security"></a>4.1. Build Process Security</h3></div></div></div><p> </p></div><div class="sect2" title="4.2. External Addons"><div class="titlepage"><div><div><h3 class="title"><a id="addons"></a>4.2. External Addons</h3></div></div></div><p> </p><div class="sect3" title="Included Addons"><div class="titlepage"><div><div><h4 class="title"><a id="id2611402"></a>Included Addons</h4></div></div></div></div><div class="sect3" title="Excluded Addons"><div class="titlepage"><div><div><h4 class="title"><a id="id2611409"></a>Excluded Addons</h4></div></div></div></div><div class="sect3" title="Dangerous Addons"><div class="titlepage"><div><div><h4 class="title"><a id="id2611419"></a>Dangerous Addons</h4></div></div></div></div></div><div class="sect2" title="4.3. Pref Changes"><div class="titlepage"><div><div><h3 class="title"><a id="prefs"></a>4.3. Pref Changes</h3></div></div></div><p> </p></div><div class="sect2" title="4.4. Update Security"><div class="titlepage"><div><div><h3 class="title"><a id="update-mechanism"></a>4.4. Update Security</h3></div></div></div><p> </p></div></div><div class="sect1" title="5. Testing"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Testing"></a>5. Testing</h2></div></div></div><p>
1269
+This patch provides an API that allows us to more easily isolate identifiers
1270
+to the URL bar domain.
1104 1271
 
1105
-The purpose of this section is to cover all the known ways that Tor browser
1106
-security can be subverted from a penetration testing perspective. The hope
1107
-is that it will be useful both for creating a "Tor Safety Check"
1108
-page, and for developing novel tests and actively attacking Torbutton with the
1109
-goal of finding vulnerabilities in either it or the Mozilla components,
1110
-interfaces and settings upon which it relies.
1272
+     </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">Add canvas image extraction prompt</a><p>
1111 1273
 
1112
-  </p><div class="sect2" title="5.1. Single state testing"><div class="titlepage"><div><div><h3 class="title"><a id="SingleStateTesting"></a>5.1. Single state testing</h3></div></div></div><p>
1274
+This patch prompts the user before returning canvas image data. Canvas image
1275
+data can be used to create an extremely stable, high-entropy fingerprint based
1276
+on the unique rendering behavior of video cards, OpenGL behavior,
1277
+system fonts, and supporting library versions.
1113 1278
 
1114
-Torbutton is a complicated piece of software. During development, changes to
1115
-one component can affect a whole slough of unrelated features.  A number of
1116
-aggregated test suites exist that can be used to test for regressions in
1117
-Torbutton and to help aid in the development of Torbutton-like addons and
1118
-other privacy modifications of other browsers. Some of these test suites exist
1119
-as a single automated page, while others are a series of pages you must visit
1120
-individually. They are provided here for reference and future regression
1121
-testing, and also in the hope that some brave soul will one day decide to
1122
-combine them into a comprehensive automated test suite.
1279
+     </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">Return client window coordinates for mouse events</a><p>
1123 1280
 
1124
-     </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><a class="ulink" href="http://decloak.net/" target="_top">Decloak.net</a><p>
1281
+This patch causes mouse events to return coordinates relative to the content
1282
+window instead of the desktop.
1125 1283
 
1126
-Decloak.net is the canonical source of plugin and external-application based
1127
-proxy-bypass exploits. It is a fully automated test suite maintained by <a class="ulink" href="http://digitaloffense.net/" target="_top">HD Moore</a> as a service for people to
1128
-use to test their anonymity systems.
1284
+     </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">Do not expose physical screen info to window.screen</a><p>
1129 1285
 
1130
-       </p></li><li class="listitem"><a class="ulink" href="http://deanonymizer.com/" target="_top">Deanonymizer.com</a><p>
1286
+This patch causes window.screen to return the display resolution size of the
1287
+content window instead of the desktop resolution size.
1131 1288
 
1132
-Deanonymizer.com is another automated test suite that tests for proxy bypass
1133
-and other information disclosure vulnerabilities. It is maintained by Kyle
1134
-Williams, the author of <a class="ulink" href="http://www.janusvm.com/" target="_top">JanusVM</a>
1135
-and <a class="ulink" href="http://www.januspa.com/" target="_top">JanusPA</a>.
1289
+     </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">Do not expose system colors to CSS or canvas</a><p>
1136 1290
 
1137
-       </p></li><li class="listitem"><a class="ulink" href="https://ip-check.info" target="_top">JonDos
1138
-AnonTest</a><p>
1291
+This patch prevents CSS and Javascript from discovering your desktop color
1292
+scheme and/or theme.
1139 1293
 
1140
-The <a class="ulink" href="https://anonymous-proxy-servers.net/" target="_top">JonDos people</a> also provide an
1141
-anonymity tester. It is more focused on HTTP headers and behaviors than plugin bypass, and
1142
-points out a couple of headers Torbutton could do a better job with
1143
-obfuscating.
1294
+     </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">Isolate the Image Cache per url bar domain</a><p>
1144 1295
 
1145
-       </p></li><li class="listitem"><a class="ulink" href="http://browserspy.dk" target="_top">Browserspy.dk</a><p>
1296
+This patch prevents cached images from being used to store third party tracking
1297
+identifiers.
1146 1298
 
1147
-Browserspy.dk provides a tremendous collection of browser fingerprinting and
1148
-general privacy tests. Unfortunately they are only available one page at a
1149
-time, and there is not really solid feedback on good vs bad behavior in
1150
-the test results.
1299
+     </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">nsIHTTPChannel.redirectTo() API</a><p>
1151 1300
 
1152
-       </p></li><li class="listitem"><a class="ulink" href="http://analyze.privacy.net/" target="_top">Privacy
1153
-Analyzer</a><p>
1301
+This patch provides HTTPS-Everywhere with an API to perform redirections more
1302
+securely and without addon conflicts.
1154 1303
 
1155
-The Privacy Analyzer provides a dump of all sorts of browser attributes and
1156
-settings that it detects, including some information on your original IP
1157
-address. Its page layout and lack of good vs bad test result feedback makes it
1158
-not as useful as a user-facing testing tool, but it does provide some
1159
-interesting checks in a single page.
1304
+     </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">Isolate DOM Storage to first party URI</a><p>
1160 1305
 
1161
-       </p></li><li class="listitem"><a class="ulink" href="http://ha.ckers.org/mr-t/" target="_top">Mr. T</a><p>
1306
+This patch prevents DOM Storage from being used to store third party tracking
1307
+identifiers.
1162 1308
 
1163
-Mr. T is a collection of browser fingerprinting and deanonymization exploits
1164
-discovered by the <a class="ulink" href="http://ha.ckers.org" target="_top">ha.ckers.org</a> crew
1165
-and others. It is also not as user friendly as some of the above tests, but it
1166
-is a useful collection.
1309
+     </p></li></ol></div></div></div><div class="appendix" title="A. Towards Transparency in Navigation Tracking"><h2 class="title"><a id="Transparency"/>A. Towards Transparency in Navigation Tracking</h2><p>
1167 1310
 
1168
-       </p></li><li class="listitem">Gregory Fleischer's <a class="ulink" href="http://pseudo-flaw.net/content/tor/torbutton/" target="_top">Torbutton</a> and
1169
-<a class="ulink" href="http://pseudo-flaw.net/content/defcon/dc-17-demos/d.html" target="_top">Defcon
1170
-17</a> Test Cases
1311
+The <a class="link" href="#privacy" title="2.2. Privacy Requirements">privacy properties</a> of Tor Browser are based
1312
+upon the assumption that link-click navigation indicates user consent to
1313
+tracking between the linking site and the destination site.  While this
1314
+definition is sufficient to allow us to eliminate cross-site third party
1315
+tracking with only minimal site breakage, it is our long-term goal to further
1316
+reduce cross-origin click navigation tracking to mechanisms that are
1317
+detectable by attentive users, so they can alert the general public if
1318
+cross-origin click navigation tracking is happening where it should not be.
1319
+
1320
+</p><p>
1321
+
1322
+In an ideal world, the mechanisms of tracking that can be employed during a
1323
+link click would be limited to the contents of URL parameters and other
1324
+properties that are fully visible to the user before they click. However, the
1325
+entrenched nature of certain archaic web features make it impossible for us to
1326
+achieve this transparency goal by ourselves without substantial site breakage.
1327
+So, instead we maintain a <a class="link" href="#deprecate" title="A.1. Deprecation Wishlist">Deprecation
1328
+Wishlist</a> of archaic web technologies that are currently being (ab)used
1329
+to facilitate federated login and other legitimate click-driven cross-domain
1330
+activity but that can one day be replaced with more privacy friendly,
1331
+auditable alternatives.
1332
+
1333
+</p><p>
1334
+
1335
+Because the total elimination of side channels during cross-origin navigation
1336
+will undoubtedly break federated login as well as destroy ad revenue, we
1337
+also describe auditable alternatives and promising web draft standards that would
1338
+preserve this functionality while still providing transparency when tracking is
1339
+occurring. 
1340
+
1341
+</p><div class="sect2" title="A.1. Deprecation Wishlist"><div class="titlepage"><div><div><h3 class="title"><a id="deprecate"/>A.1. Deprecation Wishlist</h3></div></div></div><div class="orderedlist"><ol class="orderedlist"><li class="listitem">The Referer Header
1171 1342
   <p>
1172 1343
 
1173
-Gregory Fleischer has been hacking and testing Firefox and Torbutton privacy
1174
-issues for the past 2 years. He has an excellent collection of all his test
1175
-cases that can be used for regression testing. In his Defcon work, he
1176
-demonstrates ways to infer Firefox version based on arcane browser properties.
1177
-We are still trying to determine the best way to address some of those test
1178
-cases.
1344
+We haven't disabled or restricted the referer ourselves because of the
1345
+non-trivial number of sites that rely on the referer header to "authenticate"
1346
+image requests and deep-link navigation on their sites. Furthermore, there
1347
+seems to be no real privacy benefit to taking this action by itself in a
1348
+vacuum, because many sites have begun encoding referer URL information into
1349
+GET parameters when they need it to cross http to https scheme transitions.
1350
+Google's +1 buttons are the best example of this activity.
1179 1351
 
1180
-       </p></li><li class="listitem"><a class="ulink" href="https://torcheck.xenobite.eu/index.php" target="_top">Xenobite's
1181
-TorCheck Page</a><p>
1352
+  </p><p>
1182 1353
 
1183
-This page checks to ensure you are using a valid Tor exit node and checks for
1184
-some basic browser properties related to privacy. It is not very fine-grained
1185
-or complete, but it is automated and could be turned into something useful
1186
-with a bit of work.
1354
+Because of the availability of these other explicit vectors, we believe the
1355
+main risk of the referer header is through inadvertent and/or covert data
1356
+leakage.  In fact, <a class="ulink" href="http://www2.research.att.com/~bala/papers/wosn09.pdf">a great deal of
1357
+personal data</a> is inadvertently leaked to third parties through the
1358
+source URL parameters. 
1187 1359
 
1188
-       </p></li></ol></div><p>
1189
-    </p></div></div></div></body></html>
1360
+  </p><p>
1361
+
1362
+We believe the Referer header should be made explicit. If a site wishes to
1363
+transmit its URL to third party content elements during load or during
1364
+link-click, it should have to specify this as a property of the associated
1365
+HTML tag. With an explicit property, it would then be possible for the user
1366
+agent to inform the user if they are about to click on a link that will
1367
+transmit referer information (perhaps through something as subtle as a
1368
+different color for the destination URL). This same UI notification can also
1369
+be used for links with the <a class="ulink" href="https://developer.mozilla.org/en-US/docs/HTML/Element/a#Attributes">"ping"</a>
1370
+attribute.
1371
+
1372
+  </p></li><li class="listitem">window.name
1373
+   <p>
1374
+<a class="ulink" href="https://developer.mozilla.org/En/DOM/Window.name">window.name</a> is
1375
+a DOM property that for some reason is allowed to retain a persistent value
1376
+for the lifespan of a browser tab. It is possible to utilize this property for
1377
+<a class="ulink" href="http://www.thomasfrank.se/sessionvars.html">identifier
1378
+storage</a> during click navigation. This is sometimes used for additional
1379
+XSRF protection and federated login.
1380
+   </p><p>
1381
+
1382
+It's our opinion that the contents of window.name should not be preserved for
1383
+cross-origin navigation, but doing so may break federated login for some sites.
1384
+
1385
+   </p></li><li class="listitem">Javascript link rewriting
1386
+   <p>
1387
+
1388
+In general, it should not be possible for onclick handlers to alter the
1389
+navigation destination of 'a' tags, silently transform them into POST
1390
+requests, or otherwise create situations where a user believes they are
1391
+clicking on a link leading to one URL that ends up on another. This
1392
+functionality is deceptive and is frequently a vector for malware and phishing
1393
+attacks. Unfortunately, many legitimate sites also employ such transparent
1394
+link rewriting, and blanket disabling this functionality ourselves will simply
1395
+cause Tor Browser to fail to navigate properly on these sites.
1396
+
1397
+   </p><p>
1398
+
1399
+Automated cross-origin redirects are one form of this behavior that is
1400
+possible for us to <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3600">address
1401
+ourselves</a>, as they are comparatively rare and can be handled with site
1402
+permissions.
1403
+
1404
+   </p></li></ol></div></div><div class="sect2" title="A.2. Promising Standards"><div class="titlepage"><div><div><h3 class="title"><a id="idp5752304"/>A.2. Promising Standards</h3></div></div></div><div class="orderedlist"><ol class="orderedlist"><li class="listitem"><a class="ulink" href="http://web-send.org">Web-Send Introducer</a><p>
1405
+
1406
+Web-Send is a browser-based link sharing and federated login widget that is
1407
+designed to operate without relying on third-party tracking or abusing other
1408
+cross-origin link-click side channels. It has a compelling list of <a class="ulink" href="http://web-send.org/features.html">privacy and security features</a>,
1409
+especially if used as a "Like button" replacement.
1410
+
1411
+   </p></li><li class="listitem"><a class="ulink" href="https://developer.mozilla.org/en-US/docs/Persona">Mozilla Persona</a><p>
1412
+
1413
+Mozilla's Persona is designed to provide decentralized, cryptographically
1414
+authenticated federated login in a way that does not expose the user to third
1415
+party tracking or require browser redirects or side channels. While it does
1416
+not directly provide the link sharing capabilities that Web-Send does, it is a
1417
+better solution to the privacy issues associated with federated login than
1418
+Web-Send is.
1419
+
1420
+   </p></li></ol></div></div></div></div></body></html>
1190 1421