Browse code

Update Tor Browser design doc (for 7.0.X series)

Georg Koppen authored on24/01/2018 10:16:16
Showing1 changed files
... ...
@@ -1,9 +1,9 @@
1 1
 <?xml version="1.0" encoding="UTF-8"?>
2
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><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.79.1" /></head><body><div class="article"><div class="titlepage"><div><div><h2 class="title"><a id="design"></a>The Design and Implementation of the Tor Browser [DRAFT]</h2></div><div><div class="author"><h3 class="author"><span class="firstname">Mike</span> <span class="surname">Perry</span></h3><div class="affiliation"><div class="address"><p><code class="email">&lt;<a class="email" href="mailto:mikeperry#torproject org">mikeperry#torproject org</a>&gt;</code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Erinn</span> <span class="surname">Clark</span></h3><div class="affiliation"><div class="address"><p><code class="email">&lt;<a class="email" href="mailto:erinn#torproject org">erinn#torproject org</a>&gt;</code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Steven</span> <span class="surname">Murdoch</span></h3><div class="affiliation"><div class="address"><p><code class="email">&lt;<a class="email" href="mailto:sjmurdoch#torproject org">sjmurdoch#torproject org</a>&gt;</code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Georg</span> <span class="surname">Koppen</span></h3><div class="affiliation"><div class="address"><p><code class="email">&lt;<a class="email" href="mailto:gk#torproject org">gk#torproject org</a>&gt;</code></p></div></div></div></div><div><p class="pubdate">March 10th, 2017</p></div></div><hr /></div><div class="toc"><p><strong>Table of Contents</strong></p><dl class="toc"><dt><span class="sect1"><a href="#idm29">1. Introduction</a></span></dt><dd><dl><dt><span class="sect2"><a href="#components">1.1. Browser Component Overview</a></span></dt></dl></dd><dt><span class="sect1"><a href="#DesignRequirements">2. Design Requirements and Philosophy</a></span></dt><dd><dl><dt><span class="sect2"><a href="#security">2.1. Security Requirements</a></span></dt><dt><span class="sect2"><a href="#privacy">2.2. Privacy Requirements</a></span></dt><dt><span class="sect2"><a href="#philosophy">2.3. Philosophy</a></span></dt></dl></dd><dt><span class="sect1"><a href="#adversary">3. Adversary Model</a></span></dt><dd><dl><dt><span class="sect2"><a href="#adversary-goals">3.1. Adversary Goals</a></span></dt><dt><span class="sect2"><a href="#adversary-positioning">3.2. Adversary Capabilities - Positioning</a></span></dt><dt><span class="sect2"><a href="#attacks">3.3. Adversary Capabilities - Attacks</a></span></dt></dl></dd><dt><span class="sect1"><a href="#Implementation">4. Implementation</a></span></dt><dd><dl><dt><span class="sect2"><a href="#proxy-obedience">4.1. Proxy Obedience</a></span></dt><dt><span class="sect2"><a href="#state-separation">4.2. State Separation</a></span></dt><dt><span class="sect2"><a href="#disk-avoidance">4.3. Disk Avoidance</a></span></dt><dt><span class="sect2"><a href="#app-data-isolation">4.4. Application Data Isolation</a></span></dt><dt><span class="sect2"><a href="#identifier-linkability">4.5. Cross-Origin Identifier Unlinkability</a></span></dt><dt><span class="sect2"><a href="#fingerprinting-linkability">4.6. Cross-Origin Fingerprinting Unlinkability</a></span></dt><dt><span class="sect2"><a href="#new-identity">4.7. Long-Term Unlinkability via "New Identity" button</a></span></dt><dt><span class="sect2"><a href="#other-security">4.8. Other Security Measures</a></span></dt></dl></dd><dt><span class="sect1"><a href="#BuildSecurity">5. Build Security and Package Integrity</a></span></dt><dd><dl><dt><span class="sect2"><a href="#idm1010">5.1. Achieving Binary Reproducibility</a></span></dt><dt><span class="sect2"><a href="#idm1042">5.2. Package Signatures and Verification</a></span></dt><dt><span class="sect2"><a href="#idm1049">5.3. Anonymous Verification</a></span></dt><dt><span class="sect2"><a href="#update-safety">5.4. Update Safety</a></span></dt></dl></dd><dt><span class="appendix"><a href="#Transparency">A. Towards Transparency in Navigation Tracking</a></span></dt><dd><dl><dt><span class="sect1"><a href="#deprecate">A.1. Deprecation Wishlist</a></span></dt><dt><span class="sect1"><a href="#idm1090">A.2. Promising Standards</a></span></dt></dl></dd></dl></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="idm29"></a>1. Introduction</h2></div></div></div><p>
2
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>The Design and Implementation of the Tor Browser [DRAFT]</title><meta name="generator" content="DocBook XSL Stylesheets V1.79.1" /></head><body><div class="article"><div class="titlepage"><div><div><h2 class="title"><a id="design"></a>The Design and Implementation of the Tor Browser [DRAFT]</h2></div><div><div class="author"><h3 class="author"><span class="firstname">Mike</span> <span class="surname">Perry</span></h3><div class="affiliation"><div class="address"><p><code class="email">&lt;<a class="email" href="mailto:mikeperry#torproject org">mikeperry#torproject org</a>&gt;</code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Erinn</span> <span class="surname">Clark</span></h3><div class="affiliation"><div class="address"><p><code class="email">&lt;<a class="email" href="mailto:erinn#torproject org">erinn#torproject org</a>&gt;</code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Steven</span> <span class="surname">Murdoch</span></h3><div class="affiliation"><div class="address"><p><code class="email">&lt;<a class="email" href="mailto:sjmurdoch#torproject org">sjmurdoch#torproject org</a>&gt;</code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Georg</span> <span class="surname">Koppen</span></h3><div class="affiliation"><div class="address"><p><code class="email">&lt;<a class="email" href="mailto:gk#torproject org">gk#torproject org</a>&gt;</code></p></div></div></div></div><div><p class="pubdate">January 24th, 2017</p></div></div><hr /></div><div class="toc"><p><strong>Table of Contents</strong></p><dl class="toc"><dt><span class="sect1"><a href="#idm29">1. Introduction</a></span></dt><dd><dl><dt><span class="sect2"><a href="#components">1.1. Browser Component Overview</a></span></dt></dl></dd><dt><span class="sect1"><a href="#DesignRequirements">2. Design Requirements and Philosophy</a></span></dt><dd><dl><dt><span class="sect2"><a href="#security">2.1. Security Requirements</a></span></dt><dt><span class="sect2"><a href="#privacy">2.2. Privacy Requirements</a></span></dt><dt><span class="sect2"><a href="#philosophy">2.3. Philosophy</a></span></dt></dl></dd><dt><span class="sect1"><a href="#adversary">3. Adversary Model</a></span></dt><dd><dl><dt><span class="sect2"><a href="#adversary-goals">3.1. Adversary Goals</a></span></dt><dt><span class="sect2"><a href="#adversary-positioning">3.2. Adversary Capabilities - Positioning</a></span></dt><dt><span class="sect2"><a href="#attacks">3.3. Adversary Capabilities - Attacks</a></span></dt></dl></dd><dt><span class="sect1"><a href="#Implementation">4. Implementation</a></span></dt><dd><dl><dt><span class="sect2"><a href="#proxy-obedience">4.1. Proxy Obedience</a></span></dt><dt><span class="sect2"><a href="#state-separation">4.2. State Separation</a></span></dt><dt><span class="sect2"><a href="#disk-avoidance">4.3. Disk Avoidance</a></span></dt><dt><span class="sect2"><a href="#app-data-isolation">4.4. Application Data Isolation</a></span></dt><dt><span class="sect2"><a href="#identifier-linkability">4.5. Cross-Origin Identifier Unlinkability</a></span></dt><dt><span class="sect2"><a href="#fingerprinting-linkability">4.6. Cross-Origin Fingerprinting Unlinkability</a></span></dt><dt><span class="sect2"><a href="#new-identity">4.7. Long-Term Unlinkability via "New Identity" button</a></span></dt><dt><span class="sect2"><a href="#other-security">4.8. Other Security Measures</a></span></dt></dl></dd><dt><span class="sect1"><a href="#BuildSecurity">5. Build Security and Package Integrity</a></span></dt><dd><dl><dt><span class="sect2"><a href="#idm1107">5.1. Achieving Binary Reproducibility</a></span></dt><dt><span class="sect2"><a href="#idm1139">5.2. Package Signatures and Verification</a></span></dt><dt><span class="sect2"><a href="#idm1146">5.3. Anonymous Verification</a></span></dt><dt><span class="sect2"><a href="#update-safety">5.4. Update Safety</a></span></dt></dl></dd><dt><span class="appendix"><a href="#Transparency">A. Towards Transparency in Navigation Tracking</a></span></dt><dd><dl><dt><span class="sect1"><a href="#deprecate">A.1. Deprecation Wishlist</a></span></dt><dt><span class="sect1"><a href="#idm1189">A.2. Promising Standards</a></span></dt></dl></dd></dl></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="idm29"></a>1. Introduction</h2></div></div></div><p>
3 3
 
4 4
 This document describes the <a class="link" href="#adversary" title="3. Adversary Model">adversary model</a>,
5 5
 <a class="link" href="#DesignRequirements" title="2. Design Requirements and Philosophy">design requirements</a>, and <a class="link" href="#Implementation" title="4. Implementation">implementation</a>  of the Tor Browser. It is current as of Tor Browser
6
-6.5.1.
6
+7.0.11.
7 7
 
8 8
   </p><p>
9 9
 
... ...
@@ -25,7 +25,7 @@ Support Release (ESR) Firefox branch</a>. We have a <a class="ulink" href="https
25 25
 against this browser to enhance privacy and security. Browser behavior is
26 26
 additionally augmented through the <a class="ulink" href="https://gitweb.torproject.org/torbutton.git/tree/" target="_top">Torbutton
27 27
 extension</a>, though we are in the process of moving this functionality
28
-into direct Firefox patches. We also <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/tree/browser/app/profile/000-tor-browser.js?h=tor-browser-45.8.0esr-6.5-2" target="_top">change
28
+into direct Firefox patches. We also <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/tree/browser/app/profile/000-tor-browser.js?h=tor-browser-52.5.2esr-7.0-2" target="_top">change
29 29
 a number of Firefox preferences</a> from their defaults.
30 30
 
31 31
    </p><p>
... ...
@@ -39,7 +39,7 @@ Instantbird, and XULRunner.
39 39
 To help protect against potential Tor Exit Node eavesdroppers, we include
40 40
 <a class="ulink" href="https://www.eff.org/https-everywhere" target="_top">HTTPS-Everywhere</a>. To
41 41
 provide users with optional defense-in-depth against JavaScript and other
42
-potential exploit vectors, we also include <a class="ulink" href="http://noscript.net/" target="_top">NoScript</a>. We also modify <a class="ulink" href="https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/Bundle-Data/linux/Data/Browser/profile.default/preferences/extension-overrides.js" target="_top">several
42
+potential exploit vectors, we also include <a class="ulink" href="https://noscript.net/" target="_top">NoScript</a>. We also modify <a class="ulink" href="https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/Bundle-Data/linux/Data/Browser/profile.default/preferences/extension-overrides.js" target="_top">several
43 43
 extension preferences</a> from their defaults.
44 44
 
45 45
    </p><p>
... ...
@@ -47,7 +47,7 @@ extension preferences</a> from their defaults.
47 47
 To provide censorship circumvention in areas where the public Tor network is
48 48
 blocked either by IP, or by protocol fingerprint, we include several <a class="ulink" href="https://trac.torproject.org/projects/tor/wiki/doc/AChildsGardenOfPluggableTransports" target="_top">Pluggable
49 49
 Transports</a> in the distribution. As of this writing, we include <a class="ulink" href="https://gitweb.torproject.org/pluggable-transports/obfs4.git" target="_top">Obfs3proxy,
50
-Obfs4proxy, Scramblesuit</a>,
50
+Obfs4proxy</a>,
51 51
 <a class="ulink" href="https://trac.torproject.org/projects/tor/wiki/doc/meek" target="_top">meek</a>,
52 52
 and <a class="ulink" href="https://fteproxy.org/" target="_top">FTE</a>.
53 53
 
... ...
@@ -214,7 +214,7 @@ linkability.
214 214
 <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3100" target="_top">Another
215 215
 failure of Torbutton</a> was the options panel. Each option
216 216
 that detectably alters browser behavior can be used as a fingerprinting tool.
217
-Similarly, all extensions <a class="ulink" href="http://blog.chromium.org/2010/06/extensions-in-incognito.html" target="_top">should be
217
+Similarly, all extensions <a class="ulink" href="https://blog.chromium.org/2010/06/extensions-in-incognito.html" target="_top">should be
218 218
 disabled in the mode</a> except as an opt-in basis. We should not load
219 219
 system-wide and/or operating system provided addons or plugins.
220 220
 
... ...
@@ -233,17 +233,17 @@ permissions can be written to disk. Otherwise, they should remain memory-only.
233 233
      </p></li><li class="listitem"><span class="command"><strong>No filters</strong></span><p>
234 234
 
235 235
 Site-specific or filter-based addons such as <a class="ulink" href="https://addons.mozilla.org/en-US/firefox/addon/adblock-plus/" target="_top">AdBlock
236
-Plus</a>, <a class="ulink" href="http://requestpolicy.com/" target="_top">Request Policy</a>,
237
-<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
236
+Plus</a>, <a class="ulink" href="https://requestpolicy.com/" target="_top">Request Policy</a>,
237
+<a class="ulink" href="https://www.ghostery.com/about-ghostery/" target="_top">Ghostery</a>, <a class="ulink" href="http://priv3.icsi.berkeley.edu/" target="_top">Priv3</a>, and <a class="ulink" href="https://sharemenot.cs.washington.edu/" target="_top">Sharemenot</a> are to be
238 238
 avoided. We believe that these addons do not add any real privacy to a proper
239 239
 <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
240
-should be focused on general solutions that prevent tracking by all
241
-third parties, rather than a list of specific URLs or hosts.
240
+should be focused on general solutions that prevent tracking by all third
241
+parties, rather than a list of specific URLs or hosts.
242 242
      </p><p>
243 243
 Implementing filter-based blocking directly into the browser, such as done with
