Browse code

Merge branch 'master' into staging

Sebastian Hahn authored on10/11/2014 02:08:58
Showing2 changed files
... ...
@@ -1,7 +1,7 @@
1 1
 #!wml
2 2
 
3 3
 <define-tag gitblob whitespace=delete>https://gitweb.torproject.org/tor.git?a=blob_plain;hb=HEAD;f=</define-tag>
4
-<define-tag gitblobstable whitespace=delete>https://gitweb.torproject.org/tor.git?a=blob_plain;hb=release-0.2.4;f=</define-tag>
4
+<define-tag gitblobstable whitespace=delete>https://gitweb.torproject.org/tor.git?a=blob_plain;hb=release-0.2.5;f=</define-tag>
5 5
 <define-tag gittree whitespace=delete>https://gitweb.torproject.org/tor.git?a=tree;hb=HEAD;f=</define-tag>
6 6
 <define-tag gitrepo whitespace=delete>https://gitweb.torproject.org/tor.git?a=tree;hb=HEAD</define-tag>
7 7
 <define-tag svnwebsite whitespace=delete>https://svn.torproject.org/svn/website/trunk/</define-tag>
... ...
@@ -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.78.1" /></head><body><div class="article"><div class="titlepage"><div><div><h2 class="title"><a id="design"></a>The Design and Implementation of the Tor Browser [DRAFT]</h2></div><div><div class="author"><h3 class="author"><span class="firstname">Mike</span> <span class="surname">Perry</span></h3><div class="affiliation"><div class="address"><p><code class="email">&lt;<a class="email" href="mailto:mikeperry#torproject org">mikeperry#torproject org</a>&gt;</code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Erinn</span> <span class="surname">Clark</span></h3><div class="affiliation"><div class="address"><p><code class="email">&lt;<a class="email" href="mailto:erinn#torproject org">erinn#torproject org</a>&gt;</code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Steven</span> <span class="surname">Murdoch</span></h3><div class="affiliation"><div class="address"><p><code class="email">&lt;<a class="email" href="mailto:sjmurdoch#torproject org">sjmurdoch#torproject org</a>&gt;</code></p></div></div></div></div><div><p class="pubdate">October 30th, 2014</p></div></div><hr /></div><div class="toc"><p><strong>Table of Contents</strong></p><dl class="toc"><dt><span class="sect1"><a href="#idp33097664">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="#idp39143984">5.1. Achieving Binary Reproducibility</a></span></dt><dt><span class="sect2"><a href="#idp39178848">5.2. Package Signatures and Verification</a></span></dt><dt><span class="sect2"><a href="#idp39182784">5.3. Anonymous Verification</a></span></dt></dl></dd><dt><span class="appendix"><a href="#Transparency">A. Towards Transparency in Navigation Tracking</a></span></dt><dd><dl><dt><span class="sect1"><a href="#deprecate">A.1. Deprecation Wishlist</a></span></dt><dt><span class="sect1"><a href="#idp39214016">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="idp33097664"></a>1. Introduction</h2></div></div></div><p>
2
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>The Design and Implementation of the Tor Browser [DRAFT]</title><meta name="generator" content="DocBook XSL Stylesheets V1.78.1" /></head><body><div class="article"><div class="titlepage"><div><div><h2 class="title"><a id="design"></a>The Design and Implementation of the Tor Browser [DRAFT]</h2></div><div><div class="author"><h3 class="author"><span class="firstname">Mike</span> <span class="surname">Perry</span></h3><div class="affiliation"><div class="address"><p><code class="email">&lt;<a class="email" href="mailto:mikeperry#torproject org">mikeperry#torproject org</a>&gt;</code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Erinn</span> <span class="surname">Clark</span></h3><div class="affiliation"><div class="address"><p><code class="email">&lt;<a class="email" href="mailto:erinn#torproject org">erinn#torproject org</a>&gt;</code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Steven</span> <span class="surname">Murdoch</span></h3><div class="affiliation"><div class="address"><p><code class="email">&lt;<a class="email" href="mailto:sjmurdoch#torproject org">sjmurdoch#torproject org</a>&gt;</code></p></div></div></div></div><div><p class="pubdate">November 6th, 2014</p></div></div><hr /></div><div class="toc"><p><strong>Table of Contents</strong></p><dl class="toc"><dt><span class="sect1"><a href="#idp59720528">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="#idp60597904">5.1. Achieving Binary Reproducibility</a></span></dt><dt><span class="sect2"><a href="#idp60632800">5.2. Package Signatures and Verification</a></span></dt><dt><span class="sect2"><a href="#idp60636736">5.3. Anonymous Verification</a></span></dt></dl></dd><dt><span class="appendix"><a href="#Transparency">A. Towards Transparency in Navigation Tracking</a></span></dt><dd><dl><dt><span class="sect1"><a href="#deprecate">A.1. Deprecation Wishlist</a></span></dt><dt><span class="sect1"><a href="#idp60669376">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="idp59720528"></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
-4.0.
6
+4.5-alpha-1.
7 7
 
8 8
   </p><p>
9 9
 
... ...
@@ -26,7 +26,7 @@ a number of Firefox preferences</a> from their defaults.
26 26
 Tor process management and configuration is accomplished through the <a class="ulink" href="https://gitweb.torproject.org/tor-launcher.git" target="_top">Tor Launcher</a>
27 27
 addon, which provides the initial Tor configuration splash screen and
28 28
 bootstrap progress bar. Tor Launcher is also compatible with Thunderbird,
29
-InstantBird, and XULRunner.
29
+Instantbird, and XULRunner.
30 30
 
31 31
    </p><p>
32 32
 
... ...
@@ -85,7 +85,7 @@ Separation</strong></span></a><p>
85 85
 
86 86
 The browser MUST NOT provide the content window with any state from any other
87 87
 browsers or any non-Tor browsing modes. This includes shared state from
88
-independent plugins, and shared state from Operating System implementations of
88
+independent plugins, and shared state from operating system implementations of
89 89
 TLS and other support libraries.
90 90
 
91 91
 </p></li><li class="listitem"><a class="link" href="#disk-avoidance" title="4.3. Disk Avoidance"><span class="command"><strong>Disk
... ...
@@ -108,7 +108,7 @@ must be able to ensure that secure deletion of the software is sufficient to
108 108
 remove evidence of the use of the software. All exceptions and shortcomings
109 109
 due to operating system behavior MUST be wiped by an uninstaller. However, due
110 110
 to permissions issues with access to swap, implementations MAY choose to leave
111
-it out of scope, and/or leave it to the Operating System/platform to implement
111
+it out of scope, and/or leave it to the operating system/platform to implement
112 112
 ephemeral-keyed encrypted swap.
113 113
 
114 114
 </p></li></ol></div></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="privacy"></a>2.2. Privacy Requirements</h3></div></div></div><p>
... ...
@@ -209,7 +209,7 @@ failure of Torbutton</a> was the options panel. Each option
209 209
 that detectably alters browser behavior can be used as a fingerprinting tool.
210 210
 Similarly, all extensions <a class="ulink" href="http://blog.chromium.org/2010/06/extensions-in-incognito.html" target="_top">should be
211 211
 disabled in the mode</a> except as an opt-in basis. We should not load
212
-system-wide and/or Operating System provided addons or plugins.
212
+system-wide and/or operating system provided addons or plugins.
213 213
 
214 214
      </p><p>
215 215
 Instead of global browser privacy options, privacy decisions should be made