244
-<a class="ulink" href="http://ieee-security.org/TC/SPW2015/W2SP/papers/W2SP_2015_submission_32.pdf" target="_top">
244
+<a class="ulink" href="https://ieee-security.org/TC/SPW2015/W2SP/papers/W2SP_2015_submission_32.pdf" target="_top">
245 245
 Firefox' Tracking Protection</a>, does not alleviate the concerns mentioned
246
-in the previous paragraph. There is still just a list concerned with specific
246
+in the previous paragraph. There is still just a list containing specific
247 247
 URLs and hosts which, in this case, are
248 248
 <a class="ulink" href="https://services.disconnect.me/disconnect-plaintext.json" target="_top">
249 249
 assembled</a> by <a class="ulink" href="https://disconnect.me/trackerprotection" target="_top">
... ...
@@ -256,11 +256,14 @@ Even with a precision rate at 99% and a false positive rate at 0.1% trackers
256 256
 would be missed and sites would be wrongly blocked.
257 257
      </p><p>
258 258
 Filter-based solutions in general can also introduce strange breakage and cause
259
-usability nightmares. Coping with those easily leads to just <a class="ulink" href="https://github.com/mozilla-services/shavar-list-exceptions" target="_top">whitelisting
259
+usability nightmares. For instance, there is a trend to observe that websites
260
+start <a class="ulink" href="https://petsymposium.org/2017/papers/issue3/paper25-2017-3-source.pdf" target="_top">
261
+detecting filer extensions and block access to content</a> on them. Coping
262
+with this fallout easily leads to just <a class="ulink" href="https://github.com/mozilla-services/shavar-list-exceptions" target="_top">whitelisting
260 263
 </a>
261
-the affected domains defeating the purpose of the filter in the first place.
262
-Filters will also fail to do their job if an adversary simply
263
-registers a new domain or <a class="ulink" href="http://ieee-security.org/TC/SPW2015/W2SP/papers/W2SP_2015_submission_24.pdf" target="_top">
264
+the affected domains, hoping that this helps, defeating the purpose of the
265
+filter in the first place. Filters will also fail to do their job if an
266
+adversary simply registers a new domain or <a class="ulink" href="https://ieee-security.org/TC/SPW2015/W2SP/papers/W2SP_2015_submission_24.pdf" target="_top">
264 267
 creates a new URL path</a>. Worse still, the unique filter sets that each
265 268
 user creates or installs will provide a wealth of fingerprinting targets.
266 269
       </p><p>
... ...
@@ -436,7 +439,7 @@ about the user agent.
436 439
 Also, JavaScript can be used to query the user's timezone via the
437 440
 <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
438 441
 reveal information about the video card in use, and high precision timing
439
-information can be used to <a class="ulink" href="http://w2spconf.com/2011/papers/jspriv.pdf" target="_top">fingerprint the CPU and
442
+information can be used to <a class="ulink" href="https://cseweb.ucsd.edu/~hovav/dist/jspriv.pdf" target="_top">fingerprint the cpu and
440 443
 interpreter speed</a>. JavaScript features such as
441 444
 <a class="ulink" href="https://www.w3.org/TR/resource-timing/" target="_top">Resource Timing</a>
442 445
 may leak an unknown amount of network timing related information. And, moreover,
... ...
@@ -455,7 +458,7 @@ fingerprintability. Additionally, plugins are capable of extracting font lists,
455 458
 interface addresses, and other machine information that is beyond what the
456 459
 browser would normally provide to content. In addition, plugins can be used to
457 460
 store unique identifiers that are more difficult to clear than standard
458
-cookies.  <a class="ulink" href="http://epic.org/privacy/cookies/flash.html" target="_top">Flash-based
461
+cookies.  <a class="ulink" href="https://epic.org/privacy/cookies/flash.html" target="_top">Flash-based
459 462
 cookies</a> fall into this category, but there are likely numerous other
460 463
 examples. Beyond fingerprinting, plugins are also abysmal at obeying the proxy
461 464
 settings of the browser.
... ...
@@ -475,7 +478,7 @@ encrypted traffic patterns of specific websites. In the case of Tor, this
475 478
 attack would take place between the user and the Guard node, or at the Guard
476 479
 node itself.
477 480
      </p><p> The most comprehensive study of the statistical properties of this
478
-attack against Tor was done by <a class="ulink" href="http://lorre.uni.lu/~andriy/papers/acmccs-wpes11-fingerprinting.pdf" target="_top">Panchenko
481
+attack against Tor was done by <a class="ulink" href="https://lorre.uni.lu/~andriy/papers/acmccs-wpes11-fingerprinting.pdf" target="_top">Panchenko
479 482
 et al</a>. Unfortunately, the publication bias in academia has encouraged
480 483
 the production of
481 484
 <a class="ulink" href="https://blog.torproject.org/blog/critique-website-traffic-fingerprinting-attacks" target="_top">a
... ...
@@ -494,7 +497,7 @@ In general, with machine learning, as you increase the <a class="ulink" href="ht
494 497
 categories to classify</a> while maintaining a limit on reliable feature
495 498
 information you can extract, you eventually run out of descriptive feature
496 499
 information, and either true positive accuracy goes down or the false positive
497
-rate goes up. This error is called the <a class="ulink" href="http://www.cs.washington.edu/education/courses/csep573/98sp/lectures/lecture8/sld050.htm" target="_top">bias
500
+rate goes up. This error is called the <a class="ulink" href="https://www.cs.washington.edu/education/courses/csep573/98sp/lectures/lecture8/sld050.htm" target="_top">bias
498 501
 in your hypothesis space</a>. In fact, even for unbiased hypothesis
499 502
 spaces, the number of training examples required to achieve a reasonable error
500 503
 bound is <a class="ulink" href="https://en.wikipedia.org/wiki/Probably_approximately_correct_learning#Equivalence" target="_top">a
... ...
@@ -507,7 +510,7 @@ In the case of this attack, the key factors that increase the classification
507 510
 complexity (and thus hinder a real world adversary who attempts this attack)
508 511
 are large numbers of dynamically generated pages, partially cached content,
509 512
 and also the non-web activity of the entire Tor network. This yields an
510
-effective number of "web pages" many orders of magnitude larger than even <a class="ulink" href="http://lorre.uni.lu/~andriy/papers/acmccs-wpes11-fingerprinting.pdf" target="_top">Panchenko's
513
+effective number of "web pages" many orders of magnitude larger than even <a class="ulink" href="https://lorre.uni.lu/~andriy/papers/acmccs-wpes11-fingerprinting.pdf" target="_top">Panchenko's
511 514
 "Open World" scenario</a>, which suffered continuous near-constant decline
512 515
 in the true positive rate as the "Open World" size grew (see figure 4). This
513 516
 large level of classification complexity is further confounded by a noisy and
... ...
@@ -579,7 +582,7 @@ are typically linked for these cases.
579 582
 Proxy obedience is assured through the following:
580 583
    </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><span class="command"><strong>Firefox proxy settings, patches, and build flags</strong></span><p>
581 584
 
582
-Our <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/tree/browser/app/profile/000-tor-browser.js?h=tor-browser-45.8.0esr-6.5-2" target="_top">Firefox
585
+Our <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/tree/browser/app/profile/000-tor-browser.js?h=tor-browser-52.5.2esr-7.0-2" target="_top">Firefox
583 586
 preferences file</a> sets the Firefox proxy settings to use Tor directly
584 587
 as a SOCKS proxy. It sets <span class="command"><strong>network.proxy.socks_remote_dns</strong></span>,
585 588
 <span class="command"><strong>network.proxy.socks_version</strong></span>,
... ...
@@ -595,11 +598,11 @@ as set the pref <span class="command"><strong>media.peerconnection.enabled</stro
595 598
  </p><p>
596 599
 
597 600
 We also patch Firefox in order to provide several defense-in-depth mechanisms
598
-for proxy safety. Notably, we <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0esr-6.5-2&amp;id=177e78923b3252a7442160486ec48252a6adb77a" target="_top">patch
601
+for proxy safety. Notably, we <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&amp;id=35ce9974e034c0374fb3c8e00e9eb0231c4f3378" target="_top">patch
599 602
 the DNS service</a> to prevent any browser or addon DNS resolution, and we
600
-also <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0esr-6.5-2&amp;id=6e17cef8f3cf61fdabf99e40d5e09a730142d6cd" target="_top">
603
+also <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&amp;id=ee28d8f27fdb1e47481987535c7da70095042ee2" target="_top">
601 604
 remove the DNS lookup for the profile lock signature</a>. Furhermore, we
602
-<a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0esr-6.5-2&amp;id=8197f6ffe58ba167e3bca4230c5721ebcfae55de" target="_top">patch
605
+<a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&amp;id=ffba8d1b84431b4024d5012b326cbcb986047f27" target="_top">patch
603 606
 OCSP and PKIX code</a> to prevent any use of the non-proxied command-line
604 607
 tool utility functions from being functional while linked in to the browser.
605 608
 In both cases, we could find no direct paths to these routines in the browser,
... ...
@@ -607,7 +610,7 @@ but it seemed better safe than sorry.
607 610
 
608 611
  </p><p>
609 612
 
610
-For further defense-in-depth we disabled WebIDE because it can bypass proxy
613
+For further defense-in-depth we disable WebIDE because it can bypass proxy
611 614
 settings for remote debugging, and also because it downloads extensions we
612 615
 have not reviewed. We
613 616
 are doing this by setting
... ...
@@ -616,26 +619,21 @@ are doing this by setting
616 619
 <span class="command"><strong>devtools.webide.enabled</strong></span>, and
617 620
 <span class="command"><strong>devtools.appmanager.enabled</strong></span> to <span class="command"><strong>false</strong></span>.
618 621
 Moreover, we removed the Roku Screen Sharing and screencaster code with a
619
-<a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0esr-6.5-2&amp;id= ad4abdb2e724fec060063f460604b829c66ea08a" target="_top">
622
+<a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&amp;id=055bdffbef68bc8d5e8005b3c7dd2f5d99da1163" target="_top">
620 623
 Firefox patch</a> as these features can bypass proxy settings as well.
621 624
  </p><p>
622
-Shumway is removed, too, for possible proxy bypass risks. We did this by
623
-backporting a <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0esr-6.5-2&amp;id=d020a4992d8d25baf7dfb5c8b308d80b47a8d312" target="_top">
624
-number</a> <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0esr-6.5-2&amp;id=98bf6c81b22cb5e4651a5fc060182f27b26c8ee5" target="_top">
625
-of</a> <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0esr-6.5-2&amp;id=14b723f28a6b1dd78093691013d1bf7d49dc4413" target="_top">Mozilla patches</a>.
626
-Further down on our road to proxy safety we <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0esr-6.5-2&amp;id=a9e1d8eac28abb364bbfd3adabeae287751a6a8e" target="_top">
627
-disabled the network tickler</a> as it has the capability to send UDP
628
-traffic.
629
- </p><p>
630
-
631
-Finally, we <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0esr-6.5-2&amp;id=8e52265653ab223dc5af679f9f0c073b44371fa4" target="_top">
632
-disabled mDNS support</a>, since mDNS uses UDP packets. We also disable
625
+Further down on our road to proxy safety we <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&amp;id=7222d02638689a64d7297b8e5c202f9c37547523" target="_top">
626
+disable the network tickler</a> as it has the capability to send UDP
627
+traffic and we <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&amp;id=5bc957b4f635a659f9aecaa374972ecca7f770a8" target="_top">
628
+disable mDNS support</a>, since mDNS uses UDP packets as well. We also disable
633 629
 Mozilla's TCPSocket by setting
634 630
 <span class="command"><strong>dom.mozTCPSocket.enabled</strong></span> to <span class="command"><strong>false</strong></span>. We
635 631
 <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/18866" target="_top">intend to
636 632
 rip out</a> the TCPSocket code in the future to have an even more solid
637 633
 guarantee that it won't be used by accident.
638
-
634
+ </p><p>
635
+Finally, we <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&amp;id=55bd129f081bd37ae9e72ae32434fbb56ff4e446" target="_top">
636
+remove</a> potentially unsafe Rust code.
639 637
  </p><p>
640 638
 During every Extended Support Release transition, we perform <a class="ulink" href="https://gitweb.torproject.org/tor-browser-spec.git/tree/audits" target="_top">in-depth
641 639
 code audits</a> to verify that there were no system calls or XPCOM
... ...
@@ -651,7 +649,7 @@ protocol helpers, such as SMB URLs and other custom protocol handlers are all
651 649
 blocked.
652 650
  </p></li><li class="listitem"><span class="command"><strong>Disabling plugins</strong></span><p>
653 651
 Plugins, like Flash, have the ability to make arbitrary OS system calls and
654
-<a class="ulink" href="http://decloak.net/" target="_top">bypass proxy settings</a>. This includes
652
+<a class="ulink" href="https://ip-check.info/" target="_top">bypass proxy settings</a>. This includes
655 653
 the ability to make UDP sockets and send arbitrary data independent of the
656 654
 browser proxy settings.
657 655
  </p><p>
... ...
@@ -667,9 +665,9 @@ restricted from automatic load through Firefox's click-to-play preference
667 665
 
668 666
 In addition, to reduce any unproxied activity by arbitrary plugins at load
669 667
 time, and to reduce the fingerprintability of the installed plugin list, we
670
-also patch the Firefox source code to <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0esr-6.5-2&amp;id=09883246904ce4dede9f3c4d4bb8d644aefe9d1d" target="_top">
668
+also patch the Firefox source code to <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&amp;id=95a0100fd8ac0fdbe9f517e9b7ea86d6b77ec2c9" target="_top">
671 669
 prevent the load of any plugins except for Flash and Gnash</a>. Even for
672
-Flash and Gnash, we also patch Firefox to <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0esr-6.5-2&amp;id=9a0d506e3655f2fdec97ee4217f354941e39b5b3" target="_top">
670
+Flash and Gnash, we also patch Firefox to <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&amp;id=39f5a767c0c082b1e4a001cf685a6efb31bd62c6" target="_top">
673 671
 prevent loading them into the address space</a> until they are explicitly
674 672
 enabled.
675 673
  </p><p>
... ...
@@ -681,23 +679,39 @@ can't be built reproducibly or are binary blobs which we are not allowed to
681 679
 audit (or both). For the EME case we use the <span class="command"><strong>--disable-eme</strong></span>
682 680
 configure switch and set
683 681
 <span class="command"><strong>browser.eme.ui.enabled</strong></span>,
682
+<span class="command"><strong>media.gmp-eme-adobe.visible</strong></span>,
684 683
 <span class="command"><strong>media.gmp-eme-adobe.enabled</strong></span>,
684
+<span class="command"><strong>media.gmp-widevinecdm.visible</strong></span>,
685
+<span class="command"><strong>media.gmp-widevinecdm.enabled</strong></span>,
685 686
 <span class="command"><strong>media.eme.enabled</strong></span>, and
686 687
 <span class="command"><strong>media.eme.apiVisible</strong></span> to <span class="command"><strong>false</strong></span> to indicate
687 688
 to the user that this feature is disabled. For GMPs in general we make sure that
688 689
 the external server is not even pinged for updates/downloads in the first place
689 690
 by setting <span class="command"><strong>media.gmp-manager.url.override</strong></span> to
690 691
 <span class="command"><strong>data:text/plain,</strong></span> and avoid any UI with <span class="command"><strong>
691
-media.gmp-provider.enabled</strong></span> set to <span class="command"><strong>false</strong></span>.
692
+  media.gmp-provider.enabled</strong></span> set to <span class="command"><strong>false</strong></span>. Moreover,
693
+we disable GMP downloads via local fallback by setting
694
+<span class="command"><strong>media.gmp-manager.updateEnabled</strong></span> to <span class="command"><strong>false</strong></span>.
695
+To reduce our attack surface we exclude the ClearKey EME system, too.
692 696
 
693 697
  </p></li><li class="listitem"><span class="command"><strong>External App Blocking and Drag Event Filtering</strong></span><p>
694 698
 
695 699
 External apps can be induced to load files that perform network activity.
696 700
 Unfortunately, there are cases where such apps can be launched automatically
697
-with little to no user input. In order to prevent this, Torbutton installs a
698
-component to <a class="ulink" href="https://gitweb.torproject.org/torbutton.git/tree/src/components/external-app-blocker.js" target="_top">
701
+with little to no user input. In order to prevent this, we ship <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&amp;id=d179d8a4861199e203934ecc36dd6d8ade549dfa" target="_top">
702
+Firefox</a> <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&amp;id=99173c3a5f83d9ac44091a72c5570efd296dff8f" target="_top">patches</a> and Torbutton installs a component to <a class="ulink" href="https://gitweb.torproject.org/torbutton.git/tree/src/components/external-app-blocker.js" target="_top">
699 703
 provide the user with a popup</a> whenever the browser attempts to launch
700
-a helper app.
704
+a helper application.
705
+
706
+  </p><p>
707
+
708
+Furthermore, we ship a <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&amp;id=d75b79f6fa920e6a1e3043005dfd50060ea70e57" target="_top">patch for Linux users</a> that makes
709
+sure sftp:// and smb:// URLs are not passed along to the operating system as this
710
+can lead to proxy bypasses on systems that have GIO/GnomeVS support. And proxy
711
+bypass risks due to file:// URLs should be mitigated for macOS and Linux users
712
+by <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&amp;id=8db44df10d1d82850e8b4cfe81ac3b5fce32a663" target="_top">
713
+two</a> <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&amp;id=a8e1fcc8678aa1583f73ef231c99f77cf17196d9" target="_top">
714
+further patches</a>.
701 715
 
702 716
   </p><p>
703 717
 
... ...
@@ -719,7 +733,14 @@ system-level addons from the browser through the use of
719 733
 <span class="command"><strong>extensions.autoDisableScopes</strong></span>. Furthermore, we set
720 734
 <span class="command"><strong>extensions.systemAddon.update.url</strong></span> and <span class="command"><strong>
721 735
 extensions.hotfix.id</strong></span> to an empty string in order
722
-to avoid the risk of getting extensions installed by Mozilla into Tor Browser.
736
+to avoid the risk of getting extensions installed by Mozilla into Tor Browser,
737
+and remove unused system extensions with a
738
+<a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&amp;id=4d90fcf15e328ca369751011ad0a9c0c1ba2f153" target="_top">
739
+Firefox patch</a>.
740
+In order to make it harder for users to accidentally install extensions which
741
+Mozilla presents to them on the <span class="emphasis"><em>about:addons</em></span> page, we hide
742
+the <span class="emphasis"><em>Get Addons</em></span> option on it by setting
743
+<span class="command"><strong>extensions.getAddons.showPane</strong></span> to <span class="command"><strong>false</strong></span>.
723 744
 
724 745
   </p></li></ol></div></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="state-separation"></a>4.2. State Separation</h3></div></div></div><p>
725 746
 