... ...
@@ -289,10 +289,14 @@ least <a class="link" href="#fingerprinting">tracking their activities</a>.
289 289
 
290 290
      </p></li><li class="listitem"><span class="command"><strong>History records and other on-disk
291 291
 information</strong></span><p>
292
+
292 293
 In some cases, the adversary may opt for a heavy-handed approach, such as
293 294
 seizing the computers of all Tor users in an area (especially after narrowing
294 295
 the field by the above two pieces of information). History records and cache
295
-data are the primary goals here.
296
+data are the primary goals here. Secondary goals may include confirming
297
+on-disk identifiers (such as hostname and disk-logged spoofed MAC adddress
298
+history) obtained by other means.
299
+
296 300
      </p></li></ol></div></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="adversary-positioning"></a>3.2. Adversary Capabilities - Positioning</h3></div></div></div><p>
297 301
 The adversary can position themselves at a number of different locations in
298 302
 order to execute their attacks.
... ...
@@ -588,11 +592,6 @@ connections are not attempted, through the proxy or otherwise (Tor does not
588 592
 yet support IPv6). We have also verified that external protocol helpers, such
589 593
 as smb urls and other custom protocol handlers are all blocked.
590 594
 
591
- </p><p>
592
-
593
-Numerous other third parties have also reviewed and tested the proxy settings
594
-and have provided test cases based on their work. See in particular <a class="ulink" href="http://decloak.net/" target="_top">decloak.net</a>. 
595
-
596 595
  </p></li><li class="listitem">Disabling plugins
597 596
 
598 597
  <p>Plugins have the ability to make arbitrary OS system calls and  <a class="ulink" href="http://decloak.net/" target="_top">bypass proxy settings</a>. This includes