... ...
@@ -732,41 +753,37 @@ system-wide extensions (through the use of
732 753
 disabled, which prevents Flash cookies from leaking from a pre-existing Flash
733 754
 directory.
734 755
 
735
-   </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="disk-avoidance"></a>4.3. Disk Avoidance</h3></div></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idm357"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote">
756
+   </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="disk-avoidance"></a>4.3. Disk Avoidance</h3></div></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idm372"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote">
736 757
 
737 758
 The User Agent MUST (at user option) prevent all disk records of browser activity.
738 759
 The user SHOULD be able to optionally enable URL history and other history
739 760
 features if they so desire.
740 761
 
741
-    </blockquote></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idm360"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote">
742
-
762
+    </blockquote></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idm375"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote">
743 763
      We are working towards this goal through several mechanisms. First, we set
744 764
      the Firefox Private Browsing preference
745
-     <span class="command"><strong>browser.privatebrowsing.autostart</strong></span>.
765
+     <span class="command"><strong>browser.privatebrowsing.autostart</strong></span> to <span class="command"><strong>true</strong></span>.
746 766
      We also had to disable the media cache with the pref <span class="command"><strong>media.cache_size</strong></span>, to prevent HTML5 videos from being written to the OS temporary directory, which happened regardless of the private browsing mode setting.
747
-     Finally, we needed to disable asm.js as it turns out that
748
-     <a class="ulink" href="https://bugzilla.mozilla.org/show_bug.cgi?id=1047105" target="_top">asm.js
749
-     cache entries get written to disk</a> in private browsing mode. This
750
-     is done by setting <span class="command"><strong>javascript.options.asmjs</strong></span> to
751
-     <span class="command"><strong>false</strong></span> (for linkability concerns with asm.js see below).
752
-    </blockquote></div><div class="blockquote"><blockquote class="blockquote">
753
-
754
-As an additional defense-in-depth measure, we set the following preferences:
755
-<span class="command"><strong></strong></span>,
767
+     Finally, we set <span class="command"><strong>security.nocertdb</strong></span> to <span class="command"><strong>true</strong></span>
768
+     to make the intermediate certificate store memory-only.
769
+   </blockquote></div><div class="blockquote"><blockquote class="blockquote">
770
+     Moreover, we prevent text leaking from the web console to the /tmp
771
+     directory with a direct <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&amp;id=48b68533d113c5998d19d4e5acfb8967ba2d5f5b" target="_top">Firefox patch</a>.
772
+   </blockquote></div><div class="blockquote"><blockquote class="blockquote">
773
+
774
+As an additional defense-in-depth measure, we set
756 775
 <span class="command"><strong>browser.cache.disk.enable</strong></span>,
757 776
 <span class="command"><strong>browser.cache.offline.enable</strong></span>,
758
-<span class="command"><strong>dom.indexedDB.enabled</strong></span>,
759
-<span class="command"><strong>network.cookie.lifetimePolicy</strong></span>,
760 777
 <span class="command"><strong>signon.rememberSignons</strong></span>,
761
-<span class="command"><strong>browser.formfill.enable</strong></span>,
762
-<span class="command"><strong>browser.download.manager.retention</strong></span>,
763
-<span class="command"><strong>browser.sessionstore.privacy_level</strong></span>,
764
-and <span class="command"><strong>network.cookie.lifetimePolicy</strong></span>. Many of these
765
-preferences are likely redundant with
766
-<span class="command"><strong>browser.privatebrowsing.autostart</strong></span>, but we have not done the
767
-auditing work to ensure that yet.
778
+<span class="command"><strong>browser.formfill.enable</strong></span> to <span class="command"><strong>true</strong></span>,
779
+<span class="command"><strong>browser.download.manager.retention</strong></span> to <span class="command"><strong>1</strong></span>,
780
+and both <span class="command"><strong>browser.sessionstore.privacy_level</strong></span> and
781
+<span class="command"><strong>network.cookie.lifetimePolicy</strong></span> to <span class="command"><strong>2</strong></span>.  Many
782
+of these preferences are likely redundant with
783
+<span class="command"><strong>browser.privatebrowsing.autostart</strong></span> enabled, but we have not
784
+done the auditing work to ensure that yet.
768 785
 
769
-    </blockquote></div><div class="blockquote"><blockquote class="blockquote">
786
+   </blockquote></div><div class="blockquote"><blockquote class="blockquote">
770 787
 
771 788
 For more details on disk leak bugs and enhancements, see the <a class="ulink" href="https://trac.torproject.org/projects/tor/query?keywords=~tbb-disk-leak&amp;status=!closed" target="_top">tbb-disk-leak tag in our bugtracker</a></blockquote></div></div></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="app-data-isolation"></a>4.4. Application Data Isolation</h3></div></div></div><p>
772 789
 
... ...
@@ -803,7 +820,7 @@ the URL bar origin for which browser state exists, possibly with a
803 820
 context-menu option to drill down into specific types of state or permissions.
804 821
 An example of this simplification can be seen in Figure 1.
805 822
 
806
-   </p><div class="figure"><a id="idm393"></a><p class="title"><strong>Figure 1. Improving the Privacy UI</strong></p><div class="figure-contents"><div class="mediaobject" align="center"><img src="NewCookieManager.png" align="middle" alt="Improving the Privacy UI" /></div><div class="caption"><p></p>
823
+   </p><div class="figure"><a id="idm410"></a><p class="title"><strong>Figure 1. Improving the Privacy UI</strong></p><div class="figure-contents"><div class="mediaobject" align="center"><img src="NewCookieManager.png" align="middle" alt="Improving the Privacy UI" /></div><div class="caption"><p></p>
807 824
 
808 825
 This example UI is a mock-up of how isolating identifiers to the URL bar
809 826
 domain can simplify the privacy UI for all data - not just cookies. Once
... ...
@@ -811,95 +828,85 @@ browser identifiers and site permissions operate on a URL bar basis, the same
811 828
 privacy window can represent browsing history, DOM Storage, HTTP Auth, search
812 829
 form history, login values, and so on within a context menu for each site.
813 830
 
814
-</div></div></div><br class="figure-break" /><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idm400"></a>Identifier Unlinkability Defenses in the Tor Browser</h4></div></div></div><p>
831
+</div></div></div><br class="figure-break" /><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idm417"></a>Identifier Unlinkability Defenses in the Tor Browser</h4></div></div></div><p>
815 832
 
816 833
 Unfortunately, many aspects of browser state can serve as identifier storage,
817
-and no other browser vendor or standards body has invested the effort to
834
+and no other browser vendor or standards body had invested the effort to
818 835
 enumerate or otherwise deal with these vectors for third party tracking. As
819 836
 such, we have had to enumerate and isolate these identifier sources on a
820
-piecemeal basis. Here is the list that we have discovered and dealt with to
821
-date:
837
+piecemeal basis. This has gotten better lately with Mozilla stepping up and
838
+helping us with uplifting our patches, and with contributing own ones where we
839
+lacked proper fixes. However, we are not done yet with our unlinkability defense
840
+as new identifier sources are still getting added to the web platform. Here is
841
+the list that we have discovered and dealt with to date:
822 842
 
823 843
    </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><span class="command"><strong>Cookies</strong></span><p><span class="command"><strong>Design Goal:</strong></span>
824 844
 
825 845
 All cookies MUST be double-keyed to the URL bar origin and third-party
826
-origin. There exists a <a class="ulink" href="https://bugzilla.mozilla.org/show_bug.cgi?id=565965" target="_top">Mozilla bug</a>
827
-that contains a prototype patch, but it lacks UI, and does not apply to modern
828
-Firefox versions.
846
+origin.
829 847
 
830 848
      </p><p><span class="command"><strong>Implementation Status:</strong></span>
831 849
 
832
-As a stopgap to satisfy our design requirement of unlinkability, we currently
833
-entirely disable 3rd party cookies by setting
834
-<span class="command"><strong>network.cookie.cookieBehavior</strong></span> to <span class="command"><strong>1</strong></span>. We
835
-would prefer that third party content continue to function, but we believe the
836
-requirement for unlinkability trumps that desire.
850
+Double-keying cookies should just work by setting <span class="command"><strong>privacy.firstparty.isolate
851
+</strong></span> to <span class="command"><strong>true</strong></span>. However,
852
+<a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/21905" target="_top">we have not
853
+audited that</a> yet and there is still the
854
+<a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/10353" target="_top">UI part
855
+missing for managing cookies in Private Browsing Mode</a>. We therefore
856
+opted to keep third-party cookies disabled for now by setting
857
+<span class="command"><strong>network.cookie.cookieBehavior</strong></span> to <span class="command"><strong>1</strong></span>.
837 858
 
838 859
      </p></li><li class="listitem"><span class="command"><strong>Cache</strong></span><p><span class="command"><strong>Design Goal:</strong></span>
839 860
         All cache entries MUST be isolated to the URL bar domain.
840 861
       </p><p><span class="command"><strong>Implementation Status:</strong></span>
862
+We isolate the content and image cache to the URL bar domain by setting
863
+<span class="command"><strong>privacy.firstparty.isolate</strong></span> to <span class="command"><strong>true</strong></span>.
841 864
 
842
-In Firefox, there are actually several distinct caching mechanisms: One is for
843
-general content (HTML, JavaScript, CSS). That content cache is isolated to the
844
-URL bar domain by <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0esr-6.5-2&amp;id=9e88ab764b1c9c5d26a398ec6381eef88689929c" target="_top">altering
845
-each cache key</a> to include an additional ID that includes the URL bar
846
-domain. This functionality can be observed by navigating to <a class="ulink" href="about:cache" target="_top">about:cache</a> and viewing the key used for each cache
847
-entry. Each third party element should have an additional "string@:"
848
-property prepended, which will list the base domain that was used to source it.
849
-
850
-     </p><p>
851
-
852
-Additionally, there is the image cache. Because it is a separate entity from
853
-the content cache, we had to patch Firefox to also <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0esr-6.5-2&amp;id=05749216781d470ab95c2d101dd28ad000d9161f" target="_top">isolate
854
-this cache per URL bar domain</a>.
855
-
856
-     </p><p>
865
+      </p><p>
857 866
 Furthermore there is the Cache API (CacheStorage). That one is currently not
858 867
 available in Tor Browser as we do not allow third party cookies and are in
859 868
 Private Browsing Mode by default.
860
-     </p><p>
869
+      </p><p>
861 870
 Finally, we have the asm.js cache. The cache entry of the sript is (among
862 871
 others things, like type of CPU, build ID, source characters of the asm.js
863 872
 module etc.) keyed <a class="ulink" href="https://blog.mozilla.org/luke/2014/01/14/asm-js-aot-compilation-and-startup-performance/" target="_top">to the origin of the script</a>.
864
-Lacking a good solution for binding it to the URL bar domain instead (and given
865
-the storage of asm.js modules in Private Browsing Mode) we decided to disable
866
-asm.js for the time being by setting <span class="command"><strong>javascript.options.asmjs</strong></span> to
867
-<span class="command"><strong>false</strong></span>. It remains to be seen whether keying the cache entry
868
-to the source characters of the asm.js module helps to avoid using it for
869
-cross-origin tracking of users. We did not investigate that yet.
870
-     </p></li><li class="listitem"><span class="command"><strong>HTTP Authentication</strong></span><p>
873
+Lacking a good solution for binding it to the URL bar domain instead we decided
874
+to disable asm.js for the time being by setting
875
+<span class="command"><strong>javascript.options.asmjs</strong></span> to <span class="command"><strong>false</strong></span>. It
876
+remains to be seen whether keying the cache entry e.g. to the source characters
877
+of the asm.js module helps to avoid using it for cross-origin tracking of users.
878
+We did not investigate that yet.
879
+      </p></li><li class="listitem"><span class="command"><strong>HTTP Authentication</strong></span><p>
871 880
 
872 881
 HTTP Authorization headers can be used to encode <a class="ulink" href="http://jeremiahgrossman.blogspot.com/2007/04/tracking-users-without-cookies.html" target="_top">silent
873
-third party tracking identifiers</a>. To prevent this, we remove HTTP
874
-authentication tokens for third party elements through a <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0esr-6.5-2&amp;id=5e686c690cbc33cf3fdf984e6f3d3fe7b4d83701" target="_top">patch
875
-to nsHTTPChannel</a>.
882
+third party tracking identifiers</a>. To prevent this, we set
883
+<span class="command"><strong>privacy.firstparty.isolate</strong></span> to <span class="command"><strong>true</strong></span>.
876 884
 
877
-     </p></li><li class="listitem"><span class="command"><strong>DOM Storage</strong></span><p>
885
+      </p></li><li class="listitem"><span class="command"><strong>DOM Storage</strong></span><p>
878 886
 
879 887
 DOM storage for third party domains MUST be isolated to the URL bar domain,
880
-to prevent linkability between sites. This functionality is provided through a
881
-<a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0esr-6.5-2&amp;id=20fee895321a7a18e79547e74f6739786558c0e8" target="_top">patch
882
-to Firefox</a>.
888
+to prevent linkability between sites. We achieve this by setting
889
+<span class="command"><strong>privacy.firstparty.isolate</strong></span> to <span class="command"><strong>true</strong></span>.
883 890
 
884
-     </p></li><li class="listitem"><span class="command"><strong>Flash cookies</strong></span><p><span class="command"><strong>Design Goal:</strong></span>
891
+      </p></li><li class="listitem"><span class="command"><strong>Flash cookies</strong></span><p><span class="command"><strong>Design Goal:</strong></span>
885 892
 
886 893
 Users should be able to click-to-play flash objects from trusted sites. To
887 894
 make this behavior unlinkable, we wish to include a settings file for all
888
-platforms that disables flash cookies using the <a class="ulink" href="http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager03.html" target="_top">Flash
895
+platforms that disables flash cookies using the <a class="ulink" href="https://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager03.html" target="_top">Flash
889 896
 settings manager</a>.
890 897
 
891
-     </p><p><span class="command"><strong>Implementation Status:</strong></span>
898
+      </p><p><span class="command"><strong>Implementation Status:</strong></span>
892 899
 
893 900
 We are currently <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3974" target="_top">having
894 901
 difficulties</a> causing Flash player to use this settings
895 902
 file on Windows, so Flash remains difficult to enable.
896 903
 
897
-     </p></li><li class="listitem"><span class="command"><strong>SSL+TLS session resumption</strong></span><p><span class="command"><strong>Design Goal:</strong></span>
904
+      </p></li><li class="listitem"><span class="command"><strong>SSL+TLS session resumption</strong></span><p><span class="command"><strong>Design Goal:</strong></span>
898 905
 
899 906
 TLS session resumption tickets and SSL Session IDs MUST be limited to the URL
900 907
 bar domain.
901 908
 
902
-     </p><p><span class="command"><strong>Implementation Status:</strong></span>
909
+      </p><p><span class="command"><strong>Implementation Status:</strong></span>
903 910
 
904 911
 We disable TLS Session Tickets and SSL Session IDs by
905 912
 setting <span class="command"><strong>security.ssl.disable_session_identifiers</strong></span> to
... ...
@@ -909,16 +916,18 @@ these performance optimizations, we also enable
909 916
 <a class="ulink" href="https://tools.ietf.org/html/draft-bmoeller-tls-falsestart-00" target="_top">TLS
910 917
 False Start</a> via the Firefox Pref
911 918
 <span class="command"><strong>security.ssl.enable_false_start</strong></span>.
919
+However, URL bar domain isolation should be working both for session tickets and
920
+session IDs but we <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/17252" target="_top">
921
+have not verified that yet</a>.
912 922
 
913
-    </p></li><li class="listitem"><span class="command"><strong>Tor circuit and HTTP connection linkability</strong></span><p>
923
+      </p></li><li class="listitem"><span class="command"><strong>Tor circuit and HTTP connection linkability</strong></span><p><span class="command"><strong>Design Goal:</strong></span>
914 924
 
915 925
 Tor circuits and HTTP connections from a third party in one URL bar origin
916 926
 MUST NOT be reused for that same third party in another URL bar origin.
917 927
 
918
-     </p><p>
928
+      </p><p><span class="command"><strong>Implementation Status:</strong></span>
919 929
 
920
-This isolation functionality is provided by a Torbutton
921
-component that <a class="ulink" href="" target="_top">sets
930
+The isolation functionality is provided by a Torbutton component that <a class="ulink" href="https://gitweb.torproject.org/torbutton.git/tree/src/components/domain-isolator.js" target="_top">sets
922 931
 the SOCKS username and password for each request</a>. The Tor client has
923 932
 logic to prevent connections with different SOCKS usernames and passwords from
924 933
 using the same Tor circuit. Firefox has existing logic to ensure that
... ...
@@ -928,22 +937,24 @@ connections unless the proxy settings match.
928 937
 this logic</a> to cover SOCKS username and password authentication,
929 938
 providing us with HTTP Keep-Alive unlinkability.
930 939
 
931
-     </p></li><li class="listitem"><span class="command"><strong>SharedWorkers</strong></span><p>
940
+      </p><p>
941
+
942
+While the vast majority of web requests adheres to the circuit and connection
943
+unlinkability requirement there are still corner cases we
944
+<a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&amp;id=8661822237c56d543d5c9117c8a4708c402a110f" target="_top">
945
+  need to treat separately</a> or that
946
+<a class="ulink" href="" target="_top">lack a fix altogether</a>.
947
+      </p></li><li class="listitem"><span class="command"><strong>SharedWorkers</strong></span><p>
932 948
 
933 949
 <a class="ulink" href="https://developer.mozilla.org/en-US/docs/Web/API/SharedWorker" target="_top">SharedWorkers</a>
934 950
 are a special form of JavaScript Worker threads that have a shared scope between
935
-all threads from the same Javascript origin.
936
-
937
-     </p><p>
938
-
939
-The SharedWorker scope MUST be isolated to the URL bar domain. I.e. a
940
-SharedWorker launched from a third party from one URL bar domain MUST NOT have
941
-access to the objects created by that same third party loaded under another URL
942
-bar domain. This functionality is provided by a
943
-<a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0esr-6.5-2&amp;id=d17c11445645908086c8d0af84e970e880f586eb" target="_top">
944
-Firefox patch</a>.
951
+all threads from the same Javascript origin. They MUST be isolated to the URL
952
+bar domain. I.e. a SharedWorker launched from a third party from one URL bar
953
+domain MUST NOT have access to the objects created by that same third party
954
+loaded under another URL bar domain. This functionality is provided by setting
955
+<span class="command"><strong>privacy.firstparty.isolate</strong></span> to <span class="command"><strong>true</strong></span>.
945 956
 
946
-     </p></li><li class="listitem"><span class="command"><strong>blob: URIs (URL.createObjectURL)</strong></span><p>
957
+      </p></li><li class="listitem"><span class="command"><strong>blob: URIs (URL.createObjectURL)</strong></span><p>
947 958
 
948 959
 The <a class="ulink" href="https://developer.mozilla.org/en-US/docs/Web/API/URL/createObjectURL" target="_top">URL.createObjectURL</a>
949 960
 API allows a site to load arbitrary content into a random UUID that is stored
... ...
@@ -953,23 +964,20 @@ web. While this UUID value is neither under control of the site nor
953 964
 predictable, it can still be used to tag a set of users that are of high
954 965
 interest to an adversary.
955 966
 
956
-      </p><p><span class="command"><strong>Design Goal:</strong></span>
967
+      </p><p>
957 968
 
958 969
 URIs created with URL.createObjectURL MUST be limited in scope to the first
959
-party URL bar domain that created them.
960
-
961
-     </p><p><span class="command"><strong>Implementation Status:</strong></span>
962
-
963
-We provide the isolation in Tor Browser via a <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0esr-6.5-2&amp;id=7eb0b7b7a9c7257140ae5683718e82f3f0884f4f" target="_top">direct
964
-patch to Firefox</a>. However, downloads of PDF files via the download button in the PDF viewer <a class="ulink" href="https://bugs.torproject.org/17933" target="_top">are not isolated yet</a>.
970
+party URL bar domain that created them. We provide the isolation in Tor
971
+Browser by setting <span class="command"><strong>privacy.firstparty.isolate</strong></span> to
972
+<span class="command"><strong>true</strong></span>.
965 973
 
966
-     </p></li><li class="listitem"><span class="command"><strong>SPDY and HTTP/2</strong></span><p><span class="command"><strong>Design Goal:</strong></span>
974
+      </p></li><li class="listitem"><span class="command"><strong>SPDY and HTTP/2</strong></span><p><span class="command"><strong>Design Goal:</strong></span>
967 975
 
968 976
 SPDY and HTTP/2 connections MUST be isolated to the URL bar domain. Furthermore,
969 977
 all associated means that could be used for cross-domain user tracking (alt-svc
970 978
 headers come to mind) MUST adhere to this design principle as well.
971 979
 
972
-    </p><p><span class="command"><strong>Implementation status:</strong></span>
980
+      </p><p><span class="command"><strong>Implementation status:</strong></span>
973 981
 
974 982
 SPDY and HTTP/2 are currently disabled by setting the
975 983
 Firefox preferences <span class="command"><strong>network.http.spdy.enabled</strong></span>,
... ...
@@ -981,7 +989,7 @@ Firefox preferences <span class="command"><strong>network.http.spdy.enabled</str
981 989
 <span class="command"><strong>network.http.altsvc.enabled</strong></span>, and
982 990
 <span class="command"><strong>network.http.altsvc.oe</strong></span> to <span class="command"><strong>false</strong></span>.
983 991
 
984
-     </p></li><li class="listitem"><span class="command"><strong>Automated cross-origin redirects</strong></span><p><span class="command"><strong>Design Goal:</strong></span>
992
+      </p></li><li class="listitem"><span class="command"><strong>Automated cross-origin redirects</strong></span><p><span class="command"><strong>Design Goal:</strong></span>
985 993
 
986 994
 To prevent attacks aimed at subverting the Cross-Origin Identifier
987 995
 Unlinkability <a class="link" href="#privacy" title="2.2. Privacy Requirements">privacy requirement</a>, the browser
... ...
@@ -991,26 +999,26 @@ For example, if a user clicks on a bit.ly URL that redirects to a
991 999
 doubleclick.net URL that finally redirects to a cnn.com URL, only cookies from
992 1000
 cnn.com should be retained after the redirect chain completes.
993 1001
 
994
-    </p><p>
1002
+      </p><p>
995 1003
 
996 1004
 Non-automated redirect chains that require user input at some step (such as
997 1005
 federated login systems) SHOULD still allow identifiers to persist.
998 1006
 
999
-    </p><p><span class="command"><strong>Implementation status:</strong></span>
1007
+      </p><p><span class="command"><strong>Implementation status:</strong></span>
1000 1008
 
1001 1009
 There are numerous ways for the user to be redirected, and the Firefox API
1002 1010
 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
1003 1011
 open</a> to implement what we can.
1004 1012
 
1005
-    </p></li><li class="listitem"><span class="command"><strong>window.name</strong></span><p>
1013
+      </p></li><li class="listitem"><span class="command"><strong>window.name</strong></span><p>
1006 1014
 
1007 1015
 <a class="ulink" href="https://developer.mozilla.org/En/DOM/Window.name" target="_top">window.name</a> is
1008 1016
 a magical DOM property that for some reason is allowed to retain a persistent value
1009 1017
 for the lifespan of a browser tab. It is possible to utilize this property for
1010
-<a class="ulink" href="http://www.thomasfrank.se/sessionvars.html" target="_top">identifier
1018
+<a class="ulink" href="https://www.thomasfrank.se/sessionvars.html" target="_top">identifier
1011 1019
 storage</a>.
1012 1020
 
1013
-     </p><p>
1021
+      </p><p>
1014 1022
 
1015 1023
 In order to eliminate non-consensual linkability but still allow for sites
1016 1024
 that utilize this property to function, we reset the window.name property of
... ...
@@ -1019,7 +1027,7 @@ allows window.name to persist for the duration of a click-driven navigation
1019 1027
 session, but as soon as the user enters a new URL or navigates between
1020 1028
 HTTPS/HTTP schemes, the property is cleared.
1021 1029
 
1022
-     </p></li><li class="listitem"><span class="command"><strong>Auto form-fill</strong></span><p>
1030
+      </p></li><li class="listitem"><span class="command"><strong>Auto form-fill</strong></span><p>
1023 1031
 
1024 1032
 We disable the password saving functionality in the browser as part of our
1025 1033
 <a class="link" href="#disk-avoidance" title="4.3. Disk Avoidance">Disk Avoidance</a> requirement. However,
... ...
@@ -1029,10 +1037,10 @@ preference to false to prevent saved values from immediately populating
1029 1037
 fields upon page load. Since JavaScript can read these values as soon as they
1030 1038
 appear, setting this preference prevents automatic linkability from stored passwords.
1031 1039
 
1032
-     </p></li><li class="listitem"><span class="command"><strong>HSTS and HPKP supercookies</strong></span><p>
1040
+      </p></li><li class="listitem"><span class="command"><strong>HSTS and HPKP supercookies</strong></span><p>
1033 1041
 
1034
-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</a>
1035
-<a class="ulink" href="http://www.radicalresearch.co.uk/lab/hstssupercookies/" target="_top">
1042
+An extreme (but not impossible) attack to mount is the creation of <a class="ulink" href="https://www.leviathansecurity.com/blog/archives/12-The-Double-Edged-Sword-of-HSTS-Persistence-and-Privacy.html" target="_top">HSTS</a>
1043
+<a class="ulink" href="https://www.radicalresearch.co.uk/lab/hstssupercookies/" target="_top">
1036 1044
 supercookies</a>. Since HSTS effectively stores one bit of information per domain
1037 1045
 name, an adversary in possession of numerous domains can use them to construct
1038 1046
 cookies based on stored HSTS state.
... ...
@@ -1064,9 +1072,8 @@ instead be isolated to the URL bar domain.
1064 1072
 
1065 1073
       </p><p>
1066 1074
 
1067
-We provide the isolation in Tor Browser via a <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0esr-6.5-2&amp;id=3460a38721810b5b7e785e18f202dde20b3434e8" target="_top">direct
1068
-patch to Firefox</a>. If we lack a window for determining the URL bar
1069
-domain (e.g. in some worker contexts) the use of broadcast channels is disabled.
1075
+We provide the isolation in Tor Browser by setting
1076
+<span class="command"><strong>privacy.firstparty.isolate</strong></span> to <span class="command"><strong>true</strong></span>.
1070 1077
 
1071 1078
       </p></li><li class="listitem"><span class="command"><strong>OCSP</strong></span><p>
1072 1079
 
... ...
@@ -1076,24 +1083,28 @@ no cached results are available. Thus, to avoid information leaks, e.g. to exit
1076 1083
 relays, OCSP requests MUST go over the same circuit as the HTTPS request causing
1077 1084
 them and MUST therefore be isolated to the URL bar domain. The resulting cache
1078 1085
 entries MUST be bound to the URL bar domain as well. This functionality is
1079
-provided by a
1080
-<a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0esr-6.5-2&amp;id=7eb1568275acd4fdf61359c9b1e97c2753e7b2be" target="_top">Firefox patch</a>.
1086
+provided by setting <span class="command"><strong>privacy.firstparty.isolate</strong></span> to
1087
+<span class="command"><strong>true</strong></span>.
1081 1088
 
1082
-       </p></li><li class="listitem"><span class="command"><strong>Favicons</strong></span><p>
1089
+       </p></li><li class="listitem"><span class="command"><strong>Favicons</strong></span><p><span class="command"><strong>Design Goal:</strong></span>
1083 1090
 
1084 1091
 When visiting a website its favicon is fetched via a request originating from
1085 1092
 the browser itself (similar to the OCSP mechanism mentioned in the previous
1086
-section). Those requests MUST be isolated to the URL bar domain. This
1087
-functionality is provided by a
1088
-<a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0esr-6.5-2&amp;id=f29f3ff28bbc471ea209d2181770677223c394d1" target="_top">Firefox patch</a>.
1093
+section). Those requests MUST be isolated to the URL bar domain.
1089 1094
 
1095
+      </p><p><span class="command"><strong>Implemetation Status:</strong></span>
1096
+
1097
+Favicon requests are isolated to the URL bar domain by setting
1098
+<span class="command"><strong>privacy.firstparty.isolate</strong></span> to <span class="command"><strong>true</strong></span>.
1099
+However, we need an additional
1100
+<a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&amp;id=eaa22334adaf8f79544ee4318982e5f4990c1a6f" target="_top">Firefox patch</a>
1101
+to take care of favicons in tab list menuitems.
1090 1102
       </p></li><li class="listitem"><span class="command"><strong>mediasource: URIs and MediaStreams</strong></span><p>
1091 1103
 
1092 1104
 Much like blob URLs, mediasource: URIs and MediaStreams can be used to tag
1093 1105
 users. Therefore, mediasource: URIs and MediaStreams MUST be isolated to the URL bar domain.
1094
-This functionality is part of a
1095
-<a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0esr-6.5-2&amp;id=7eb0b7b7a9c7257140ae5683718e82f3f0884f4f" target="_top">Firefox patch</a>
1096
-
1106
+This functionality is provided by setting <span class="command"><strong>privacy.firstparty.isolate</strong></span>
1107
+to <span class="command"><strong>true</strong></span>.
1097 1108
       </p></li><li class="listitem"><span class="command"><strong>Speculative and prefetched connections</strong></span><p>
1098 1109
 
1099 1110
 Firefox provides the feature to <a class="ulink" href="https://www.igvita.com/2015/08/17/eliminating-roundtrips-with-preconnect/" target="_top">connect speculatively</a> to
... ...
@@ -1108,26 +1119,42 @@ connections and rel="preconnect" usage where a proxy is used (see <a class="ulin
1108 1119
 3 in bug 18762</a> for further details). Explicit prefetching via the
1109 1120
 rel="prefetch" attribute is still performed, however.
1110 1121
 
1111
-      </p><p><span class="command"><strong>Design Goal:</strong></span>
1122
+      </p><p>
1112 1123
 
1113 1124
 All pre-loaded links and speculative connections MUST be isolated to the URL
1114 1125
 bar domain, if enabled. This includes isolating both Tor circuit use, as well
1115 1126
 as the caching and associate browser state for the prefetched resource.
1116 1127
 
1117
-      </p><p><span class="command"><strong>Implementation Status:</strong></span>
1128
+      </p><p>
1118 1129
 
1119 1130
 For automatic speculative connects and rel="preconnect", we leave them
1120 1131
 disabled as per the Mozilla default for proxy settings. However, if enabled,
1121 1132
 speculative connects will be isolated to the proper first party Tor circuit by
1122
-the same mechanism as is used for HTTP Keep-alive. This is true for rel="prefetch"
1123
-requests as well. For rel="preconnect", we isolate them <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0esr-6.5-2&amp;id=9126303651785d02f2df0554f391fffba0b0a00e" target="_top">via
1124
-this patch</a>. This isolation makes both preconnecting and cache warming
1125
-via rel=prefetch ineffective for links to domains other than the current URL
1126
-bar domain. For links to the same domain as the URL bar domain, the full cache
1127
-warming benefit is obtained. As an optimization, any preconnecting to domains
1128
-other than the current URL bar domain can thus be disabled (perhaps with the
1129
-exception of frames), but we do not do this. We allow these requests to
1130
-proceed, but we isolate them.
1133
+the same mechanism as is used for HTTP Keep-Alive. This is true for rel="prefetch"
1134
+requests as well. For rel="preconnect", we set <span class="command"><strong>privacy.firstparty.isolate</strong></span>
1135
+to <span class="command"><strong>true</strong></span>. This isolation makes both preconnecting and cache
1136
+warming via rel="prefetch" ineffective for links to domains other than the
1137
+current URL bar domain. For links to the same domain as the URL bar domain,
1138
+the full cache warming benefit is obtained. As an optimization, any
1139
+preconnecting to domains other than the current URL bar domain can thus be
1140
+disabled (perhaps with the exception of frames), but we do not do this.
1141
+We allow these requests to proceed, but we isolate them.
1142
+
1143
+      </p></li><li class="listitem"><span class="command"><strong>Permissions API</strong></span><p>
1144
+
1145
+The Permissions API allows a website to query the status of different
1146
+permissions. Although permissions are keyed to the origin, that is not enough to
1147
+alleviate cross-linkabilility concerns: the combined permission state could work
1148
+like an identifier given more and more permissions and their state being
1149
+accessible under this API.
1150
+
1151
+      </p><p><span class="command"><strong>Design Goal:</strong></span>
1152
+
1153
+Permissions MUST be isolated to the URL bar domain.
1154
+
1155
+      </p><p><span class="command"><strong>Implementation Status:</strong></span>
1156
+
1157
+Right now we provide a <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&amp;id=14374d30767f83923561084530b54c066bb661b4" target="_top">Firefox patch</a> that makes sure permissions are isolated to the URL bar domain.
1131 1158
 
1132 1159
       </p></li></ol></div><p>
1133 1160
 For more details on identifier linkability bugs and enhancements, see the <a class="ulink" href="https://trac.torproject.org/projects/tor/query?keywords=~tbb-linkability&amp;status=!closed" target="_top">tbb-linkability tag in our bugtracker</a>
... ...
@@ -1306,7 +1333,7 @@ narrow domain or use case, or when there are alternate ways of accomplishing
1306 1333
 the same task, these features and/or certain aspects of their functionality
1307 1334
 may be simply removed.
1308 1335
 
1309
-   </p></li></ol></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idm608"></a>Strategies for Defense: Randomization versus Uniformity</h4></div></div></div><p>
1336
+   </p></li></ol></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idm646"></a>Strategies for Defense: Randomization versus Uniformity</h4></div></div></div><p>
1310 1337
 
1311 1338
 When applying a form of defense to a specific fingerprinting vector or source,
1312 1339
 there are two general strategies available: either the implementation for all
... ...
@@ -1316,10 +1343,10 @@ each interaction between a user and a site provides a different fingerprint.
1316 1343
 
1317 1344
     </p><p>
1318 1345
 
1319
-Although <a class="ulink" href="http://research.microsoft.com/pubs/209989/tr1.pdf" target="_top">some
1320
-research suggests</a> that randomization can be effective, so far striving
1321
-for uniformity has generally proved to be a better strategy for Tor Browser
1322
-for the following reasons:
1346
+Although <a class="ulink" href="https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/tr1-1.pdf" target="_top">
1347
+some research suggests</a> that randomization can be effective, so far
1348
+striving for uniformity has generally proved to be a better strategy for Tor
1349
+Browser for the following reasons:
1323 1350
 
1324 1351
     </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><span class="command"><strong>Evaluation and measurement difficulties</strong></span><p>
1325 1352
 
... ...
@@ -1430,8 +1457,8 @@ only after the user has specifically enabled plugins. Flash is the only plugin
1430 1457
 available, the rest are entirely
1431 1458
 blocked from loading by the Firefox patches mentioned in the <a class="link" href="#proxy-obedience" title="4.1. Proxy Obedience">Proxy Obedience
1432 1459
 section</a>. We also set the Firefox
1433
-preference <span class="command"><strong>plugin.expose_full_path</strong></span> to false, to avoid
1434
-leaking plugin installation information.
1460
+preference <span class="command"><strong>plugin.expose_full_path</strong></span> to
1461
+<span class="command"><strong>false</strong></span>, to avoid leaking plugin installation information.
1435 1462
 
1436 1463
      </p></li><li class="listitem"><span class="command"><strong>HTML5 Canvas Image Extraction</strong></span><p>
1437 1464
 
... ...
@@ -1453,7 +1480,7 @@ fingerprinting vectors. If WebGL is normalized through software rendering,
1453 1480
 system colors were standardized, and the browser shipped a fixed collection of
1454 1481
 fonts (see later points in this list), it might not be necessary to create a
1455 1482
 canvas permission. However, until then, to reduce the threat from this vector,
1456
-we have patched Firefox to <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0esr-6.5-2&amp;id=526e6d0bc5c68d8c409cbaefc231c71973d949cc" target="_top">prompt before returning valid image data</a> to the Canvas APIs,
1483
+we have patched Firefox to <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&amp;id=196354d7951a48b4e6f5309d2a8e46962fff9d5f" target="_top">prompt before returning valid image data</a> to the Canvas APIs,
1457 1484
 and for access to isPointInPath and related functions. Moreover, we put media
1458 1485
 streams on a canvas behind the site permission in that patch as well.
1459 1486
 If the user hasn't previously allowed the site in the URL bar to access Canvas
... ...
@@ -1484,7 +1511,10 @@ Tor client then rejects them, since it is configured to proxy for internal IP
1484 1511
 addresses by default. Access to the local network is forbidden via the same
1485 1512
 mechanism. We also disable the WebRTC API as mentioned previously, since even
1486 1513
 if it were usable over Tor, it still currently provides the local IP address
1487
-and associated network information to websites.
1514
+and associated network information to websites. Additionally, we
1515
+<a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&amp;id=13baf9df4b47bd13bb7da045048ed4339615ac03" target="_top">
1516
+rip out</a> the option to collect local IP addresses via the
1517
+NetworkInfoService.
1488 1518
 
1489 1519
      </p></li><li class="listitem"><span class="command"><strong>Invasive Authentication Mechanisms (NTLM and SPNEGO)</strong></span><p>
1490 1520
 
... ...
@@ -1495,7 +1525,8 @@ aren't an attractive vector for this reason. However, because it is not clear
1495 1525
 if certain carefully-crafted error conditions in these protocols could cause
1496 1526
 them to reveal machine information and still fail silently prior to the
1497 1527
 password prompt, these authentication mechanisms should either be disabled, or
1498
-placed behind a site permission before their use. We simply disable them.
1528
+placed behind a site permission before their use. We simply disable them
1529
+<a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&amp;id=fe465944545a76287842321175cc7713091e77b1" target="_top">with a patch</a>.
1499 1530
 
1500 1531
      </p></li><li class="listitem"><span class="command"><strong>USB Device ID Enumeration via the GamePad API</strong></span><p>
1501 1532
 
... ...
@@ -1518,7 +1549,7 @@ it via the pref <span class="command"><strong>dom.gamepad.enabled</strong></span
1518 1549
      </p></li><li class="listitem"><span class="command"><strong>Fonts</strong></span><p>
1519 1550
 
1520 1551
 According to the Panopticlick study, fonts provide the most linkability when
1521
-they are provided as an enumerable list in file system order, via either the
1552
+they are available as an enumerable list in file system order, via either the
1522 1553
 Flash or Java plugins. However, it is still possible to use CSS and/or
1523 1554
 JavaScript to query for the existence of specific fonts. With a large enough
1524 1555
 pre-built list to query, a large amount of fingerprintable information may