... ...
@@ -655,13 +654,13 @@ system-wide extensions (through the use of
655 654
 disabled, which prevents Flash cookies from leaking from a pre-existing Flash
656 655
 directory.
657 656
 
658
-   </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="disk-avoidance"></a>4.3. Disk Avoidance</h3></div></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp38917584"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote">
657
+   </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="idp60374176"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote">
659 658
 
660 659
 The User Agent MUST (at user option) prevent all disk records of browser activity.
661 660
 The user should be able to optionally enable URL history and other history
662 661
 features if they so desire. 
663 662
 
664
-    </blockquote></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp38918944"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote">
663
+    </blockquote></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp60375536"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote">
665 664
 
666 665
 We achieve this goal through several mechanisms. First, we set the Firefox
667 666
 Private Browsing preference
... ...
@@ -735,7 +734,7 @@ the url bar origin for which browser state exists, possibly with a
735 734
 context-menu option to drill down into specific types of state or permissions.
736 735
 An example of this simplification can be seen in Figure 1.
737 736
 
738
-   </p><div class="figure"><a id="idp38941648"></a><p class="title"><strong>Figure 1. Improving the Privacy UI</strong></p><div class="figure-contents"><div class="mediaobject" align="center"><img src="NewCookieManager.png" align="middle" alt="Improving the Privacy UI" /></div><div class="caption"><p></p>
737
+   </p><div class="figure"><a id="idp60398240"></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>
739 738
 
740 739
 This example UI is a mock-up of how isolating identifiers to the URL bar
741 740
 origin can simplify the privacy UI for all data - not just cookies. Once
... ...
@@ -773,7 +772,7 @@ of HTTP POST data.
773 772
 However, to <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3666" target="_top">increase the
774 773
 security of the isolation</a> and to <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3754" target="_top">solve conflicts
775 774
 with OCSP relying the cacheKey property for reuse of POST requests</a>, we
776
-had to <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0004-Add-a-string-based-cacheKey.patch" target="_top">patch
775
+had to <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/18dfd3064aff23a402fec248aab797036a9ba615" target="_top">patch
777 776
 Firefox to provide a cacheDomain cache attribute</a>. We use the fully
778 777
 qualified url bar domain as input to this field, to avoid the complexities
779 778
 of heuristically determining the second-level DNS name.
... ...
@@ -799,7 +798,7 @@ FQDN that was used to source the third party element.
799 798
      </p><p>
800 799
 
801 800
 Additionally, because the image cache is a separate entity from the content
802
-cache, we had to patch Firefox to also <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0024-Isolate-the-Image-Cache-per-url-bar-domain.patch" target="_top">isolate
801
+cache, we had to patch Firefox to also <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/114cd22282f8b3cd6e6a5c29de8a8c396a79acc0" target="_top">isolate
803 802
 this cache per url bar domain</a>.
804 803
 
805 804
      </p></li><li class="listitem">HTTP Auth
... ...
@@ -814,7 +813,7 @@ linkability between domains</a>.
814 813
 
815 814
 DOM storage for third party domains MUST be isolated to the url bar origin,
816 815
 to prevent linkability between sites. This functionality is provided through a
817
-<a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0026-Isolate-DOM-storage-to-first-party-URI.patch" target="_top">patch
816
+<a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/973468a07fb9e7d9995d01b250223a8df16d6cfd" target="_top">patch
818 817
 to Firefox</a>.
819 818
 
820 819
      </p></li><li class="listitem">Flash cookies
... ...
@@ -843,7 +842,7 @@ origin MUST NOT be reused for that same third party in another url bar origin.
843 842
 We currently clear SSL Session IDs upon <a class="link" href="#new-identity" title="4.7. Long-Term Unlinkability via &quot;New Identity&quot; button">New
844 843
 Identity</a>, we disable TLS Session Tickets via the Firefox Pref
845 844
 <span class="command"><strong>security.enable_tls_session_tickets</strong></span>. We disable SSL Session
846
-IDs via a <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0008-Disable-SSL-Session-ID-tracking.patch" target="_top">patch
845
+IDs via a <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/5524ae43780e4738310852cc2a0b7c5d25aa69ed" target="_top">patch
847 846
 to Firefox</a>. To compensate for the increased round trip latency from disabling
848 847
 these performance optimizations, we also enable
849 848
 <a class="ulink" href="https://tools.ietf.org/html/draft-bmoeller-tls-falsestart-00" target="_top">TLS
... ...
@@ -934,20 +933,13 @@ cleared by <a class="link" href="#new-identity" title="4.7. Long-Term Unlinkabi
934 933
 defend against the creation of these cookies between <span class="command"><strong>New
935 934
 Identity</strong></span> invocations.
936 935
       </p></li><li class="listitem">Exit node usage
937
-     <p><span class="command"><strong>Design Goal:</strong></span>
938
-
939
-Every distinct navigation session (as defined by a non-blank Referer header)
940
-MUST exit through a fresh Tor circuit in Tor Browser to prevent exit node
941
-observers from linking concurrent browsing activity.
942
-
943
-     </p><p><span class="command"><strong>Implementation Status:</strong></span>
936
+    <p>
944 937
 
945
-The Tor feature that supports this ability only exists in the 0.2.3.x-alpha
946
-series. <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3455" target="_top">Ticket
947
-#3455</a> is the Torbutton ticket to make use of the new Tor
948
-functionality.
938
+All content elements associated with a given URL bar domain (including the
939
+main page) are given a SOCKS username and password for this domain, which
940
+causes Tor to isolate all of these requests on their own set of Tor circuits.
949 941
 
950
-     </p></li></ol></div><p>
942
+    </p></li></ol></div><p>
951 943
 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>
952 944
   </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="fingerprinting-linkability"></a>4.6. Cross-Origin Fingerprinting Unlinkability</h3></div></div></div><p>
953 945
 
... ...
@@ -962,42 +954,50 @@ determine how many bits of identifying information each attribute provided.
962 954
 
963 955
    </p><p>
964 956
 
965
-Because fingerprinting is problem that potentially touches every aspect of the
966
-browser, we reduce the efforts for fingerprinting resistance by only
967
-concerning ourselves with reducing the fingerprintable differences
968
-<span class="emphasis"><em>among</em></span> Tor Browser users. We do not believe it is possible
969
-to solve cross-browser fingerprinting issues. Similarly, we prioritize issues
970
-that differentiate only MacOS, Windows, and Linux lower than those that
971
-differentiate aspects of the hardware, third party installed software, and
972
-configuration differences in those operating systems.
957
+Unfortunately, there are limitations to the way the Panopticlick study was
958
+conducted. Because the Panopticlick dataset is based on browser data spanning
959
+a number of widely deployed browsers over a number of years, any
960
+fingerprinting defenses attempted by browsers today are very likely to cause
961
+Panopticlick to report an <span class="emphasis"><em>increase</em></span> in fingerprintability
962
+and entropy, because those defenses will stand out in sharp contrast to
963
+historical data. Moreover, because fingerprinting is a problem that
964
+potentially touches every aspect of the browser, we do not believe it is
965
+possible to solve cross-browser fingerprinting issues. We reduce the efforts
966
+for fingerprinting resistance by only concerning ourselves with reducing the
967
+fingerprintable differences <span class="emphasis"><em>among</em></span> Tor Browser users. 
973 968
 
974 969
    </p><p>
975 970
 
976
-Unfortunately, the unsolvable nature of the cross-browser fingerprinting
977
-problem means that the Panopticlick test website itself is not useful for
978
-evaluating the actual effectiveness of our defenses, or the fingerprinting
979
-defenses of any other web browser. Because the Panopticlick dataset is based
980
-on browser data spanning a number of widely deployed browsers over a number of
981
-years, any fingerprinting defenses attempted by browsers today are very likely
982
-to cause Panopticlick to report an <span class="emphasis"><em>increase</em></span> in
983
-fingerprintability and entropy, because those defenses will stand out in sharp
984
-contrast to historical data. We have been <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/6119" target="_top">working to convince
985
-the EFF</a> that it is worthwhile to release the source code to
986
-Panopticlick to allow us to run our own version for this reason.
971
+The unsolvable nature of the cross-browser fingerprinting problem also means
972
+that the Panopticlick test website itself is not useful for evaluating the
973
+actual effectiveness of our defenses, or the fingerprinting defenses of any
974
+other web browser. We are interested in deploying an improved version of
975
+Panopticlick that measures entropy and variance only among a specific user
976
+agent population, but until then, intuition serves as a decent guide.
977
+Essentially, anything that reveals custom user configuration, third party
978
+software, highly variable hardware details, and external devices attached to
979
+the users computer is likely to more fingerprintable than things like
980
+operating system type and even processor speed.
987 981
 
988 982
    </p><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="fingerprinting-defenses"></a>Fingerprinting defenses in the Tor Browser</h4></div></div></div><p>
989 983
 
990 984
 The following defenses are listed roughly in order of most severe
991
-fingerprinting threat first, though we are desperately in need of updated
992
-measurements to determine this with certainty. Where our actual implementation
993
-differs from an ideal solution, we separately describe our <span class="command"><strong>Design
994
-Goal</strong></span> and our <span class="command"><strong>Implementation Status</strong></span>.
985
+fingerprinting threat first. This ordering is based on the above intuition that
986
+user configurable aspects of the computer are the most severe source of
987
+fingerprintability, though we are in need of updated measurements to determine
988
+this with certainty.
989
+
990
+   </p><p>
991
+Where our actual implementation differs from
992
+an ideal solution, we separately describe our <span class="command"><strong>Design Goal</strong></span>
993
+and our <span class="command"><strong>Implementation Status</strong></span>.
995 994
 
996 995
    </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem">Plugins
997 996
      <p>
998 997
 
999
-Plugins add to fingerprinting risk via two main vectors: their mere presence in
1000
-window.navigator.plugins, as well as their internal functionality.
998
+Plugins add to fingerprinting risk via two main vectors: their mere presence
999
+in window.navigator.plugins (because they are optional, end-user installed
1000
+third party software), as well as their internal functionality.
1001 1001
 
1002 1002
      </p><p><span class="command"><strong>Design Goal:</strong></span>
1003 1003
 
... ...
@@ -1017,7 +1017,7 @@ Currently, we entirely disable all plugins in Tor Browser. However, as a
1017 1017
 compromise due to the popularity of Flash, we allow users to re-enable Flash,
1018 1018
 and flash objects are blocked behind a click-to-play barrier that is available
1019 1019
 only after the user has specifically enabled plugins. Flash is the only plugin
1020
-available, the rest are <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0005-Block-all-plugins-except-flash.patch" target="_top">entirely
1020
+available, the rest are <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/1ef32dcf0cc64876f5b92a583b788dc921f22c5d" target="_top">entirely
1021 1021
 blocked from loading by a Firefox patch</a>. We also set the Firefox
1022 1022
 preference <span class="command"><strong>plugin.expose_full_path</strong></span> to false, to avoid
1023 1023
 leaking plugin installation information.
... ...
@@ -1025,11 +1025,9 @@ leaking plugin installation information.
1025 1025
      </p></li><li class="listitem">HTML5 Canvas Image Extraction
1026 1026
      <p>
1027 1027
 
1028
-The <a class="ulink" href="https://developer.mozilla.org/en-US/docs/HTML/Canvas" target="_top">HTML5
1029
-Canvas</a> is a feature that has been added to major browsers after the
1030
-EFF developed their Panopticlick study. After plugins and plugin-provided
1031
-information, we believe that the HTML5 Canvas is the single largest
1032
-fingerprinting threat browsers face today. <a class="ulink" href="http://www.w2spconf.com/2012/papers/w2sp12-final4.pdf" target="_top">Initial
1028
+After plugins and plugin-provided information, we believe that the <a class="ulink" href="https://developer.mozilla.org/en-US/docs/HTML/Canvas" target="_top">HTML5
1029
+Canvas</a> is the single largest fingerprinting threat browsers face
1030
+today. <a class="ulink" href="http://www.w2spconf.com/2012/papers/w2sp12-final4.pdf" target="_top">Initial
1033 1031
 studies</a> show that the Canvas can provide an easy-access fingerprinting
1034 1032
 target: The adversary simply renders WebGL, font, and named color data to a
1035 1033
 Canvas element, extracts the image buffer, and computes a hash of that image
... ...
@@ -1041,8 +1039,9 @@ image can be used almost identically to a tracking cookie by the web server.
1041 1039
      </p><p>
1042 1040
 
1043 1041
 In some sense, the canvas can be seen as the union of many other
1044
-fingerprinting vectors. If WebGL were normalized through software rendering,
1045
-and the browser shipped a fixed collection of fonts, it might not be necessary
1042
+fingerprinting vectors. If WebGL is normalized through software rendering,
1043
+system colors were standardized, and the browser shipped a fixed collection of
1044
+fonts (see later points in this list), it might not be necessary
1046 1045
 to create a canvas permission. However, until then, to reduce the threat from
1047 1046
 this vector, we have patched Firefox to <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/3b53f525cfb68880e676e64f13cbc0b928ae3ecf" target="_top">prompt
1048 1047
 before returning valid image data</a> to the Canvas APIs, and for <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/fb9f463fe3a69499d6896c217786bafdf0cda62f" target="_top">access
... ...
@@ -1058,7 +1057,13 @@ In Firefox, by using either WebSockets or XHR, it is possible for remote
1058 1057
 content to <a class="ulink" href="http://www.andlabs.org/tools/jsrecon.html" target="_top">enumerate
1059 1058
 the list of TCP ports open on 127.0.0.1</a>. In other browsers, this can
1060 1059
 be accomplished by DOM events on image or script tags. This open vs filtered
1061
-vs closed port list can provide a very unique fingerprint of a machine.
1060
+vs closed port list can provide a very unique fingerprint of a machine,
1061
+because it essentially enables the detection of many different popular third
1062
+party applications and optional system services (Skype, Bitcoin, Bittorrent
1063
+and other P2P software, SSH ports, SMB and related LAN services, CUPS and
1064
+printer daemon config ports, mail servers, and so on). It is also possible to
1065
+determine when ports are closed versus filtered/blocked (and thus probe
1066
+custom firewall configuration).
1062 1067
 
1063 1068
      </p><p>In Tor Browser, we prevent access to
1064 1069
 127.0.0.1/localhost by ensuring that even these requests are still sent by
... ...
@@ -1066,7 +1071,19 @@ Firefox to our SOCKS proxy (ie we set
1066 1071
 <span class="command"><strong>network.proxy.no_proxies_on</strong></span> to the empty string). The local
1067 1072
 Tor client then rejects them, since it is configured to proxy for internal IP
1068 1073
 addresses by default.
1069
-     </p></li><li class="listitem">USB Device ID enumeration
1074
+     </p></li><li class="listitem">Invasive Authentication Mechanisms (NTLM and SPNEGO)
1075
+     <p>
1076
+
1077
+Both NTLM and SPNEGO authentication mechanisms can leak the hostname, and in
1078
+some cases the current username. The only reason why these aren't a more
1079
+serious problem is that they typically involve user interaction, and likely
1080
+aren't an attractive vector for this reason. However, because it is not clear
1081
+if certain carefully-crafted error conditions in these protocols could cause
1082
+them to reveal machine information and still fail silently prior to the
1083
+password prompt, these authentication mechanisms should either be disabled, or
1084
+placed behind a site permission before their use. We simply disable them.
1085
+
1086
+     </p></li><li class="listitem">USB Device ID Enumeration
1070 1087
      <p>
1071 1088
 
1072 1089
 The <a class="ulink" href="https://developer.mozilla.org/en-US/docs/Web/Guide/API/Gamepad" target="_top">GamePad
... ...
@@ -1077,38 +1094,6 @@ should be behind a site permission in Private Browsing Modes, or should present
1077 1094
 controller type (perhaps a two button controller that can be mapped to the keyboard) in all cases.
1078 1095
 We simply disable it via the pref <span class="command"><strong>dom.gamepad.enabled</strong></span>.
1079 1096
 
1080
-     </p></li><li class="listitem">Invasive Authentication Mechanisms (NTLM and SPNEGO)
1081
-     <p>
1082
-Both NTLM and SPNEGO authentication mechanisms can leak the hostname, and in
1083
-some cases the machine username. These authentication mechanisms should either
1084
-be disabled, or placed behind a site permission before their use. We simply
1085
-disable them.
1086
-     </p></li><li class="listitem">WebGL
1087
-     <p>
1088
-
1089
-WebGL is fingerprintable both through information that is exposed about the
1090
-underlying driver and optimizations, as well as through performance
1091
-fingerprinting.
1092
-
1093
-     </p><p>
1094
-
1095
-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
1096
-vulnerability surface</a>, we deploy a similar strategy against WebGL as
1097
-for plugins. First, WebGL Canvases have click-to-play placeholders (provided
1098
-by NoScript), and do not run until authorized by the user. Second, we
1099
-obfuscate driver information by setting the Firefox preferences
1100
-<span class="command"><strong>webgl.disable-extensions</strong></span> and
1101
-<span class="command"><strong>webgl.min_capability_mode</strong></span>, which reduce the information
1102
-provided by the following WebGL API calls: <span class="command"><strong>getParameter()</strong></span>,
1103
-<span class="command"><strong>getSupportedExtensions()</strong></span>, and
1104
-<span class="command"><strong>getExtension()</strong></span>.
1105
-
1106
-     </p><p>
1107
-
1108
-Another option for WebGL might be to use software-only rendering, using a
1109
-library such as <a class="ulink" href="http://www.mesa3d.org/" target="_top">Mesa</a>. The use of
1110
-such a library would avoid hardware-specific rendering differences.
1111
-
1112 1097
      </p></li><li class="listitem">Fonts
1113 1098
      <p>
1114 1099
 
... ...
@@ -1117,7 +1102,8 @@ they are provided as an enumerable list in filesystem order, via either the
1117 1102
 Flash or Java plugins. However, it is still possible to use CSS and/or
1118 1103
 Javascript to query for the existence of specific fonts. With a large enough
1119 1104
 pre-built list to query, a large amount of fingerprintable information may
1120
-still be available.
1105
+still be available, especially given that additional fonts often end up
1106
+installed by third party software and for multilingual support.
1121 1107
 
1122 1108
      </p><p><span class="command"><strong>Design Goal:</strong></span> The sure-fire way to address font
1123 1109
 linkability is to ship the browser with a font for every language, typeface,
... ...
@@ -1130,17 +1116,18 @@ and <a class="ulink" href="https://fedorahosted.org/lohit/" target="_top">Lohit
1130 1116
 font set is fairly complete by itself, but Nanum and Lohit have smaller
1131 1117
 versions of many South Asian languages. When combined in a way that chooses the
1132 1118
 smallest font implementations for each locale, these three font sets provide
1133
-which provide coverage for the all languages used on Wikipedia with more than
1119
+poverage for the all languages used on Wikipedia with more than
1134 1120
 10,000 articles, and several others as well, in approximately 3MB of compressed
1135 1121
 overhead. The <a class="ulink" href="https://www.google.com/get/noto/" target="_top">Noto font
1136 1122
 set</a> is another font set that aims for complete coverage, but is
1137 1123
 considerably larger than the combination of the Droid, Nanum, and Lohit fonts.
1124
+
1138 1125
      </p><p><span class="command"><strong>Implementation Status:</strong></span>
1139 1126
 
1140 1127
 In the meantime while we investigate shipping our own fonts, we disable
1141
-plugins, which prevents font enumeration. Additionally, we limit both the
1128
+plugins, which prevents font name enumeration. Additionally, we limit both the
1142 1129
 number of font queries from CSS, as well as the total number of fonts that can
1143
-be used in a document <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0011-Limit-the-number-of-fonts-per-document.patch" target="_top">with
1130
+be used in a document <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/d515c79ffd115b132caade7f881e5b467448964d" target="_top">with
1144 1131
 a Firefox patch</a>. We create two prefs,
1145 1132
 <span class="command"><strong>browser.display.max_font_attempts</strong></span> and
1146 1133
 <span class="command"><strong>browser.display.max_font_count</strong></span> for this purpose. Once these
... ...
@@ -1153,13 +1140,16 @@ To improve rendering, we exempt remote <a class="ulink" href="https://developer.
1153 1140
 fonts</a> from these counts, and if a font-family CSS rule lists a remote
1154 1141
 font (in any order), we use that font instead of any of the named local fonts.
1155 1142
 
1156
-     </p></li><li class="listitem">Monitor and Desktop resolution
1143
+     </p></li><li class="listitem">Monitor, Widget, and OS Desktop Resolution
1157 1144
      <p>
1158 1145
 
1159 1146
 Both CSS and Javascript have access to a lot of information about the screen
1160 1147
 resolution, usable desktop size, OS widget size, toolbar size, title bar size,
1161
-screen orientation, and other desktop features that are not at all relevant
1162
-to rendering and serve only to provide information for fingerprinting.
1148
+and OS desktop widget sizing information that are not at all relevant to
1149
+rendering and serve only to provide information for fingerprinting. Since many
1150
+aspects of desktop widget positioning and size are user configurable, these
1151
+properties yield customized information about the computer, even beyond the
1152
+monitor size.
1163 1153
 
1164 1154
      </p><p><span class="command"><strong>Design Goal:</strong></span>
1165 1155
 
... ...
@@ -1193,20 +1183,23 @@ addition, we prevent auto-maximizing on browser start, and are investigating a
1193 1183
 user-friendly way of informing users that maximized windows are detrimental
1194 1184
 to privacy in this mode.
1195 1185
 
1196
-     </p></li><li class="listitem">CSS Media Queries
1186
+     </p></li><li class="listitem">Display Media information
1197 1187
      <p>
1198 1188
 
1199
-Even without Javascript, CSS has access to a lot of information about the screen
1200
-resolution, usable desktop size, OS widget size, toolbar size, title bar size,
1201
-system theme colors, and other desktop features that are not at all relevant
1202
-to rendering and serve only to provide information for fingerprinting. Most of this information comes from 
1203
-<a class="ulink" href="https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Media_queries" target="_top">CSS Media Queries</a>, but 
1204
-Mozilla has exposed <a class="ulink" href="https://developer.mozilla.org/en-US/docs/Web/CSS/color_value#System_Colors" target="_top">several user and OS theme defined color values</a> to CSS as well.
1189
+Beyond simple resolution information, a large amount of so-called "Media"
1190
+information is also exported to content. Even without Javascript, CSS has
1191
+access to a lot of information about the device orientation, system theme
1192
+colors, and other desktop and display features that are not at all relevant to
1193
+rendering and also user configurable. Most of this
1194
+information comes from <a class="ulink" href="https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Media_queries" target="_top">CSS
1195
+Media Queries</a>, but Mozilla has exposed <a class="ulink" href="https://developer.mozilla.org/en-US/docs/Web/CSS/color_value#System_Colors" target="_top">several
1196
+user and OS theme defined color values</a> to CSS as well.
1205 1197
 
1206 1198
      </p><p><span class="command"><strong>Design Goal:</strong></span>
1207
-In Private Browsing Mode, CSS should not be able infer anything that the user
1208
-has configured about their computer. Additionally, it should not be able to
1209
-infer machine-specific details such as screen orientation or type.
1199
+
1200
+CSS should not be able infer anything that the user has configured about their
1201
+computer. Additionally, it should not be able to infer machine-specific
1202
+details such as screen orientation or type.
1210 1203
 
1211 1204
      </p><p><span class="command"><strong>Implementation Status:</strong></span>
1212 1205
 
... ...
@@ -1217,6 +1210,32 @@ detection of font smoothing on OSX</a>. We also always
1217 1210
 <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/09561f0e5452305b9efcb4e6169c613c8db33246" target="_top">report
1218 1211
 landscape-primary</a> for the screen orientation.
1219 1212
 
1213
+     </p></li><li class="listitem">WebGL
1214
+     <p>
1215
+
1216
+WebGL is fingerprintable both through information that is exposed about the
1217
+underlying driver and optimizations, as well as through performance
1218
+fingerprinting.
1219
+
1220
+     </p><p>
1221
+
1222
+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
1223
+vulnerability surface</a>, we deploy a similar strategy against WebGL as
1224
+for plugins. First, WebGL Canvases have click-to-play placeholders (provided
1225
+by NoScript), and do not run until authorized by the user. Second, we
1226
+obfuscate driver information by setting the Firefox preferences
1227
+<span class="command"><strong>webgl.disable-extensions</strong></span> and
1228
+<span class="command"><strong>webgl.min_capability_mode</strong></span>, which reduce the information
1229
+provided by the following WebGL API calls: <span class="command"><strong>getParameter()</strong></span>,
1230
+<span class="command"><strong>getSupportedExtensions()</strong></span>, and
1231
+<span class="command"><strong>getExtension()</strong></span>.
1232
+
1233
+     </p><p>
1234
+
1235
+Another option for WebGL might be to use software-only rendering, using a
1236
+library such as <a class="ulink" href="http://www.mesa3d.org/" target="_top">Mesa</a>. The use of
1237
+such a library would avoid hardware-specific rendering differences.
1238
+
1220 1239
      </p></li><li class="listitem">User Agent and HTTP Headers
1221 1240
      <p><span class="command"><strong>Design Goal:</strong></span>
1222 1241
 
... ...
@@ -1230,7 +1249,7 @@ these headers should remain identical across the population even when updated.
1230 1249
 Firefox provides several options for controlling the browser user agent string
1231 1250
 which we leverage. We also set similar prefs for controlling the
1232 1251
 Accept-Language and Accept-Charset headers, which we spoof to English by default. Additionally, we
1233
-<a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0001-Block-Components.interfaces-from-content.patch" target="_top">remove
1252
+<a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/95cd0e8071aa1fe3f4914331d4036f218007e31d" target="_top">remove
1234 1253
 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
1235 1254
 used</a> to fingerprint OS, platform, and Firefox minor version.  </p></li><li class="listitem">Locale Fingerprinting
1236 1255
      <p>
... ...
@@ -1248,12 +1267,13 @@ We set the fallback character set to set to windows-1252 for all locales, via
1248 1267
 the JS engine</a> to use en-US as its internal C locale for all Date, Math,
1249 1268
 and exception handling.
1250 1269
 
1251
-     </p></li><li class="listitem">Timezone and clock offset
1270
+     </p></li><li class="listitem">Timezone and Clock Offset
1252 1271
      <p>
1253 1272
 
1254 1273
 While the latency in Tor connections varies anywhere from milliseconds to
1255
-several seconds, it is still possible for the remote site to detect large
1256
-differences between the user's clock and an official reference timesource. 
1274
+a few seconds, it is still possible for the remote site to detect large
1275
+differences between the user's clock and an official reference time source. 
1276
+
1257 1277
      </p><p><span class="command"><strong>Design Goal:</strong></span>
1258 1278
 
1259 1279
 All Tor Browser users MUST report the same timezone to websites. Currently, we
... ...
@@ -1264,16 +1284,14 @@ software should detect if the users clock is significantly divergent from the
1264 1284
 clocks of the relays that it connects to, and use this to reset the clock
1265 1285
 values used in Tor Browser to something reasonably accurate. Alternatively,
1266 1286
 the browser can obtain this clock skew via a mechanism similar to that used in
1267
-<a class="ulink" href="" target="_top">tlsdate</a>.
1287
+<a class="ulink" href="https://github.com/ioerror/tlsdate" target="_top">tlsdate</a>.
1268 1288
 
1269 1289
      </p><p><span class="command"><strong>Implementation Status:</strong></span>
1270 1290
 
1271 1291
 We set the timezone using the TZ environment variable, which is supported on
1272
-all platforms. Additionally, we plan to <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3652" target="_top">obtain a clock
1273
-offset from Tor</a>, but this won't be available until Tor 0.2.3.x is in
1274
-use.
1292
+all platforms.
1275 1293
 
1276
-     </p></li><li class="listitem">Javascript performance fingerprinting
1294
+     </p></li><li class="listitem">Javascript Performance Fingerprinting
1277 1295
      <p>
1278 1296
 
1279 1297
 <a class="ulink" href="http://w2spconf.com/2011/papers/jspriv.pdf" target="_top">Javascript performance
... ...
@@ -1287,13 +1305,18 @@ We have <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3
1287 1305
 mitigation approaches</a> to reduce the accuracy of performance
1288 1306
 fingerprinting without risking too much damage to functionality. Our current
1289 1307
 favorite is to reduce the resolution of the Event.timeStamp and the Javascript
1290
-Date() object, while also introducing jitter. Our goal is to increase the
1291
-amount of time it takes to mount a successful attack. <a class="ulink" href="http://w2spconf.com/2011/papers/jspriv.pdf" target="_top">Mowery et al</a> found that
1292
-even with the default precision in most browsers, they required up to 120
1308
+Date() object, while also introducing jitter. We believe that Javascript time
1309
+resolution may be reduced all the way up to the second before it seriously
1310
+impacts site operation. Our goal with this quantization is to increase the
1311
+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
1312
+that even with the default precision in most browsers, they required up to 120
1293 1313
 seconds of amortization and repeated trials to get stable results from their
1294 1314
 feature set. We intend to work with the research community to establish the
1295
-optimum trade-off between quantization+jitter and amortization time.
1296
-
1315
+optimum trade-off between quantization+jitter and amortization time, as well
1316
+as identify highly variable Javascript operations. As long as these attacks
1317
+take several seconds or more to execute, they are unlikely to be appealing to
1318
+advertisers, and are also very likely to be noticed if deployed against a
1319
+large number of people.
1297 1320
 
1298 1321
      </p><p><span class="command"><strong>Implementation Status:</strong></span>
1299 1322
 
... ...
@@ -1302,17 +1325,7 @@ disable <a class="ulink" href="http://www.w3.org/TR/navigation-timing/" target="
1302 1325
 Timing</a> through the Firefox preference
1303 1326
 <span class="command"><strong>dom.enable_performance</strong></span>.
1304 1327
 
1305
-     </p></li><li class="listitem">Non-Uniform HTML5 API Implementations
1306
-     <p>
1307
-
1308
-At least two HTML5 features have different implementation status across the
1309
-major OS vendors: the <a class="ulink" href="https://developer.mozilla.org/en-US/docs/DOM/window.navigator.battery" target="_top">Battery
1310
-API</a> and the <a class="ulink" href="https://developer.mozilla.org/en-US/docs/DOM/window.navigator.connection" target="_top">Network
1311
-Connection API</a>. We disable these APIs
1312
-through the Firefox preferences <span class="command"><strong>dom.battery.enabled</strong></span> and
1313
-<span class="command"><strong>dom.network.enabled</strong></span>. 
1314
-
1315
-     </p></li><li class="listitem">Keystroke fingerprinting
1328
+     </p></li><li class="listitem">Keystroke Fingerprinting
1316 1329
      <p>
1317 1330
 
1318 1331
 Keystroke fingerprinting is the act of measuring key strike time and key
... ...
@@ -1325,48 +1338,50 @@ fingerprinting: timestamp quantization and jitter.
1325 1338
 
1326 1339
      </p><p><span class="command"><strong>Implementation Status:</strong></span>
1327 1340
 We have no implementation as of yet.
1328
-     </p></li><li class="listitem">Operating System type fingerprinting
1341
+     </p></li><li class="listitem">Operating System Type Fingerprinting
1329 1342
      <p>
1330 1343
 
1331 1344
 As we mentioned in the introduction of this section, OS type fingerprinting is
1332 1345
 currently considered a lower priority, due simply to the numerous ways that
1333
-characteristics of the Operating System type may leak into content, and the
1346
+characteristics of the operating system type may leak into content, and the
1334 1347
 comparatively low contribution of OS to overall entropy. In particular, there
1335 1348
 are likely to be many ways to measure the differences in widget size,
1336 1349
 scrollbar size, and other rendered details on a page. Also, directly exported
1337 1350
 OS routines, such as the Math library, expose differences in their
1338 1351
 implementations due to these results.
1339 1352
 
1340
-
1341 1353
      </p><p><span class="command"><strong>Design Goal:</strong></span>
1342 1354
 
1343 1355
 We intend to reduce or eliminate OS type fingerprinting to the best extent
1344 1356
 possible, but recognize that the effort for reward on this item is not as high
1345 1357
 as other areas. The entropy on the current OS distribution is somewhere around
1346 1358
 2 bits, which is much lower than other vectors which can also be used to
1347
-fingerprint configuration and user-specific information.
1359
+fingerprint configuration and user-specific information.  You can see the
1360
+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
1361
+tag on our bug tracker</a>.
1348 1362
 
1349 1363
      </p><p><span class="command"><strong>Implementation Status:</strong></span>
1350 1364
 
1351
-We have no defenses deployed that address OS type fingerprinting, but nothing
1352
-else. Several defenses may help also mitigate it, in addition to reducing a
1353
-lot more entropy elsewhere. You can see the major areas of OS fingerprinting
1354
-we're aware of using the tag <a class="ulink" href="https://trac.torproject.org/projects/tor/query?keywords=~tbb-fingerprinting-os" target="_top">tbb-fingerprinting-os
1355
-on our bugtracker</a>.
1365
+At least two HTML5 features have different implementation status across the
1366
+major OS vendors: the <a class="ulink" href="https://developer.mozilla.org/en-US/docs/DOM/window.navigator.battery" target="_top">Battery
1367
+API</a> and the <a class="ulink" href="https://developer.mozilla.org/en-US/docs/DOM/window.navigator.connection" target="_top">Network
1368
+Connection API</a>. We disable these APIs through the Firefox preferences
1369
+<span class="command"><strong>dom.battery.enabled</strong></span> and
1370
+<span class="command"><strong>dom.network.enabled</strong></span>. 
1356 1371
 
1357 1372
      </p></li></ol></div></div><p>
1358
-For more details on identifier linkability bugs and enhancements, see the <a class="ulink" href="https://trac.torproject.org/projects/tor/query?keywords=~tbb-fingerprinting&amp;status=!closed" target="_top">tbb-fingerprinting tag in our bugtracker</a>
1373
+For more details on fingerprinting bugs and enhancements, see the <a class="ulink" href="https://trac.torproject.org/projects/tor/query?keywords=~tbb-fingerprinting&amp;status=!closed" target="_top">tbb-fingerprinting tag in our bug tracker</a>
1359 1374
   </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="new-identity"></a>4.7. Long-Term Unlinkability via "New Identity" button</h3></div></div></div><p>
1360 1375
 
1361 1376
 In order to avoid long-term linkability, we provide a "New Identity" context
1362 1377
 menu option in Torbutton. This context menu option is active if Torbutton can
1363 1378
 read the environment variables $TOR_CONTROL_PASSWD and $TOR_CONTROL_PORT.
1364 1379
 
1365
-   </p><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp39106608"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote">
1380
+   </p><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp60545136"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote">
1366 1381
 
1367 1382
 All linkable identifiers and browser state MUST be cleared by this feature.
1368 1383
 
1369
-    </blockquote></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp39107856"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p>
1384
+    </blockquote></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp60546384"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p>
1370 1385
 
1371 1386
 First, Torbutton disables Javascript in all open tabs and windows by using
1372 1387
 both the <a class="ulink" href="https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIDocShell#Attributes" target="_top">browser.docShell.allowJavascript</a>
... ...
@@ -1383,10 +1398,10 @@ After closing all tabs, we then emit "<a class="ulink" href="https://developer.m
1383 1398
 (which instructs addons and various Firefox components to clear their session
1384 1399
 state), and then manually clear the following state: searchbox and findbox
1385 1400
 text, HTTP auth, SSL state, OCSP state, site-specific content preferences
1386
-(including HSTS state), content and image cache, offline cache, Cookies, DOM
1387
-storage, crypto tokens, DOM local storage, the safe browsing key, and the
1401
+(including HSTS state), content and image cache, offline cache, offline
1402
+storage, Cookies, crypto tokens, DOM storage, the safe browsing key, and the
1388 1403
 Google wifi geolocation token (if it exists). We also clear NoScript's site
1389
-and temporary permissions.
1404
+and temporary permissions, and all other browser site permissions.
1390 1405
 
1391 1406
      </p><p>
1392 1407
 
... ...
@@ -1405,13 +1420,48 @@ In addition to the above mechanisms that are devoted to preserving privacy
1405 1420
 while browsing, we also have a number of technical mechanisms to address other
1406 1421
 privacy and security issues.
1407 1422
 
1408
-   </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><a id="traffic-fingerprinting-defenses"></a><span class="command"><strong>Website Traffic Fingerprinting Defenses</strong></span><p>
1423
+   </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><a id="security-slider"></a><span class="command"><strong>Security Slider</strong></span><p>
1424
+
1425
+In order to provide vulnerability surface reduction for users that need high
1426
+security, we have implemented a "Security Slider" that essentially represents a
1427
+tradeoff between usability and security. Using metrics collected from
1428
+Mozilla's bug tracker, we analyzed the vulnerability counts of core components,
1429
+and used <a class="ulink" href="https://github.com/iSECPartners/publications/tree/master/reports/Tor%20Browser%20Bundle" target="_top">information
1430
+gathered from a study performed by iSec Partners</a> to inform which
1431
+features should be disabled at which security levels.
1432
+
1433
+     </p><p>
1434
+
1435
+The Security Slider consists of four positions. At the lowest security level
1436
+(the default), we disable
1437
+<span class="command"><strong>gfx.font_rendering.graphite.enabled</strong></span> for Latin locales, as
1438
+well as <span class="command"><strong>gfx.font_rendering.graphite.enabled</strong></span>. At the
1439
+medium-low level, we disable most Javascript JIT and related optimizations
1440
+(<span class="command"><strong>javascript.options.ion.content</strong></span>,
1441
+<span class="command"><strong>javascript.options.typeinference</strong></span>,
1442
+<span class="command"><strong>javascript.options.asmjs</strong></span>). We also make HTML5 media
1443
+click-to-play (<span class="command"><strong>noscript.forbidMedia</strong></span>), and disable WebAudio
1444
+(<span class="command"><strong>media.webaudio.enabled</strong></span>). At the medium-high level, we
1445
+disable the baseline JIT
1446
+(<span class="command"><strong>javascript.options.baselinejit.content</strong></span>), disable
1447
+Javascript entirely all elements that are loaded when the URL bar is not
1448
+HTTPS (<span class="command"><strong>noscript.globalHttpsWhitelist</strong></span>), and fully disable
1449
+graphite font rendering for all locales
1450
+(<span class="command"><strong>gfx.font_rendering.graphite.enable</strong></span>). At the highest level,
1451
+Javascript is fully disabled (<span class="command"><strong>noscript.global</strong></span>), as well as
1452
+all non-WebM HTML5 codecs (<span class="command"><strong>media.ogg.enabled</strong></span>,
1453
+<span class="command"><strong>media.opus.enabled</strong></span>, <span class="command"><strong>media.opus.enabled</strong></span>,
1454
+<span class="command"><strong>media.DirectShow.enabled</strong></span>,
1455
+<span class="command"><strong>media.wave.enabled</strong></span>, and
1456
+<span class="command"><strong>media.apple.mp3.enabled</strong></span>).
1457
+
1458
+     </p></li><li class="listitem"><a id="traffic-fingerprinting-defenses"></a><span class="command"><strong>Website Traffic Fingerprinting Defenses</strong></span><p>
1409 1459
 
1410 1460
 <a class="link" href="#website-traffic-fingerprinting">Website Traffic
1411 1461
 Fingerprinting</a> is a statistical attack to attempt to recognize specific
1412 1462
 encrypted website activity.
1413 1463
 
1414
-     </p><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp39122096"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p>
1464
+     </p><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp60574784"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p>
1415 1465
 
1416 1466
 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
1417 1467
 for classification. This mechanism would either impact the true and false
... ...
@@ -1433,8 +1483,8 @@ Congestion-Sensitive BUFLO</a>. It may be also possible to <a class="ulink" href
1433 1483
 defenses</a> such that they only use existing spare Guard bandwidth capacity in the Tor
1434 1484
 network, making them also effectively no-overhead.
1435 1485
 
1436
-     </p></blockquote></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp39128912"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p>
1437
-Currently, we patch Firefox to <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0017-Randomize-HTTP-request-order-and-pipeline-depth.patch" target="_top">randomize
1486
+     </p></blockquote></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp60581680"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p>
1487
+Currently, we patch Firefox to <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/27ef32d509ed1c9eeb28f7affee0f9ba11773f72" target="_top">randomize
1438 1488
 pipeline order and depth</a>. Unfortunately, pipelining is very fragile.
1439 1489
 Many sites do not support it, and even sites that advertise support for
1440 1490
 pipelining may simply return error codes for successive requests, effectively
... ...
@@ -1483,6 +1533,12 @@ homepage to point to a <a class="ulink" href="https://check.torproject.org/?lang
1483 1533
 informs the user</a> that their browser is out of
1484 1534
 date.
1485 1535
 
1536
+     </p><p>
1537
+
1538
+We also make use of the in-browser Mozilla updater, and have <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/777695d09e3cff4c79c48839e1c9d5102b772d6f" target="_top">patched
1539
+the updater</a> to avoid sending OS and Kernel version information as part
1540
+of its update pings.
1541
+
1486 1542
      </p></li></ol></div></div></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="BuildSecurity"></a>5. Build Security and Package Integrity</h2></div></div></div><p>
1487 1543
 
1488 1544
 In the age of state-sponsored malware, <a class="ulink" href="https://blog.torproject.org/blog/deterministic-builds-part-one-cyberwar-and-global-compromise" target="_top">we
... ...
@@ -1492,7 +1548,7 @@ contend with. For this reason, we have deployed a build system
1492 1548
 that allows anyone to use our source code to reproduce byte-for-byte identical
1493 1549
 binary packages to the ones that we distribute.
1494 1550
 
1495
-  </p><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idp39143984"></a>5.1. Achieving Binary Reproducibility</h3></div></div></div><p>
1551
+  </p><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idp60597904"></a>5.1. Achieving Binary Reproducibility</h3></div></div></div><p>
1496 1552
 
1497 1553
 The GNU toolchain has been working on providing reproducible builds for some
1498 1554
 time, however a large software project such as Firefox typically ends up
... ...
@@ -1516,7 +1572,7 @@ authentication, as well as transfer intermediate build outputs between the
1516 1572
 stages of the build process. Because Gitian creates an Ubuntu build
1517 1573
 environment, we must use cross-compilation to create packages for Windows and
1518 1574
 Mac OS. For Windows, we use mingw-w64 as our cross compiler. For Mac OS, we
1519
-use toolchain4 in combination with a binary redistribution of the Mac OS 10.6
1575
+use crosstools-ng in combination with a binary redistribution of the Mac OS 10.6
1520 1576
 SDK.
1521 1577
 
1522 1578
    </p><p>
... ...
@@ -1561,19 +1617,10 @@ patch</a>.
1561 1617
 
1562 1618
 The standard way of controlling timestamps in Gitian is to use libfaketime,
1563 1619
 which hooks time-related library calls to provide a fixed timestamp. However,
1564
-libfaketime does not spoof the millisecond and microsecond components of
1565
-timestamps, which found their way into pyc files and also in explicit Firefox
1566
-build process timestamp embedding.
1567
-    </p><p>
1568
-
1569
-We addressed the Firefox issues with direct patches to their build process,
1570
-which have since been merged. However, pyc timestamps had to be address with 
1571
-an additional <a class="ulink" href="https://gitweb.torproject.org/builders/tor-browser-bundle.git/blob/HEAD:/gitian/build-helpers/pyc-timestamp.sh" target="_top">helper
1572
-script</a>.
1573
-    </p><p>
1574
-
1575
-The timezone leaks were addressed by setting the <span class="command"><strong>TZ</strong></span>
1576
-environment variable to UTC in our descriptors.
1620
+due to our use of wine to run py2exe for python-based pluggable transports,
1621
+pyc timestamps had to be address with an additional <a class="ulink" href="https://gitweb.torproject.org/builders/tor-browser-bundle.git/blob/HEAD:/gitian/build-helpers/pyc-timestamp.sh" target="_top">helper
1622
+script</a>. The timezone leaks were addressed by setting the
1623
+<span class="command"><strong>TZ</strong></span> environment variable to UTC in our descriptors.
1577 1624
 
1578 1625
     </p></li><li class="listitem">Deliberately generated entropy
1579 1626
     <p>
... ...
@@ -1610,11 +1657,18 @@ hostname and Linux kernel version can leak from the host OS into the LXC
1610 1657
 container. We addressed umask by setting it explicitly in our Gitian
1611 1658
 descriptor scriptlet, and addressed the hostname and kernel version leaks by
1612 1659
 directly patching the aspects of the Firefox build process that included this
1613
-information into the build.
1614
-   </p></li></ol></div></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idp39178848"></a>5.2. Package Signatures and Verification</h3></div></div></div><p>
1660
+information into the build. It also turns out that some libraries (in
1661
+particular: libgmp) attempt to detect the current CPU to determine which
1662
+optimizations to compile in. This CPU type is uniform on our KVM instances,
1663
+but differs under LXC. We are also investigating currently <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/12239" target="_top">unknown sources of
1664
+unitialized memory</a> that only appear in LXC mode, as well as
1665
+<a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/12240" target="_top">oddities related to
1666
+time-based dependency tracking</a> that only appear in LXC containers.
1667
+
1668
+   </p></li></ol></div></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idp60632800"></a>5.2. Package Signatures and Verification</h3></div></div></div><p>
1615 1669
 
1616 1670
 The build process produces a single sha256sums.txt file that contains a sorted
1617
-list the SHA-256 hashes of every package produced for that build version. Each
1671
+list of the SHA-256 hashes of every package produced for that build version. Each
1618 1672
 official builder uploads this file and a GPG signature of it to a directory
1619 1673
 on a Tor Project's web server. The build scripts have an optional matching
1620 1674
 step that downloads these signatures, verifies them, and ensures that the
... ...
@@ -1645,7 +1699,7 @@ and by their nature are based on non-public key material, providing native
1645 1699
 code-signed packages while still preserving ease of reproducibility
1646 1700
 verification has not yet been achieved.
1647 1701
 
1648
-    </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idp39182784"></a>5.3. Anonymous Verification</h3></div></div></div><p>
1702
+    </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idp60636736"></a>5.3. Anonymous Verification</h3></div></div></div><p>
1649 1703
 
1650 1704
 Due to the fact that bit-identical packages can be produced by anyone, the
1651 1705
 security of this build system extends beyond the security of the official
... ...
@@ -1661,7 +1715,7 @@ privately download our source code, verify it against public signed, audited,
1661 1715
 and mirrored git repositories, and reproduce our builds exactly, without being
1662 1716
 subject to targeted attacks. If they notice any differences, they can alert
1663 1717
 the public builders/signers, hopefully using a pseudonym or our anonymous
1664
-bugtracker account, to avoid revealing the fact that they are a build
1718
+bug tracker account, to avoid revealing the fact that they are a build
1665 1719
 verifier.
1666 1720
 
1667 1721
    </p></div></div><div class="appendix"><h2 class="title" style="clear: both"><a id="Transparency"></a>A. Towards Transparency in Navigation Tracking</h2><p>
... ...
@@ -1717,14 +1771,16 @@ source URL parameters.
1717 1771
 
1718 1772
   </p><p>
1719 1773
 
1720
-We believe the Referer header should be made explicit. If a site wishes to
1721
-transmit its URL to third party content elements during load or during
1722
-link-click, it should have to specify this as a property of the associated HTML
1723
-tag. With an explicit property, it would then be possible for the user agent to
1724
-inform the user if they are about to click on a link that will transmit Referer
1725
-information (perhaps through something as subtle as a different color in the
1726
-lower toolbar for the destination URL). This same UI notification can also be
1727
-used for links with the <a class="ulink" href="https://developer.mozilla.org/en-US/docs/HTML/Element/a#Attributes" target="_top">"ping"</a>
1774
+We believe the Referer header should be made explicit, and believe that CSP
1775
+2.0 provides a <a class="ulink" href="http://www.w3.org/TR/CSP11/#directive-referrer" target="_top">decent step in this
1776
+direction</a>. If a site wishes to transmit its URL to third party content
1777
+elements during load or during link-click, it should have to specify this as a
1778
+property of the associated HTML tag or CSP policy. With an explicit property
1779
+or policy, it would then be possible for the user agent to inform the user if
1780
+they are about to click on a link that will transmit Referer information
1781
+(perhaps through something as subtle as a different color in the lower toolbar
1782
+for the destination URL). This same UI notification can also be used for links
1783
+with the <a class="ulink" href="https://developer.mozilla.org/en-US/docs/HTML/Element/a#Attributes" target="_top">"ping"</a>
1728 1784
 attribute.
1729 1785
 
1730 1786
   </p></li><li class="listitem">window.name
... ...
@@ -1759,7 +1815,7 @@ possible for us to <a class="ulink" href="https://trac.torproject.org/projects/t
1759 1815
 ourselves</a>, as they are comparatively rare and can be handled with site
1760 1816
 permissions.
1761 1817
 
1762
-   </p></li></ol></div></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="idp39214016"></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>
1818
+   </p></li></ol></div></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="idp60669376"></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>
1763 1819
 
1764 1820
 Web-Send is a browser-based link sharing and federated login widget that is
1765 1821
 designed to operate without relying on third-party tracking or abusing other