... ...
@@ -1540,7 +1571,8 @@ vary in detail.
1540 1571
 
1541 1572
 For Windows and macOS we use a preference, <span class="command"><strong>font.system.whitelist</strong></span>,
1542 1573
 to restrict fonts being used to those in the whitelist. This functionality is
1543
-provided <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0esr-6.5-2&amp;id=80d233db514a556d7255034ae057b138527cb2ea" target="_top">by a Firefox patch</a>.
1574
+provided by setting <span class="command"><strong>privacy.resistFingerprinting</strong></span> to
1575
+<span class="command"><strong>true</strong></span>.
1544 1576
 The whitelist for Windows and macOS contains both a set of
1545 1577
 <a class="ulink" href="https://www.google.com/get/noto" target="_top">Noto fonts</a> which we bundle
1546 1578
 and fonts provided by the operating system. For Linux systems we only bundle
... ...
@@ -1595,11 +1627,13 @@ maximizing their windows can lead to fingerprintability under the current scheme
1595 1627
 
1596 1628
      </p><p><span class="command"><strong>Implementation Status:</strong></span>
1597 1629
 
1598
-We automatically resize new browser windows to a 200x100 pixel multiple <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0esr-6.5-2&amp;id=7b3e68bd7172d4f3feac11e74c65b06729a502b2" target="_top">based
1599
-on desktop resolution</a> which is provided by a Firefox patch. To minimize
1600
-the effect of the long tail of large monitor sizes, we also cap the window size
1601
-at 1000 pixels in each direction. In addition to that we set
1602
-<span class="command"><strong>privacy.resistFingerprinting</strong></span>
1630
+We automatically resize new browser windows to a 200x100 pixel multiple based
1631
+on desktop resolution by backporting patches from
1632
+<a class="ulink" href="" target="_top">bug 1330882</a>
1633
+and setting <span class="command"><strong>privacy.resistfingerprinting</strong></span> to
1634
+<span class="command"><strong>true</strong></span>. To minimize the effect of the long tail of large
1635
+monitor sizes, we also cap the window size at 1000 pixels in each direction.
1636
+In addition to that we set <span class="command"><strong>privacy.resistFingerprinting</strong></span>
1603 1637
 to <span class="command"><strong>true</strong></span> to use the client content window size for
1604 1638
 window.screen, and to report a window.devicePixelRatio of 1.0. Similarly,
1605 1639
 we use that preference to return content window relative points for DOM events.
... ...
@@ -1630,12 +1664,12 @@ details such as screen orientation or type.
1630 1664
      </p><p><span class="command"><strong>Implementation Status:</strong></span>
1631 1665
 
1632 1666
 We set <span class="command"><strong>ui.use_standins_for_native_colors</strong></span> to <span class="command"><strong>true
1633
-</strong></span> and provide a <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0esr-6.5-2&amp;id=c6be9ba561a69250c7d5926d90e0112091453643" target="_top">Firefox patch</a>
1667
+</strong></span> and provide a <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&amp;id=9e84b962ae4e7369fcf13fdf3adb646877d48f1d" target="_top">Firefox patch</a>
1634 1668
 to report a fixed set of system colors to content window CSS, and prevent
1635 1669
 detection of font smoothing on macOS with the help of
1636
-<span class="command"><strong>privacy.resistFingerprinting</strong></span>. We also always
1637
-<a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0esr-6.5-2&amp;id=5a159c6bfa310b4339555de389ac16cf8e13b3f5" target="_top">
1638
-report landscape-primary</a> for the <a class="ulink" href="https://w3c.github.io/screen-orientation/" target="_top">screen orientation</a>.
1670
+<span class="command"><strong>privacy.resistFingerprinting</strong></span> set to <span class="command"><strong>true</strong></span>.
1671
+We use the same preference, too, to always report landscape-primary for the
1672
+<a class="ulink" href="https://w3c.github.io/screen-orientation/" target="_top">screen orientation</a>.
1639 1673
 
1640 1674
      </p></li><li class="listitem"><span class="command"><strong>WebGL</strong></span><p>
1641 1675
 
... ...
@@ -1645,24 +1679,25 @@ fingerprinting.
1645 1679
 
1646 1680
      </p><p>
1647 1681
 
1648
-Because of the large amount of potential fingerprinting vectors and the <a class="ulink" href="http://www.contextis.com/resources/blog/webgl/" target="_top">previously unexposed
1649
-vulnerability surface</a>, we deploy a similar strategy against WebGL as
1650
-for plugins. First, WebGL Canvases have click-to-play placeholders (provided
1651
-by NoScript), and do not run until authorized by the user. Second, we
1652
-obfuscate driver information by setting the Firefox preferences
1682
+Because of the large amount of potential fingerprinting vectors and the <a class="ulink" href="https://www.contextis.com/resources/blog/webgl-new-dimension-browser-exploitation/" target="_top">
1683
+previously unexposed vulnerability surface</a>, we deploy a similar strategy
1684
+against WebGL as for plugins. First, WebGL Canvases have click-to-play
1685
+placeholders (provided by NoScript), and do not run until authorized by the user.
1686
+Second, we obfuscate driver information by setting the Firefox preferences
1653 1687
 <span class="command"><strong>webgl.disable-extensions</strong></span>,
1654 1688
 <span class="command"><strong>webgl.min_capability_mode</strong></span>, and
1655
-<span class="command"><strong>webgl.disable-fail-if-major-performance-caveat</strong></span> which reduce
1656
-the information provided by the following WebGL API calls:
1657
-<span class="command"><strong>getParameter()</strong></span>, <span class="command"><strong>getSupportedExtensions()</strong></span>,
1658
-and <span class="command"><strong>getExtension()</strong></span>. To make the minimal WebGL mode usable we
1659
-additionally <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0esr-6.5-2&amp;id=7b0caa1224c3417754d688344eacc97fbbabf7d5" target="_top">
1689
+<span class="command"><strong>webgl.disable-fail-if-major-performance-caveat</strong></span> to
1690
+<span class="command"><strong>true</strong></span> which reduces the information provided by the following
1691
+WebGL API calls: <span class="command"><strong>getParameter()</strong></span>,
1692
+<span class="command"><strong>getSupportedExtensions()</strong></span>, and <span class="command"><strong>getExtension()</strong></span>. Furthermore, WebGL2 is disabled by setting <span class="command"><strong>webgl.enable-webgl2</strong></span>
1693
+to <span class="command"><strong>false</strong></span>. To make the minimal WebGL mode usable we
1694
+additionally <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&amp;id=1acd0c7fae9121240401cf4a8f0e2b1f6fdb9827" target="_top">
1660 1695
 normalize its properties with a Firefox patch</a>.
1661 1696
 
1662 1697
      </p><p>
1663 1698
 
1664 1699
 Another option for WebGL might be to use software-only rendering, using a
1665
-library such as <a class="ulink" href="http://www.mesa3d.org/" target="_top">Mesa</a>. The use of
1700
+library such as <a class="ulink" href="https://www.mesa3d.org/" target="_top">Mesa</a>. The use of
1666 1701
 such a library would avoid hardware-specific rendering differences.
1667 1702
 
1668 1703
      </p></li><li class="listitem"><span class="command"><strong>MediaDevices API</strong></span><p>
... ...
@@ -1681,10 +1716,37 @@ on the application software and/or drivers a user chose to install. Web pages
1681 1716
 can not only estimate the amount of MIME types registered by checking
1682 1717
 <span class="command"><strong>navigator.mimetypes.length</strong></span>. Rather, they are even able to
1683 1718
 test whether particular MIME types are available which can have a non-negligible
1684
-impact on a user's fingerprint. We prevent both of these information leaks with
1685
-a direct <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0esr-6.5-2&amp;id=38999857761196b0b7f59f49ee93ae13f73c6149" target="_top">Firefox patch</a>.
1686
-
1687
-    </p></li><li class="listitem"><span class="command"><strong>System Uptime</strong></span><p>
1719
+impact on a user's fingerprint. We prevent both of these information leaks by
1720
+setting <span class="command"><strong>privacy.resistfingerprinting</strong></span> to <span class="command"><strong>true</strong></span>.
1721
+    </p></li><li class="listitem"><span class="command"><strong>Web Speech API</strong></span><p>
1722
+
1723
+The Web Speech API consists of two parts: SpeechSynthesis (Text-to-Speech) and
1724
+SpeechRecognition (Asynchronous Speech Recognition). The latter is still
1725
+disabled in Firefox. However, the former is enabled by default and there is the
1726
+risk that <span class="command"><strong>speechSynthesis.getVoices()</strong></span> has access to
1727
+computer-specific speech packages making them available in an enumerable
1728
+fashion. Morevover, there are callbacks that would allow JavaScript to time how
1729
+long a phrase takes to be "uttered". To prevent both we set
1730
+<span class="command"><strong>media.webspeech.synth.enabled</strong></span> to <span class="command"><strong>false</strong></span>.
1731
+
1732
+      </p></li><li class="listitem"><span class="command"><strong>Touch API</strong></span><p>
1733
+
1734
+Touch events are able to reveal the absolute screen coordinates of a device
1735
+which would defeat our approach to mitigate leaking the screen size as described
1736
+above. In order to prevent that we implemented two defenses: first we disable
1737
+the Touch API by setting <span class="command"><strong>dom.w3c_touch_events.enabled</strong></span> to
1738
+<span class="command"><strong>false</strong></span>. Second, for those user that really need or want to
1739
+have this API available we patched the code to give content-window related
1740
+coordinates back. Furthermore, we made sure that the touch area described by
1741
+<span class="command"><strong>Touch.radiusX</strong></span>, <span class="command"><strong>Touch.radiusY</strong></span>, and
1742
+<span class="command"><strong>Touch.rotationAngle</strong></span> does not leak further information and
1743
+<span class="command"><strong>Touch.force</strong></span> does not reveal how much pressure a user applied
1744
+to the surface. That is achieved by a direct
1745
+<a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&amp;id=7d9701c2b6a203b1b7a556f614858588e3e5976e" target="_top">
1746
+Firefox patch</a> which reports back <span class="command"><strong>1</strong></span> for the first two
1747
+properties and <span class="command"><strong>0.0</strong></span> for the two last ones.
1748
+
1749
+      </p></li><li class="listitem"><span class="command"><strong>System Uptime</strong></span><p>
1688 1750
 
1689 1751
 It is possible to get the system uptime of a Tor Browser user by querying the
1690 1752
 <span class="command"><strong>Event.timestamp</strong></span> property. We avoid this by setting <span class="command"><strong>
... ...
@@ -1708,9 +1770,9 @@ Browser user.
1708 1770
 
1709 1771
       </p><p><span class="command"><strong>Implementation Status:</strong></span>
1710 1772
 
1711
-We provide <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0esr-6.5-2&amp;id=a65b5269ff04e4fbbb3689e2adf853543804ffbf" target="_top">two</a>
1712
-<a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0esr-6.5-2&amp;id=383b8e7e073ea79e70f19858efe1c5fde64b99cf" target="_top">Firefox patches</a> that
1713
-take care of spoofing <span class="command"><strong>KeyboardEvent.code</strong></span> and <span class="command"><strong>
1773
+We provide <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&amp;id=d6d29f155e60c63b38918c8879ee221b9c90b1f7" target="_top">two</a>
1774
+<a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&amp;id=789bad5fe5a7a0c2d27e1d8dd7b9a7e35de91cc8" target="_top">Firefox patches</a>
1775
+that take care of spoofing <span class="command"><strong>KeyboardEvent.code</strong></span> and <span class="command"><strong>
1714 1776
 KeyboardEvent.keyCode</strong></span> by providing consensus (US-English-style) fake
1715 1777
 properties. This is achieved by hiding the user's use of the numpad, and any
1716 1778
 non-QWERTY US English keyboard. Characters from non-en-US languages
... ...
@@ -1730,7 +1792,7 @@ these headers should remain identical across the population even when updated.
1730 1792
 Firefox provides several options for controlling the browser user agent string
1731 1793
 which we leverage. We also set similar prefs for controlling the
1732 1794
 Accept-Language and Accept-Charset headers, which we spoof to English by default. Additionally, we
1733
-<a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0esr-6.5-2&amp;id=848da9cdb2b7c09dc8ec335d687f535fc5c87a67" target="_top">remove
1795
+<a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&amp;id=bd51d0c24d339c5135028297f5eeb591a65e99df" target="_top">remove
1734 1796
 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
1735 1797
 used</a> to fingerprint OS, platform, and Firefox minor version.  </p></li><li class="listitem"><span class="command"><strong>Timing-based Side Channels</strong></span><p>
1736 1798
 Attacks based on timing side channels are nothing new in the browser context.
... ...
@@ -1748,25 +1810,31 @@ timing-based side channels.
1748 1810
       </p><p><span class="command"><strong>Implementation Status:</strong></span>
1749 1811
 
1750 1812
 The cleanest solution to timing-based side channels would be to get rid of them.
1751
-However, this does not seem to be trivial even considering just a
1813
+This has been <a class="ulink" href="https://acmccs.github.io/papers/p163-caoA.pdf" target="_top">proposed</a>
1814
+in the research community. However, we remain skeptical as it does not seem to
1815
+be trivial even considering just a
1752 1816
 <a class="ulink" href="https://bugzilla.mozilla.org/show_bug.cgi?id=711043" target="_top">single</a>
1753
-<a class="ulink" href="https://cseweb.ucsd.edu/~dkohlbre/papers/subnormal.pdf" target="_top">side channel</a>.
1754
-Thus, we rely on disabling all possible timing sources or making them
1755
-coarse-grained enough in order to render timing side channels unsuitable as a
1756
-means for fingerprinting browser users.
1817
+<a class="ulink" href="https://cseweb.ucsd.edu/~dkohlbre/papers/subnormal.pdf" target="_top">side channel</a>
1818
+and <a class="ulink" href="https://gruss.cc/files/fantastictimers.pdf" target="_top">more and more
1819
+potential side channels</a> are showing up. Thus, we rely on disabling all
1820
+possible timing sources or making them coarse-grained enough in order to render
1821
+timing side channels unsuitable as a means for fingerprinting browser users.
1757 1822
 
1758 1823
       </p><p>
1759 1824
 
1760 1825
 We set <span class="command"><strong>dom.enable_user_timing</strong></span> and
1761 1826
 <span class="command"><strong>dom.enable_resource_timing</strong></span> to <span class="command"><strong>false</strong></span> to
1762 1827
 disable these explicit timing sources. Furthermore, we clamp the resolution of
1763
-explicit clocks to 100ms <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0esr-6.5-2&amp;id=1febc98f7ae5dbec845567415bd5b703ee45d774" target="_top">with a Firefox patch</a>.
1828
+explicit clocks to 100ms <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&amp;id=1736ea256276546c899d712dffdae2c8d050d8a0" target="_top">with two Firefox</a> <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&amp;id=a4c6d2c07d483acfd729c7a50dd3f7b07fcba03a" target="_top">patches</a>.
1764 1829
 
1765 1830
 This includes <span class="command"><strong>performance.now()</strong></span>, <span class="command"><strong>new Date().getTime()
1766 1831
 </strong></span>, <span class="command"><strong>audioContext.currentTime</strong></span>, <span class="command"><strong>
1767 1832
 canvasStream.currentTime</strong></span>, <span class="command"><strong>video.currentTime</strong></span>,
1768 1833
 <span class="command"><strong>audio.currentTime</strong></span>, <span class="command"><strong>new File([], "").lastModified
1769
-</strong></span>, and <span class="command"><strong>new File([], "").lastModifiedDate.getTime()</strong></span>.
1834
+</strong></span>, <span class="command"><strong>new File([], "").lastModifiedDate.getTime()</strong></span>,
1835
+<span class="command"><strong>animation.startTime</strong></span>, <span class="command"><strong>animation.currentTime</strong></span>,
1836
+<span class="command"><strong>animation.timeline.currentTime</strong></span>,
1837
+and <span class="command"><strong>document.timeline.currentTime</strong></span>.
1770 1838
 
1771 1839
       </p><p>
1772 1840
 
... ...
@@ -1796,7 +1864,7 @@ out of a Tor Browser user by deploying resource:// and/or chrome:// URIs. Until
1796 1864
 this is fixed in Firefox <a class="ulink" href="https://gitweb.torproject.org/torbutton.git/tree/src/components/content-policy.js" target="_top">
1797 1865
 we filter</a> resource:// and chrome:// requests done
1798 1866
 by web content denying them by default. We need a whitelist of resource:// and
1799
-chrome:// URIs, though, to avoid breaking parts of Firefox. Those nearly a
1867
+chrome:// URIs, though, to avoid breaking parts of Firefox. Those more than a
1800 1868
 dozen Firefox resources do not aid in fingerprinting Tor Browser users as they
1801 1869
 are not different on the platforms and in the locales we support.
1802 1870
 
... ...
@@ -1814,7 +1882,7 @@ We set the fallback character set to set to windows-1252 for all locales, via
1814 1882
 <span class="command"><strong>javascript.use_us_english_locale</strong></span> to <span class="command"><strong>true</strong></span>
1815 1883
 to instruct the JS engine to use en-US as its internal C locale for all Date,
1816 1884
 Math, and exception handling. Additionally, we provide a patch to use an
1817
-<a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0esr-6.5-2&amp;id=0080b2d6bafcbfb8a57f54a26e53d7f74d239389" target="_top">
1885
+<a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&amp;id=d144738fedeeb23746d7a9f16067bd985b0d59aa" target="_top">
1818 1886
 en-US label for the <span class="command"><strong>isindex</strong></span> HTML element</a> instead of
1819 1887
 letting the label leak the browser's UI locale.
1820 1888
      </p></li><li class="listitem"><span class="command"><strong>Timezone and Clock Offset</strong></span><p>
... ...
@@ -1829,7 +1897,7 @@ All Tor Browser users MUST report the same timezone to websites. Currently, we
1829 1897
 choose UTC for this purpose, although an equally valid argument could be made
1830 1898
 for EDT/EST due to the large English-speaking population density (coupled with
1831 1899
 the fact that we spoof a US English user agent). Additionally, the Tor
1832
-software should detect if the users clock is significantly divergent from the
1900
+software should detect if the user's clock is significantly divergent from the
1833 1901
 clocks of the relays that it connects to, and use this to reset the clock
1834 1902
 values used in Tor Browser to something reasonably accurate. Alternatively,
1835 1903
 the browser can obtain this clock skew via a mechanism similar to that used in
... ...
@@ -1837,19 +1905,19 @@ the browser can obtain this clock skew via a mechanism similar to that used in
1837 1905
 
1838 1906
      </p><p><span class="command"><strong>Implementation Status:</strong></span>
1839 1907
 
1840
-We <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0esr-6.5-2&amp;id=0ee3aa4cbeb1be3301d8960d0cf3a64831ea6d1b" target="_top">
1908
+We <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&amp;id=dd1ba0b5c9281ee3207e5a87991159b8d2609a11" target="_top">
1841 1909
 set the timezone to UTC</a> with a Firefox patch using the TZ environment
1842 1910
 variable, which is supported on all platforms. Moreover, with an additional
1843
-patch just needed for the Windows platform, <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0esr-6.5-2&amp;id=bdd0303a78347d17250950a4cf858de556afb1c7" target="_top">
1911
+patch just needed for the Windows platform, <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&amp;id=008649e2ce0357f31eb67d874e6429c39ddd7e8f" target="_top">
1844 1912
 we make sure</a> the TZ environment variable is respected by the
1845 1913
 <a class="ulink" href="http://site.icu-project.org/" target="_top">ICU library</a> as well.
1846 1914
 
1847 1915
      </p></li><li class="listitem"><span class="command"><strong>JavaScript Performance Fingerprinting</strong></span><p>
1848 1916
 
1849
-<a class="ulink" href="http://w2spconf.com/2011/papers/jspriv.pdf" target="_top">JavaScript performance
1850
-fingerprinting</a> is the act of profiling the performance
1851
-of various JavaScript functions for the purpose of fingerprinting the
1852
-JavaScript engine and the CPU.
1917
+<a class="ulink" href="https://cseweb.ucsd.edu/~hovav/dist/jspriv.pdf" target="_top">JavaScript
1918
+performance fingerprinting</a> is the act of profiling the performance of
1919
+various JavaScript functions for the purpose of fingerprinting the JavaScript
1920
+engine and the CPU.
1853 1921
 
1854 1922
      </p><p><span class="command"><strong>Design Goal:</strong></span>
1855 1923
 
... ...
@@ -1860,7 +1928,7 @@ favorite is to reduce the resolution of the Event.timeStamp and the JavaScript
1860 1928
 Date() object, while also introducing jitter. We believe that JavaScript time
1861 1929
 resolution may be reduced all the way up to the second before it seriously
1862 1930
 impacts site operation. Our goal with this quantization is to increase the
1863
-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
1931
+amount of time it takes to mount a successful attack. <a class="ulink" href="https://cseweb.ucsd.edu/~hovav/dist/jspriv.pdf" target="_top">Mowery et al</a> found
1864 1932
 that even with the default precision in most browsers, they required up to 120
1865 1933
 seconds of amortization and repeated trials to get stable results from their
1866 1934
 feature set. We intend to work with the research community to establish the
... ...
@@ -1873,11 +1941,12 @@ large number of people.
1873 1941
      </p><p><span class="command"><strong>Implementation Status:</strong></span>
1874 1942
 
1875 1943
 Currently, our mitigation against performance fingerprinting is to
1876
-disable <a class="ulink" href="http://www.w3.org/TR/navigation-timing/" target="_top">Navigation
1877
-Timing</a> through the Firefox preference
1878
-<span class="command"><strong>dom.enable_performance</strong></span>, and to disable the <a class="ulink" href="https://developer.mozilla.org/en-US/docs/Web/API/HTMLVideoElement#Gecko-specific_properties" target="_top">Mozilla
1879
-Video Statistics</a> API extensions via the preference
1880
-<span class="command"><strong>media.video_stats.enabled</strong></span>.
1944
+disable <a class="ulink" href="https://www.w3.org/TR/navigation-timing/" target="_top">Navigation
1945
+Timing</a> by setting the Firefox preference
1946
+<span class="command"><strong>dom.enable_performance</strong></span> to <span class="command"><strong>false</strong></span>, and to
1947
+disable the <a class="ulink" href="https://developer.mozilla.org/en-US/docs/Web/API/HTMLVideoElement#Gecko-specific_properties" target="_top">Mozilla
1948
+Video Statistics</a> API extensions by setting the preference
1949
+<span class="command"><strong>media.video_stats.enabled</strong></span> to <span class="command"><strong>false</strong></span>, too.
1881 1950
 
1882 1951
      </p></li><li class="listitem"><span class="command"><strong>Keystroke Fingerprinting</strong></span><p>
1883 1952
 
... ...
@@ -1891,9 +1960,44 @@ fingerprinting: timestamp quantization and jitter.
1891 1960
 
1892 1961
      </p><p><span class="command"><strong>Implementation Status:</strong></span>
1893 1962
 
1894
-We clamp keyboard event resolution to 100ms with a <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0esr-6.5-2&amp;id=1febc98f7ae5dbec845567415bd5b703ee45d774" target="_top">Firefox patch</a>.
1963
+We clamp keyboard event resolution to 100ms with a <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&amp;id=1736ea256276546c899d712dffdae2c8d050d8a0" target="_top">Firefox patch</a>.
1964
+
1965
+     </p></li><li class="listitem"><span class="command"><strong>Amount of Processor Cores (hardwareConcurrency)</strong></span><p>
1895 1966
 
1896
-     </p></li><li class="listitem"><span class="command"><strong>Connection State</strong></span><p>
1967
+Modern computers have multiple physical processor cores in their CPU available.
1968
+One core typically allows to run more than one thread at a time and
1969
+<span class="command"><strong>navigator.hardwareConcurrency</strong></span> makes the number of those
1970
+threads (i.e. logical processors) available to web content.
1971
+
1972
+      </p><p><span class="command"><strong>Design Goal:</strong></span>
1973
+
1974
+Websites MUST NOT be able to fingerprint a Tor Browser user taking advantage of
1975
+the amount of logical processors available.
1976
+
1977
+      </p><p><span class="command"><strong>Implementation Status:</strong></span>
1978
+
1979
+We set <span class="command"><strong>dom.maxHardwareConcurrency</strong></span> to <span class="command"><strong>1</strong></span> to
1980
+report the same amount of logical processors for everyone. However, there are
1981
+<a class="ulink" href="https://github.com/oftn/core-estimator" target="_top">probablistic ways of
1982
+determining the same information available</a> which we are not defending
1983
+against currently. Moreover, we might even want to think about a more elaborate
1984
+approach defending against this fingerprinting technique by not making all users
1985
+uniform but rather <a class="ulink" href="https://bugs.torproject.org/22127" target="_top">by following
1986
+a bucket approach</a> as we currently do in our defense against screen
1987
+size exfiltration.
1988
+
1989
+      </p></li><li class="listitem"><span class="command"><strong>MediaError.message</strong></span><p>
1990
+
1991
+The <span class="command"><strong>MediaError</strong></span> object allows the user agent to report errors
1992
+that occurred while handling media, for instance using <span class="command"><strong>audio</strong></span>
1993
+or <span class="command"><strong>video</strong></span> elements. The <span class="command"><strong>message</strong></span> property
1994
+provides specific diagnostic information to help understanding the error
1995
+condition. As a defense-in-depth we make sure that no information aiding in
1996
+fingerprinting is leaking to websites that way
1997
+<span class="command"><strong>
1998
+by returning just an empty string</strong></span>.
1999
+
2000
+      </p></li><li class="listitem"><span class="command"><strong>Connection State</strong></span><p>
1897 2001
 
1898 2002
 It is possible to monitor the connection state of a browser over time with
1899 2003
 <a class="ulink" href="https://developer.mozilla.org/en-US/docs/Web/API/NavigatorOnLine/onLine" target="_top">
... ...
@@ -1937,7 +2041,12 @@ datareporting.healthreport.about.reportUrl</strong></span> and the new tiles fea
1937 2041
 related <span class="command"><strong>browser.newtabpage.directory.ping</strong></span> and <span class="command"><strong>
1938 2042
 browser.newtabpage.directory.source</strong></span> preferences. Additionally, we
1939 2043
 disable the UITour backend by setting <span class="command"><strong>browser.uitour.enabled</strong></span>
1940
-to <span class="command"><strong>false</strong></span>.
2044
+to <span class="command"><strong>false</strong></span>. Finally, we provide <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&amp;id=9f24ce35cd8776a0f7c3a4d54992ecb0eaad6311" target="_top">a patch</a>
2045
+to prevent Mozilla's websites from querying whether particular extensions are
2046
+installed and what their state in Tor Browser is by using the
2047
+<span class="command"><strong>window.navigator.AddonManager</strong></span> API. As a defense-in-depth the
2048
+patch makes sure that not only Mozilla's websites can't get at that information
2049
+but that the whitelist governing this access is empty in general.
1941 2050
       </p></li><li class="listitem"><span class="command"><strong>Operating System Type Fingerprinting</strong></span><p>
1942 2051
 
1943 2052
 As we mentioned in the introduction of this section, OS type fingerprinting is
... ...
@@ -1955,7 +2064,7 @@ We intend to reduce or eliminate OS type fingerprinting to the best extent
1955 2064
 possible, but recognize that the effort for reward on this item is not as high
1956 2065
 as other areas. The entropy on the current OS distribution is somewhere around
1957 2066
 2 bits, which is much lower than other vectors which can also be used to
1958
-fingerprint configuration and user-specific information.  You can see the
2067
+fingerprint configuration and user-specific information. You can see the
1959 2068
 major areas of OS fingerprinting we're aware of using the <a class="ulink" href="https://trac.torproject.org/projects/tor/query?keywords=~tbb-fingerprinting-os" target="_top">tbb-fingerprinting-os
1960 2069
 tag on our bug tracker</a>.
1961 2070
 
... ...
@@ -1977,11 +2086,11 @@ In order to avoid long-term linkability, we provide a "New Identity" context
1977 2086
 menu option in Torbutton. This context menu option is active if Torbutton can
1978 2087
 read the environment variables $TOR_CONTROL_PASSWD and $TOR_CONTROL_PORT.
1979 2088
 
1980
-   </p><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idm914"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote">
2089
+   </p><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idm1011"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote">
1981 2090
 
1982 2091
 All linkable identifiers and browser state MUST be cleared by this feature.
1983 2092
 
1984
-    </blockquote></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idm917"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p>
2093
+    </blockquote></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idm1014"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p>
1985 2094
 
1986 2095
 First, Torbutton disables JavaScript in all open tabs and windows by using
1987 2096
 both the <a class="ulink" href="https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIDocShell#Attributes" target="_top">browser.docShell.allowJavaScript</a>
... ...
@@ -2000,14 +2109,14 @@ After closing all tabs, we then clear the searchbox and findbox text and emit
2000 2109
 state). Then we manually clear the following state: HTTP auth, SSL state,
2001 2110
 crypto tokens, OCSP state, site-specific content preferences (including HSTS
2002 2111
 state), the undo tab history, content and image cache, offline and memory cache,
2003
-offline storage, cookies, DOM storage, the safe browsing key, the
2004
-Google wifi geolocation token (if it exists), and the domain isolator state. We
2005
-also clear NoScript's site and temporary permissions, and all other browser site
2006
-permissions.
2112
+offline storage, IndexedDB storage, asm.js cache, cookies, DOM storage, the
2113
+safe browsing key, the Google wifi geolocation token (if it exists), and the
2114
+domain isolator state. We also clear NoScript's site and temporary permissions,
2115
+and all other browser site permissions.
2007 2116
 
2008 2117
      </p><p>
2009 2118
 
2010
-After the state is cleared, we then close all remaining HTTP keep-alive
2119
+After the state is cleared, we then close all remaining HTTP Keep-Alive
2011 2120
 connections and then send the NEWNYM signal to the Tor control port to cause a
2012 2121
 new circuit to be created.
2013 2122
      </p><p>
... ...
@@ -2045,7 +2154,9 @@ includes three features that were formerly governed by the slider at
2045 2154
 higher security levels: <span class="command"><strong>gfx.font_rendering.graphite.enabled</strong></span>
2046 2155
 is set to <span class="command"><strong>false</strong></span> now after Mozilla got convinced that
2047 2156
 <a class="ulink" href="https://bugzilla.mozilla.org/show_bug.cgi?id=1255731" target="_top">leaving
2048
-it enabled is too risky</a>. <span class="command"><strong>network.jar.block-remote-files</strong></span>
2157
+it enabled is too risky</a>. Even though Mozilla reverted that decision
2158
+after another round of fixing critical Graphite bugs, we remain skeptical
2159
+and keep that feature disabled for now. <span class="command"><strong>network.jar.block-remote-files</strong></span>
2049 2160
 is set to <span class="command"><strong>true</strong></span>. Mozilla tried to block remote JAR files in
2050 2161
 Firefox 45 but needed to revert that decision due to breaking IBM's iNotes.
2051 2162
 While Mozilla <a class="ulink" href="https://bugzilla.mozilla.org/show_bug.cgi?id=1329336" target="_top">
... ...
@@ -2059,9 +2170,9 @@ Unlinkability</a> sections for further details.
2059 2170
       </p></li><li class="listitem"><span class="command"><strong>Medium</strong></span><p>
2060 2171
 
2061 2172
 At this security level, we disable the ION JIT
2062
-(<span class="command"><strong>javascript.options.ion.content</strong></span>), TypeInference JIT
2063
-(<span class="command"><strong>javascript.options.typeinference</strong></span>), Baseline JIT
2064
-(<span class="command"><strong>javascript.options.baselinejit.content</strong></span>), WebAudio
2173
+(<span class="command"><strong>javascript.options.ion</strong></span>), native regular expressions
2174
+(<span class="command"><strong>javascript.options.native_regexp</strong></span>), Baseline JIT
2175
+(<span class="command"><strong>javascript.options.baselinejit</strong></span>), WebAudio
2065 2176
 (<span class="command"><strong>media.webaudio.enabled</strong></span>), MathML
2066 2177
 (<span class="command"><strong>mathml.disabled</strong></span>), SVG Opentype font rendering
2067 2178
 (<span class="command"><strong>gfx.font_rendering.opentype_svg.enabled</strong></span>), and make HTML5 audio
... ...
@@ -2084,7 +2195,7 @@ images (<span class="command"><strong>svg.in-content.enabled</strong></span>).
2084 2195
 Fingerprinting</a> is a statistical attack to attempt to recognize specific
2085 2196
 encrypted website activity.
2086 2197
 
2087
-     </p><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idm975"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p>
2198
+     </p><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idm1072"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p>
2088 2199
 
2089 2200
 We want to deploy a mechanism that reduces the accuracy of <a class="ulink" href="https://en.wikipedia.org/wiki/Feature_selection" target="_top">useful features</a> available
2090 2201
 for classification. This mechanism would either impact the true and false
... ...
@@ -2096,18 +2207,18 @@ that could be classified at a given accuracy rate.
2096 2207
 Ideally, this mechanism would be as light-weight as possible, and would be
2097 2208
 tunable in terms of overhead. We suspect that it may even be possible to
2098 2209
 deploy a mechanism that reduces feature extraction resolution without any
2099
-network overhead. In the no-overhead category, we have <a class="ulink" href="http://freehaven.net/anonbib/cache/LZCLCP_NDSS11.pdf" target="_top">HTTPOS</a> and
2210
+network overhead. In the no-overhead category, we have <a class="ulink" href="https://freehaven.net/anonbib/cache/LZCLCP_NDSS11.pdf" target="_top">HTTPOS</a> and
2100 2211
 <a class="ulink" href="https://blog.torproject.org/blog/experimental-defense-website-traffic-fingerprinting" target="_top">better
2101 2212
 use of HTTP pipelining and/or SPDY</a>.
2102 2213
 In the tunable/low-overhead
2103 2214
 category, we have <a class="ulink" href="https://arxiv.org/abs/1512.00524" target="_top">Adaptive
2104
-Padding</a> and <a class="ulink" href="http://www.cs.sunysb.edu/~xcai/fp.pdf" target="_top">
2215
+Padding</a> and <a class="ulink" href="https://www3.cs.stonybrook.edu/~xcai/fp.pdf" target="_top">
2105 2216
 Congestion-Sensitive BUFLO</a>. It may be also possible to <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/7028" target="_top">tune such
2106 2217
 defenses</a> such that they only use existing spare Guard bandwidth capacity in the Tor
2107 2218
 network, making them also effectively no-overhead.
2108 2219
 
2109
-     </p></blockquote></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idm987"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p>
2110
-Currently, we patch Firefox to <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0esr-6.5-2&amp;id=60f9e7f73f3dba5542f7fbe882f7c804cb8ecc18" target="_top">randomize
2220
+     </p></blockquote></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idm1084"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p>
2221
+Currently, we patch Firefox to <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&amp;id=b9fa77472aa67e26bd46a5ca889b20ce3448f9d1" target="_top">randomize
2111 2222
 pipeline order and depth</a>. Unfortunately, pipelining is very fragile.
2112 2223
 Many sites do not support it, and even sites that advertise support for
2113 2224
 pipelining may simply return error codes for successive requests, effectively
... ...
@@ -2158,7 +2269,7 @@ date.
2158 2269
 
2159 2270
      </p><p>
2160 2271
 
2161
-We also make use of the in-browser Mozilla updater, and have <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0esr-6.5-2&amp;id=a5a23f5d316a850f11063ead15353d677c9153fd" target="_top">patched
2272
+We also make use of the in-browser Mozilla updater, and have <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&amp;id=0efd496826cc3dfb0a6874d150e8acecd4eb6a92" target="_top">patched
2162 2273
 the updater</a> to avoid sending OS and Kernel version information as part
2163 2274
 of its update pings.
2164 2275
 
... ...
@@ -2171,7 +2282,7 @@ contend with. For this reason, we have deployed a build system
2171 2282
 that allows anyone to use our source code to reproduce byte-for-byte identical
2172 2283
 binary packages to the ones that we distribute.
2173 2284
 
2174
-  </p><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idm1010"></a>5.1. Achieving Binary Reproducibility</h3></div></div></div><p>
2285
+  </p><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idm1107"></a>5.1. Achieving Binary Reproducibility</h3></div></div></div><p>
2175 2286
 
2176 2287
 The GNU toolchain has been working on providing reproducible builds for some
2177 2288
 time, however a large software project such as Firefox typically ends up
... ...
@@ -2279,7 +2390,7 @@ particular: libgmp) attempt to detect the current CPU to determine which
2279 2390
 optimizations to compile in. This CPU type is uniform on our KVM instances,
2280 2391
 but differs under LXC.
2281 2392
 
2282
-   </p></li></ol></div></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idm1042"></a>5.2. Package Signatures and Verification</h3></div></div></div><p>
2393
+   </p></li></ol></div></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idm1139"></a>5.2. Package Signatures and Verification</h3></div></div></div><p>
2283 2394
 
2284 2395
 The build process generates a single sha256sums-unsigned-build.txt file that
2285 2396
 contains a sorted list of the SHA-256 hashes of every package produced for that
... ...
@@ -2312,7 +2423,7 @@ In order to verify package integrity, the signature must be stripped off using
2312 2423
 the osslsigncode tool, as described on the <a class="ulink" href="https://www.torproject.org/docs/verifying-signatures.html.en#BuildVerification" target="_top">Signature
2313 2424
 Verification</a> page.
2314 2425
 
2315
-    </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idm1049"></a>5.3. Anonymous Verification</h3></div></div></div><p>
2426
+    </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idm1146"></a>5.3. Anonymous Verification</h3></div></div></div><p>
2316 2427
 
2317 2428
 Due to the fact that bit-identical packages can be produced by anyone, the
2318 2429
 security of this build system extends beyond the security of the official
... ...
@@ -2382,25 +2493,26 @@ occurring.
2382 2493
 
2383 2494
 </p><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="deprecate"></a>A.1. Deprecation Wishlist</h2></div></div></div><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><span class="command"><strong>The Referer Header</strong></span><p>
2384 2495
 
2385
-When leaving a .onion domain we <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.8.0esr-6.5-2&amp;id=09188cb14dfaa8ac22f687c978166c7bd171b576" target="_top">
2386
-set the Referer header to the destination</a> to avoid leaking information
2387
-which might be especially problematic in the case of transitioning from a .onion
2388
-domain to one reached over clearnet. Apart from that we haven't disabled or
2389
-restricted the Referer ourselves because of the non-trivial number of sites
2390
-that rely on the Referer header to "authenticate" image requests and deep-link
2391
-navigation on their sites. Furthermore, there seems to be no real privacy
2392
-benefit to taking this action by itself in a vacuum, because many sites have
2393
-begun encoding Referer URL information into GET parameters when they need it to
2394
-cross HTTP to HTTPS scheme transitions. Google's +1 buttons are the best
2496
+When leaving a .onion domain we set the Referer header to an empty string by
2497
+<a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&amp;id=021bffff111b6b93eecb5859e680d540991c20c9" target="_top">
2498
+providing a preference</a>, <span class="command"><strong>network.http.referer.hideOnionSource</strong></span>, and setting it to <span class="command"><strong>true</strong></span>. That avoids leaking
2499
+information which might be especially problematic in the case of transitioning
2500
+from a .onion domain to one reached over clearnet. Apart from that we haven't
2501
+disabled or restricted the Referer ourselves because of the non-trivial number
2502
+of sites that rely on the Referer header to "authenticate" image requests and
2503
+deep-link navigation on their sites. Furthermore, there seems to be no real
2504
+privacy benefit to taking this action by itself in a vacuum, because many sites
2505
+have begun encoding Referer URL information into GET parameters when they need
2506
+it to cross HTTP to HTTPS scheme transitions. Google's +1 buttons are the best
2395 2507
 example of this activity.
2396 2508
 
2397 2509
   </p><p>
2398 2510
 
2399 2511
 Because of the availability of these other explicit vectors, we believe the
2400 2512
 main risk of the Referer header is through inadvertent and/or covert data
2401
-leakage. In fact, <a class="ulink" href="http://www2.research.att.com/~bala/papers/wosn09.pdf" target="_top">a great deal of
2402
-personal data</a> is inadvertently leaked to third parties through the
2403
-source URL parameters.
2513
+leakage. In fact, <a class="ulink" href="http://web2.research.att.com/export/sites/att_labs/people/Krishnamurthy_Balachander/papers/wosn09.pdf" target="_top">
2514
+a great deal of personal data</a> is inadvertently leaked to third parties
2515
+through the source URL parameters.
2404 2516
 
2405 2517
   </p><p>
2406 2518
 
... ...
@@ -2421,7 +2533,7 @@ attribute.
2421 2533
 <a class="ulink" href="https://developer.mozilla.org/En/DOM/Window.name" target="_top">window.name</a> is
2422 2534
 a DOM property that for some reason is allowed to retain a persistent value
2423 2535
 for the lifespan of a browser tab. It is possible to utilize this property for
2424
-<a class="ulink" href="http://www.thomasfrank.se/sessionvars.html" target="_top">identifier
2536
+<a class="ulink" href="https://www.thomasfrank.se/sessionvars.html" target="_top">identifier
2425 2537
 storage</a> during click navigation. This is sometimes used for additional
2426 2538
 CSRF protection and federated login.
2427 2539
    </p><p>
... ...
@@ -2447,12 +2559,13 @@ possible for us to <a class="ulink" href="https://trac.torproject.org/projects/t
2447 2559
 ourselves</a>, as they are comparatively rare and can be handled with site
2448 2560
 permissions.
2449 2561
 
2450
-   </p></li></ol></div></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="idm1090"></a>A.2. Promising Standards</h2></div></div></div><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><a class="ulink" href="http://web-send.org" target="_top">Web-Send Introducer</a><p>
2562
+   </p></li></ol></div></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="idm1189"></a>A.2. Promising Standards</h2></div></div></div><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><a class="ulink" href="https://web.archive.org/web/20130213034335/http://web-send.org:80/" target="_top">Web-Send Introducer</a><p>
2451 2563
 
2452 2564
 Web-Send is a browser-based link sharing and federated login widget that is
2453 2565
 designed to operate without relying on third-party tracking or abusing other
2454
-cross-origin link-click side channels. It has a compelling list of <a class="ulink" href="http://web-send.org/features.html" target="_top">privacy and security features</a>,
2455
-especially if used as a "Like button" replacement.
2566
+cross-origin link-click side channels. It has a compelling list of <a class="ulink" href="https://web.archive.org/web/20130213034335/http://web-send.org:80/featurs.html" target="_top">
2567
+privacy and security features</a>, especially if used as a "Like button"
2568
+replacement.
2456 2569
 
2457 2570
    </p></li><li class="listitem"><a class="ulink" href="https://developer.mozilla.org/en-US/docs/Persona" target="_top">Mozilla Persona</a><p>
2458 2571