@@ -1,32 +1,32 @@

 <define-tag version-stable whitespace=delete>0.2.9.10</define-tag>

 <define-tag version-alpha whitespace=delete>0.3.0.4-rc</define-tag>

-<define-tag version-win32-stable whitespace=delete>0.2.9.9</define-tag>

+<define-tag version-win32-stable whitespace=delete>0.2.9.10</define-tag>

 <define-tag version-torbrowserdevelopbranch whitespace=delete>maint-6.5</define-tag>

-<define-tag version-torbrowserbundledir whitespace=delete>6.5</define-tag>

-<define-tag version-torbrowserbundlebetadir whitespace=delete>7.0a1</define-tag>

-

-<define-tag version-torbrowserbundle whitespace=delete>6.5</define-tag>

-<define-tag releasedate-torbrowserbundle whitespace=delete>2017-01-24</define-tag>

-<define-tag version-torbrowserbundlebeta whitespace=delete>7.0a1</define-tag>

-<define-tag releasedate-torbrowserbundlebeta whitespace=delete>2017-01-25</define-tag>

-

-<define-tag version-torbrowserbundlelinux32 whitespace=delete>6.5</define-tag>

-<define-tag releasedate-torbrowserbundlelinux32 whitespace=delete>2017-01-24</define-tag>

-<define-tag version-torbrowserbundlelinux64 whitespace=delete>6.5</define-tag>

-<define-tag releasedate-torbrowserbundlelinux64 whitespace=delete>2017-01-24</define-tag>

-<define-tag version-torbrowserbundlelinux32beta whitespace=delete>7.0a1</define-tag>

-<define-tag releasedate-torbrowserbundlelinux32beta whitespace=delete>2017-01-25</define-tag>

-<define-tag version-torbrowserbundlelinux64beta whitespace=delete>7.0a1</define-tag>

-<define-tag releasedate-torbrowserbundlelinux64beta whitespace=delete>2017-01-25</define-tag>

-

-<define-tag version-torbrowserbundleosx32 whitespace=delete>6.5</define-tag>

-<define-tag releasedate-torbrowserbundleosx32 whitespace=delete>2017-01-24</define-tag>

-<define-tag version-torbrowserbundleosx64 whitespace=delete>6.5</define-tag>

-<define-tag releasedate-torbrowserbundleosx64 whitespace=delete>2017-01-24</define-tag>

-<define-tag version-torbrowserbundleosx64beta whitespace=delete>7.0a1</define-tag>

-<define-tag releasedate-torbrowserbundleosx64beta whitespace=delete>2017-01-25</define-tag>

+<define-tag version-torbrowserbundledir whitespace=delete>6.5.1</define-tag>

+<define-tag version-torbrowserbundlebetadir whitespace=delete>7.0a2</define-tag>

+

+<define-tag version-torbrowserbundle whitespace=delete>6.5.1</define-tag>

+<define-tag releasedate-torbrowserbundle whitespace=delete>2017-03-07</define-tag>

+<define-tag version-torbrowserbundlebeta whitespace=delete>7.0a2</define-tag>

+<define-tag releasedate-torbrowserbundlebeta whitespace=delete>2017-03-08</define-tag>

+

+<define-tag version-torbrowserbundlelinux32 whitespace=delete>6.5.1</define-tag>

+<define-tag releasedate-torbrowserbundlelinux32 whitespace=delete>2017-03-07</define-tag>

+<define-tag version-torbrowserbundlelinux64 whitespace=delete>6.5.1</define-tag>

+<define-tag releasedate-torbrowserbundlelinux64 whitespace=delete>2017-03-07</define-tag>

+<define-tag version-torbrowserbundlelinux32beta whitespace=delete>7.0a2</define-tag>

+<define-tag releasedate-torbrowserbundlelinux32beta whitespace=delete>2017-03-08</define-tag>

+<define-tag version-torbrowserbundlelinux64beta whitespace=delete>7.0a2</define-tag>

+<define-tag releasedate-torbrowserbundlelinux64beta whitespace=delete>2017-03-08</define-tag>

+

+<define-tag version-torbrowserbundleosx32 whitespace=delete>6.5.1</define-tag>

+<define-tag releasedate-torbrowserbundleosx32 whitespace=delete>2017-03-07</define-tag>

+<define-tag version-torbrowserbundleosx64 whitespace=delete>6.5.1</define-tag>

+<define-tag releasedate-torbrowserbundleosx64 whitespace=delete>2017-03-07</define-tag>

+<define-tag version-torbrowserbundleosx64beta whitespace=delete>7.0a2</define-tag>

+<define-tag releasedate-torbrowserbundleosx64beta whitespace=delete>2017-03-08</define-tag>

 <define-tag version-torbrowsersandboxlinux whitespace=delete>0.0.3</define-tag>

 <define-tag package-win32-stable whitespace=delete>../dist/torbrowser/<version-torbrowserbundledir>/tor-win32-<version-win32-stable>.zip</define-tag>

@@ -1,12 +1,12 @@

 [

-"6.5",

-"6.5-Linux",

-"6.5-MacOS",

-"6.5-Windows",

-"7.0a1",

-"7.0a1-Linux",

-"7.0a1-MacOS",

-"7.0a1-Windows",

-"7.0a1-hardened",

-"7.0a1-hardened-Linux"

+"6.5.1",

+"6.5.1-Linux",

+"6.5.1-MacOS",

+"6.5.1-Windows",

+"7.0a2",

+"7.0a2-Linux",

+"7.0a2-MacOS",

+"7.0a2-Windows",

+"7.0a2-hardened",

+"7.0a2-hardened-Linux"

 ]

@@ -1,9 +1,9 @@

 <?xml version="1.0" encoding="UTF-8"?>

-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>The Design and Implementation of the Tor Browser [DRAFT]</title><meta name="generator" content="DocBook XSL Stylesheets V1.78.1" /></head><body><div class="article"><div class="titlepage"><div><div><h2 class="title"><a id="design"></a>The Design and Implementation of the Tor Browser [DRAFT]</h2></div><div><div class="author"><h3 class="author"><span class="firstname">Mike</span> <span class="surname">Perry</span></h3><div class="affiliation"><div class="address"><p><code class="email">&lt;<a class="email" href="mailto:mikeperry#torproject org">mikeperry#torproject org</a>&gt;</code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Erinn</span> <span class="surname">Clark</span></h3><div class="affiliation"><div class="address"><p><code class="email">&lt;<a class="email" href="mailto:erinn#torproject org">erinn#torproject org</a>&gt;</code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Steven</span> <span class="surname">Murdoch</span></h3><div class="affiliation"><div class="address"><p><code class="email">&lt;<a class="email" href="mailto:sjmurdoch#torproject org">sjmurdoch#torproject org</a>&gt;</code></p></div></div></div></div><div><p class="pubdate">May 6th, 2015</p></div></div><hr /></div><div class="toc"><p><strong>Table of Contents</strong></p><dl class="toc"><dt><span class="sect1"><a href="#idp53435264">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="#idp55327360">5.1. Achieving Binary Reproducibility</a></span></dt><dt><span class="sect2"><a href="#idp55349120">5.2. Package Signatures and Verification</a></span></dt><dt><span class="sect2"><a href="#idp55353648">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="#idp55389664">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="idp53435264"></a>1. Introduction</h2></div></div></div><p>

+<!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>

 This document describes the <a class="link" href="#adversary" title="3. Adversary Model">adversary model</a>,

 <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

-4.5.

+6.5.1.

   </p><p>

@@ -25,7 +25,7 @@ Support Release (ESR) Firefox branch</a>. We have a <a class="ulink" href="https

 against this browser to enhance privacy and security. Browser behavior is

 additionally augmented through the <a class="ulink" href="https://gitweb.torproject.org/torbutton.git/tree/" target="_top">Torbutton

 extension</a>, though we are in the process of moving this functionality

-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-31.6.0esr-4.5-1" target="_top">change

+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

 a number of Firefox preferences</a> from their defaults.

    </p><p>

@@ -38,30 +38,31 @@ Instantbird, and XULRunner.

 To help protect against potential Tor Exit Node eavesdroppers, we include

 <a class="ulink" href="https://www.eff.org/https-everywhere" target="_top">HTTPS-Everywhere</a>. To

-provide users with optional defense-in-depth against Javascript and other

-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

+provide users with optional defense-in-depth against JavaScript and other

+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

 extension preferences</a> from their defaults.

    </p><p>

 To provide censorship circumvention in areas where the public Tor network is

 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

-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">Obfs4proxy</a>,

+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,

+Obfs4proxy, Scramblesuit</a>,

 <a class="ulink" href="https://trac.torproject.org/projects/tor/wiki/doc/meek" target="_top">meek</a>,

-<a class="ulink" href="https://fteproxy.org/" target="_top">FTE</a>, and <a class="ulink" href="https://crypto.stanford.edu/flashproxy/" target="_top">FlashProxy</a>.

+and <a class="ulink" href="https://fteproxy.org/" target="_top">FTE</a>.

    </p></div></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="DesignRequirements"></a>2. Design Requirements and Philosophy</h2></div></div></div><p>

 The Tor Browser Design Requirements are meant to describe the properties of a

 Private Browsing Mode that defends against both network and local forensic

-adversaries. 

+adversaries.

   </p><p>

 There are two main categories of requirements: <a class="link" href="#security" title="2.1. Security Requirements">Security Requirements</a>, and <a class="link" href="#privacy" title="2.2. Privacy Requirements">Privacy Requirements</a>. Security Requirements are the

 minimum properties in order for a browser to be able to support Tor and

 similar privacy proxies safely. Privacy requirements are the set of properties

-that cause us to prefer one browser over another. 

+that cause us to prefer one browser over another.

   </p><p>

@@ -123,7 +124,7 @@ The privacy requirements are primarily concerned with reducing linkability:

 the ability for a user's activity on one site to be linked with their activity

 on another site without their knowledge or explicit consent. With respect to

 browser support, privacy requirements are the set of properties that cause us

-to prefer one browser over another. 

+to prefer one browser over another.

    </p><p>

@@ -181,7 +182,7 @@ User model breakage was one of the <a class="ulink" href="https://blog.torprojec

 of Torbutton</a>: Even if users managed to install everything properly,

 the toggle model was too hard for the average user to understand, especially

 in the face of accumulating tabs from multiple states crossed with the current

-Tor-state of the browser. 

+Tor-state of the browser.

       </p></li><li class="listitem"><span class="command"><strong>Favor the implementation mechanism least likely to

 break sites</strong></span><p>

@@ -221,14 +222,14 @@ system-wide and/or operating system provided addons or plugins.

 Instead of global browser privacy options, privacy decisions should be made

 <a class="ulink" href="https://wiki.mozilla.org/Privacy/Features/Site-based_data_management_UI" target="_top">per

 URL bar origin</a> to eliminate the possibility of linkability

-between domains. For example, when a plugin object (or a Javascript access of

+between domains. For example, when a plugin object (or a JavaScript access of

 window.plugins) is present in a page, the user should be given the choice of

 allowing that plugin object for that URL bar origin only. The same

 goes for exemptions to third party cookie policy, geolocation, and any other

 privacy permissions.

      </p><p>

 If the user has indicated they wish to record local history storage, these

-permissions can be written to disk. Otherwise, they should remain memory-only. 

+permissions can be written to disk. Otherwise, they should remain memory-only.

      </p></li><li class="listitem"><span class="command"><strong>No filters</strong></span><p>

 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

@@ -239,11 +240,29 @@ avoided. We believe that these addons do not add any real privacy to a proper

 should be focused on general solutions that prevent tracking by all

 third parties, rather than a list of specific URLs or hosts.

      </p><p>

-Filter-based addons can also introduce strange breakage and cause usability

-nightmares, and will also fail to do their job if an adversary simply

-registers a new domain or creates a new URL path. Worse still, the unique

-filter sets that each user creates or installs will provide a wealth of

-fingerprinting targets.

+Implementing filter-based blocking directly into the browser, such as done with

+<a class="ulink" href="http://ieee-security.org/TC/SPW2015/W2SP/papers/W2SP_2015_submission_32.pdf" target="_top">

+Firefox' Tracking Protection</a>, does not alleviate the concerns mentioned

+in the previous paragraph. There is still just a list concerned with specific

+URLs and hosts which, in this case, are

+<a class="ulink" href="https://services.disconnect.me/disconnect-plaintext.json" target="_top">

+assembled</a> by <a class="ulink" href="https://disconnect.me/trackerprotection" target="_top">

+Disconnect</a> and <a class="ulink" href="https://github.com/mozilla-services/shavar-list-exceptions" target="_top">adapted</a> by Mozilla.

+     </p><p>

+Trying to resort to <a class="ulink" href="https://jonathanmayer.org/papers_data/bau13.pdf" target="_top">filter methods based on

+machine learning</a> does not solve the problem either: they don't provide

+a general solution to the tracking problem as they are working probabilistically.

+Even with a precision rate at 99% and a false positive rate at 0.1% trackers

+would be missed and sites would be wrongly blocked.

+     </p><p>

+Filter-based solutions in general can also introduce strange breakage and cause

+usability nightmares. Coping with those easily leads to just <a class="ulink" href="https://github.com/mozilla-services/shavar-list-exceptions" target="_top">whitelisting

+</a>

+the affected domains defeating the purpose of the filter in the first place.

+Filters will also fail to do their job if an adversary simply

+registers a new domain or <a class="ulink" href="http://ieee-security.org/TC/SPW2015/W2SP/papers/W2SP_2015_submission_24.pdf" target="_top">

+creates a new URL path</a>. Worse still, the unique filter sets that each

+user creates or installs will provide a wealth of fingerprinting targets.

       </p><p>

 As a general matter, we are also generally opposed to shipping an always-on Ad

@@ -266,12 +285,12 @@ A Tor web browser adversary has a number of goals, capabilities, and attack

 types that can be used to illustrate the design requirements for the

 Tor Browser. Let's start with the goals.

-   </p><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="adversary-goals"></a>3.1. Adversary Goals</h3></div></div></div><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><span class="command"><strong>Bypassing proxy settings</strong></span><p>The adversary's primary goal is direct compromise and bypass of 

+   </p><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="adversary-goals"></a>3.1. Adversary Goals</h3></div></div></div><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><span class="command"><strong>Bypassing proxy settings</strong></span><p>The adversary's primary goal is direct compromise and bypass of

 Tor, causing the user to directly connect to an IP of the adversary's

 choosing.</p></li><li class="listitem"><span class="command"><strong>Correlation of Tor vs Non-Tor Activity</strong></span><p>If direct proxy bypass is not possible, the adversary will likely

 happily settle for the ability to correlate something a user did via Tor with

 their non-Tor activity. This can be done with cookies, cache identifiers,

-Javascript events, and even CSS. Sometimes the fact that a user uses Tor may

+JavaScript events, and even CSS. Sometimes the fact that a user uses Tor may

 be enough for some authorities.</p></li><li class="listitem"><span class="command"><strong>History disclosure</strong></span><p>

 The adversary may also be interested in history disclosure: the ability to

 query a user's history to see if they have issued certain censored search

@@ -287,7 +306,7 @@ attempt to perform this correlation without the user's explicit consent.

 Fingerprinting (more generally: "anonymity set reduction") is used to attempt

 to gather identifying information on a particular individual without the use

-of tracking identifiers. If the dissident or whistleblower's timezone is

+of tracking identifiers. If the dissident's or whistleblower's timezone is

 available, and they are using a rare build of Firefox for an obscure operating

 system, and they have a specific display resolution only used on one type of

 laptop, this can be very useful information for tracking them down, or at

@@ -314,7 +333,7 @@ wild.

 The adversary can also run websites, or more likely, they can contract out

 ad space from a number of different ad servers and inject content that way. For

 some users, the adversary may be the ad servers themselves. It is not

-inconceivable that ad servers may try to subvert or reduce a user's anonymity 

+inconceivable that ad servers may try to subvert or reduce a user's anonymity

 through Tor for marketing purposes.

      </p></li><li class="listitem"><span class="command"><strong>Local Network/ISP/Upstream Router</strong></span><p>

 The adversary can also inject malicious content at the user's upstream router

@@ -324,7 +343,7 @@ activity.

 Additionally, at this position the adversary can block Tor, or attempt to

 recognize the traffic patterns of specific web pages at the entrance to the Tor

-network. 

+network.

      </p></li><li class="listitem"><span class="command"><strong>Physical Access</strong></span><p>

 Some users face adversaries with intermittent or constant physical access.

@@ -334,10 +353,10 @@ confiscation of their computer equipment for excessive Tor usage or just

 general suspicion.

      </p></li></ol></div></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="attacks"></a>3.3. Adversary Capabilities - Attacks</h3></div></div></div><p>

-The adversary can perform the following attacks from a number of different 

+The adversary can perform the following attacks from a number of different

 positions to accomplish various aspects of their goals. It should be noted

 that many of these attacks (especially those involving IP address leakage) are

-often performed by accident by websites that simply have Javascript, dynamic 

+often performed by accident by websites that simply have JavaScript, dynamic

 CSS elements, and plugins. Others are performed by ad servers seeking to

 correlate users' activity across different IP addresses, and still others are

 performed by malicious agents on the Tor network and at national firewalls.

@@ -367,22 +386,21 @@ These types of attacks are attempts at subverting our <a class="link" href="#ide

 attributes</strong></span><p>

 There is an absurd amount of information available to websites via attributes

-of the browser. This information can be used to reduce anonymity set, or even

-uniquely fingerprint individual users. Attacks of this nature are typically

-aimed at tracking users across sites without their consent, in an attempt to

-subvert our <a class="link" href="#fingerprinting-linkability" title="4.6. Cross-Origin Fingerprinting Unlinkability">Cross-Origin

+of the browser. This information can be used to reduce the anonymity set, or

+even uniquely fingerprint individual users. Attacks of this nature are

+typically aimed at tracking users across sites without their consent, in an

+attempt to subvert our <a class="link" href="#fingerprinting-linkability" title="4.6. Cross-Origin Fingerprinting Unlinkability">Cross-Origin

 Fingerprinting Unlinkability</a> and <a class="link" href="#new-identity" title="4.7. Long-Term Unlinkability via &quot;New Identity&quot; button">Long-Term Unlinkability</a> design requirements.

 </p><p>

-Fingerprinting is an intimidating

-problem to attempt to tackle, especially without a metric to determine or at

-least intuitively understand and estimate which features will most contribute

-to linkability between visits.

+Fingerprinting is an intimidating problem to attempt to tackle, especially

+without a metric to determine or at least intuitively understand and estimate

+which features will most contribute to linkability between visits.

 </p><p>

-The <a class="ulink" href="https://panopticlick.eff.org/about.php" target="_top">Panopticlick study

+The <a class="ulink" href="https://panopticlick.eff.org/about" target="_top">Panopticlick study

 done</a> by the EFF uses the <a class="ulink" href="https://en.wikipedia.org/wiki/Entropy_%28information_theory%29" target="_top">Shannon

 entropy</a> - the number of identifying bits of information encoded in

 browser properties - as this metric. Their <a class="ulink" href="https://wiki.mozilla.org/Fingerprinting#Data" target="_top">result data</a> is

@@ -409,20 +427,25 @@ usage, and request ordering. Additionally, the use of custom filters such as

 AdBlock and other privacy filters can be used to fingerprint request patterns

 (as an extreme example).

-     </p></li><li class="listitem"><span class="command"><strong>Inserting Javascript</strong></span><p>

+     </p></li><li class="listitem"><span class="command"><strong>Inserting JavaScript</strong></span><p>

-Javascript can reveal a lot of fingerprinting information. It provides DOM

+JavaScript can reveal a lot of fingerprinting information. It provides DOM

 objects such as window.screen and window.navigator to extract information

-about the user agent. 

+about the user agent.

-Also, Javascript can be used to query the user's timezone via the

+Also, JavaScript can be used to query the user's timezone via the

 <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

 reveal information about the video card in use, and high precision timing

 information can be used to <a class="ulink" href="http://w2spconf.com/2011/papers/jspriv.pdf" target="_top">fingerprint the CPU and

-interpreter speed</a>. In the future, new JavaScript features such as

-<a class="ulink" href="http://w3c-test.org/webperf/specs/ResourceTiming/" target="_top">Resource

-Timing</a> may leak an unknown amount of network timing related

-information.

+interpreter speed</a>. JavaScript features such as

+<a class="ulink" href="https://www.w3.org/TR/resource-timing/" target="_top">Resource Timing</a>

+may leak an unknown amount of network timing related information. And, moreover,

+JavaScript is able to

+<a class="ulink" href="https://seclab.cs.ucsb.edu/media/uploads/papers/sp2013_cookieless.pdf" target="_top">

+extract</a>

+<a class="ulink" href="https://www.cosic.esat.kuleuven.be/fpdetective/" target="_top">available</a>

+<a class="ulink" href="https://hal.inria.fr/hal-01285470v2/document" target="_top">fonts</a> on a

+device with high precision.

      </p></li><li class="listitem"><span class="command"><strong>Inserting Plugins</strong></span><p>

@@ -435,7 +458,7 @@ store unique identifiers that are more difficult to clear than standard

 cookies.  <a class="ulink" href="http://epic.org/privacy/cookies/flash.html" target="_top">Flash-based

 cookies</a> fall into this category, but there are likely numerous other

 examples. Beyond fingerprinting, plugins are also abysmal at obeying the proxy

-settings of the browser. 

+settings of the browser.

      </p></li><li class="listitem"><span class="command"><strong>Inserting CSS</strong></span><p>

@@ -443,7 +466,7 @@ settings of the browser.

 <a class="ulink" href="https://developer.mozilla.org/En/CSS/Media_queries" target="_top">CSS media

 queries</a> can be inserted to gather information about the desktop size,

 widget size, display type, DPI, user agent type, and other information that

-was formerly available only to Javascript.

+was formerly available only to JavaScript.

      </p></li></ol></div></li><li class="listitem"><a id="website-traffic-fingerprinting"></a><span class="command"><strong>Website traffic fingerprinting</strong></span><p>

@@ -454,15 +477,16 @@ node itself.

      </p><p> The most comprehensive study of the statistical properties of this

 attack against Tor was done by <a class="ulink" href="http://lorre.uni.lu/~andriy/papers/acmccs-wpes11-fingerprinting.pdf" target="_top">Panchenko

 et al</a>. Unfortunately, the publication bias in academia has encouraged

-the production of a number of follow-on attack papers claiming "improved"

-success rates, in some cases even claiming to completely invalidate any

-attempt at defense. These "improvements" are actually enabled primarily by

-taking a number of shortcuts (such as classifying only very small numbers of

-web pages, neglecting to publish ROC curves or at least false positive rates,

-and/or omitting the effects of dataset size on their results). Despite these

-subsequent "improvements", we are skeptical of the efficacy of this attack in

-a real world scenario, <span class="emphasis"><em>especially</em></span> in the face of any

-defenses.

+the production of

+<a class="ulink" href="https://blog.torproject.org/blog/critique-website-traffic-fingerprinting-attacks" target="_top">a

+number of follow-on attack papers claiming "improved" success rates</a>, in

+some cases even claiming to completely invalidate any attempt at defense. These

+"improvements" are actually enabled primarily by taking a number of shortcuts

+(such as classifying only very small numbers of web pages, neglecting to publish

+ROC curves or at least false positive rates, and/or omitting the effects of

+dataset size on their results). Despite these subsequent "improvements", we are

+skeptical of the efficacy of this attack in a real world scenario,

+<span class="emphasis"><em>especially</em></span> in the face of any defenses.

      </p><p>

@@ -482,8 +506,8 @@ function of the complexity of the categories</a> you need to classify.

 In the case of this attack, the key factors that increase the classification

 complexity (and thus hinder a real world adversary who attempts this attack)

 are large numbers of dynamically generated pages, partially cached content,

-and also the non-web activity of entire Tor network. This yields an 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

+and also the non-web activity of the entire Tor network. This yields an

+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

 "Open World" scenario</a>, which suffered continuous near-constant decline

 in the true positive rate as the "Open World" size grew (see figure 4). This

 large level of classification complexity is further confounded by a noisy and

@@ -522,14 +546,14 @@ can perform similar actions.

 For the purposes of the browser itself, we limit the scope of this adversary

 to one that has passive forensic access to the disk after browsing activity

-has taken place. This adversary motivates our 

+has taken place. This adversary motivates our

 <a class="link" href="#disk-avoidance" title="4.3. Disk Avoidance">Disk Avoidance</a> defenses.

     </p><p>

 An adversary with arbitrary code execution typically has more power, though.

 It can be quite hard to really significantly limit the capabilities of such an

-adversary. <a class="ulink" href="http://tails.boum.org/contribute/design/" target="_top">The Tails system</a> can

+adversary. <a class="ulink" href="https://tails.boum.org/contribute/design/" target="_top">The Tails system</a> can

 provide some defense against this adversary through the use of readonly media

 and frequent reboots, but even this can be circumvented on machines without

 Secure Boot through the use of BIOS rootkits.

@@ -555,7 +579,7 @@ are typically linked for these cases.

 Proxy obedience is assured through the following:

    </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>

-Our <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/tree/browser/app/profile/000-tor-browser.js?h=tor-browser-31.6.0esr-4.5-1" target="_top">Firefox

+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

 preferences file</a> sets the Firefox proxy settings to use Tor directly

 as a SOCKS proxy. It sets <span class="command"><strong>network.proxy.socks_remote_dns</strong></span>,

 <span class="command"><strong>network.proxy.socks_version</strong></span>,

@@ -571,9 +595,11 @@ as set the pref <span class="command"><strong>media.peerconnection.enabled</stro

  </p><p>

 We also patch Firefox in order to provide several defense-in-depth mechanisms

-for proxy safety. Notably, we <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0esr-4.5-1&amp;id=8c6604d2b776f0d8e33ed9130c5f5b8cf744bac8" target="_top">patch

+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

 the DNS service</a> to prevent any browser or addon DNS resolution, and we

-also <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0esr-4.5-1&amp;id=c96c854c0eca21fed1362d1ddd164b657d351795" target="_top">patch

+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">

+remove the DNS lookup for the profile lock signature</a>. Furhermore, we

+<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

 OCSP and PKIX code</a> to prevent any use of the non-proxied command-line

 tool utility functions from being functional while linked in to the browser.

 In both cases, we could find no direct paths to these routines in the browser,

@@ -581,6 +607,36 @@ but it seemed better safe than sorry.

  </p><p>

+For further defense-in-depth we disabled WebIDE because it can bypass proxy

+settings for remote debugging, and also because it downloads extensions we

+have not reviewed. We

+are doing this by setting

+<span class="command"><strong>devtools.webide.autoinstallADBHelper</strong></span>,

+<span class="command"><strong>devtools.webide.autoinstallFxdtAdapters</strong></span>,

+<span class="command"><strong>devtools.webide.enabled</strong></span>, and

+<span class="command"><strong>devtools.appmanager.enabled</strong></span> to <span class="command"><strong>false</strong></span>.

+Moreover, we removed the Roku Screen Sharing and screencaster code 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= ad4abdb2e724fec060063f460604b829c66ea08a" target="_top">

+Firefox patch</a> as these features can bypass proxy settings as well.

+ </p><p>

+Shumway is removed, too, for possible proxy bypass risks. We did this by

+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">

+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">

+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>.

+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">

+disabled the network tickler</a> as it has the capability to send UDP

+traffic.

+ </p><p>

+

+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">

+disabled mDNS support</a>, since mDNS uses UDP packets. We also disable

+Mozilla's TCPSocket by setting

+<span class="command"><strong>dom.mozTCPSocket.enabled</strong></span> to <span class="command"><strong>false</strong></span>. We

+<a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/18866" target="_top">intend to

+rip out</a> the TCPSocket code in the future to have an even more solid

+guarantee that it won't be used by accident.

+

+ </p><p>

 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

 code audits</a> to verify that there were no system calls or XPCOM

 activity in the source tree that did not use the browser proxy settings.

@@ -590,12 +646,12 @@ We have verified that these settings and patches properly proxy HTTPS, OCSP,

 HTTP, FTP, gopher (now defunct), DNS, SafeBrowsing Queries, all JavaScript

 activity, including HTML5 audio and video objects, addon updates, WiFi

 geolocation queries, searchbox queries, XPCOM addon HTTPS/HTTP activity,

-WebSockets, and live bookmark updates. We have also verified that IPv6

-connections are not attempted, through the proxy or otherwise (Tor does not

-yet support IPv6). We have also verified that external protocol helpers, such

-as SMB URLs and other custom protocol handlers are all blocked.

-

- </p></li><li class="listitem"><span class="command"><strong>Disabling plugins</strong></span><p>Plugins have the ability to make arbitrary OS system calls and  bypass proxy settings. This includes

+WebSockets, and live bookmark updates. We have also verified that external

+protocol helpers, such as SMB URLs and other custom protocol handlers are all

+blocked.

+ </p></li><li class="listitem"><span class="command"><strong>Disabling plugins</strong></span><p>

+Plugins, like Flash, 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

 the ability to make UDP sockets and send arbitrary data independent of the

 browser proxy settings.

  </p><p>

@@ -611,10 +667,28 @@ restricted from automatic load through Firefox's click-to-play preference

 In addition, to reduce any unproxied activity by arbitrary plugins at load

 time, and to reduce the fingerprintability of the installed plugin list, we

-also patch the Firefox source code to <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0esr-4.5-1&amp;id=465cb8295db58a6450dc14a593d29372cbebc71d" target="_top">

+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">

 prevent the load of any plugins except for Flash and Gnash</a>. Even for

-Flash and Gnash, we also patch Firefox to <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0esr-4.5-1&amp;id=e5531b1baa3c96dee7d8d4274791ff393bafd241" target="_top">prevent loading them into the

-address space</a> until they are explicitly enabled.

+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">

+prevent loading them into the address space</a> until they are explicitly

+enabled.

+ </p><p>

+With <a class="ulink" href="https://wiki.mozilla.org/GeckoMediaPlugins" target="_top">Gecko Media

+Plugins</a> (GMPs) a second type of plugins is available. They are mainly

+third party codecs and <a class="ulink" href="https://www.w3.org/TR/encrypted-media/" target="_top">EME</a>

+content decryption modules. We currently disable these plugins as they either

+can't be built reproducibly or are binary blobs which we are not allowed to

+audit (or both). For the EME case we use the <span class="command"><strong>--disable-eme</strong></span>

+configure switch and set

+<span class="command"><strong>browser.eme.ui.enabled</strong></span>,

+<span class="command"><strong>media.gmp-eme-adobe.enabled</strong></span>,

+<span class="command"><strong>media.eme.enabled</strong></span>, and

+<span class="command"><strong>media.eme.apiVisible</strong></span> to <span class="command"><strong>false</strong></span> to indicate

+to the user that this feature is disabled. For GMPs in general we make sure that

+the external server is not even pinged for updates/downloads in the first place

+by setting <span class="command"><strong>media.gmp-manager.url.override</strong></span> to

+<span class="command"><strong>data:text/plain,</strong></span> and avoid any UI with <span class="command"><strong>

+media.gmp-provider.enabled</strong></span> set to <span class="command"><strong>false</strong></span>.

  </p></li><li class="listitem"><span class="command"><strong>External App Blocking and Drag Event Filtering</strong></span><p>

@@ -642,42 +716,39 @@ bypassing Tor. It is for this reason we disable the addon whitelist

 before installing addons regardless of the source. We also exclude

 system-level addons from the browser through the use of

 <span class="command"><strong>extensions.enabledScopes</strong></span> and

-<span class="command"><strong>extensions.autoDisableScopes</strong></span>.

+<span class="command"><strong>extensions.autoDisableScopes</strong></span>. Furthermore, we set

+<span class="command"><strong>extensions.systemAddon.update.url</strong></span> and <span class="command"><strong>

+extensions.hotfix.id</strong></span> to an empty string in order

+to avoid the risk of getting extensions installed by Mozilla into Tor Browser.

   </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>

 Tor Browser State is separated from existing browser state through use of a

 custom Firefox profile, and by setting the $HOME environment variable to the

-root of the bundle's directory.  The browser also does not load any

+root of the bundle's directory. The browser also does not load any

 system-wide extensions (through the use of

 <span class="command"><strong>extensions.enabledScopes</strong></span> and

 <span class="command"><strong>extensions.autoDisableScopes</strong></span>). Furthermore, plugins are

 disabled, which prevents Flash cookies from leaking from a pre-existing Flash

 directory.

-   </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="idp55029872"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote">

+   </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">

 The User Agent MUST (at user option) prevent all disk records of browser activity.

-The user should be able to optionally enable URL history and other history

-features if they so desire. 

-

-    </blockquote></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp55031232"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote">

-

-We achieve this goal through several mechanisms. First, we set the Firefox

-Private Browsing preference

-<span class="command"><strong>browser.privatebrowsing.autostart</strong></span>. In addition, four Firefox patches are needed to prevent disk writes, even if

-Private Browsing Mode is enabled. We need to

-

-<a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0esr-4.5-1&amp;id=44b8ae43a83191bbf5161cbdbf399e10c1b943d0" target="_top">prevent

-the permissions manager from recording HTTPS STS state</a>, <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0esr-4.5-1&amp;id=e5abcb28f131aa96e8762212573488d303b3614d" target="_top">prevent

-intermediate SSL certificates from being recorded</a>, <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0esr-4.5-1&amp;id=ee34e122ac2929a7668314483e36e58a88c98c08" target="_top">prevent

-the clipboard cache from being written to disk for large pastes</a>, and

-<a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0esr-4.5-1&amp;id=c8e357740dd7bafa2a129007f27d2b243e36f4a2" target="_top">prevent

-the content preferences service from recording site zoom</a>. 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.

-

+The user SHOULD be able to optionally enable URL history and other history

+features if they so desire.

+

+    </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">

+

+     We are working towards this goal through several mechanisms. First, we set

+     the Firefox Private Browsing preference

+     <span class="command"><strong>browser.privatebrowsing.autostart</strong></span>.

+     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.

+     Finally, we needed to disable asm.js as it turns out that

+     <a class="ulink" href="https://bugzilla.mozilla.org/show_bug.cgi?id=1047105" target="_top">asm.js

+     cache entries get written to disk</a> in private browsing mode. This

+     is done by setting <span class="command"><strong>javascript.options.asmjs</strong></span> to

+     <span class="command"><strong>false</strong></span> (for linkability concerns with asm.js see below).

     </blockquote></div><div class="blockquote"><blockquote class="blockquote">

 As an additional defense-in-depth measure, we set the following preferences:

@@ -699,18 +770,17 @@ auditing work to ensure that yet.

 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>

-Tor Browser Bundle MUST NOT cause any information to be written outside of the

-bundle directory. This is to ensure that the user is able to completely and

-safely remove the bundle without leaving other traces of Tor usage on their

-computer.

+Tor Browser MUST NOT cause any information to be written outside of the bundle

+directory. This is to ensure that the user is able to completely and

+safely remove it without leaving other traces of Tor usage on their computer.

    </p><p>

-To ensure TBB directory isolation, we set

+To ensure Tor Browser directory isolation, we set

 <span class="command"><strong>browser.download.useDownloadDir</strong></span>,

 <span class="command"><strong>browser.shell.checkDefaultBrowser</strong></span>, and

 <span class="command"><strong>browser.download.manager.addToRecentDocs</strong></span>. We also set the

-$HOME environment variable to be the TBB extraction directory.

+$HOME environment variable to be the Tor Browser extraction directory.

    </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="identifier-linkability"></a>4.5. Cross-Origin Identifier Unlinkability</h3></div></div></div><p>

 The Cross-Origin Identifier Unlinkability design requirement is satisfied

@@ -733,15 +803,15 @@ the URL bar origin for which browser state exists, possibly with a

 context-menu option to drill down into specific types of state or permissions.

 An example of this simplification can be seen in Figure 1.

-   </p><div class="figure"><a id="idp55052928"></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>

+   </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>

 This example UI is a mock-up of how isolating identifiers to the URL bar

-origin can simplify the privacy UI for all data - not just cookies. Once

+domain can simplify the privacy UI for all data - not just cookies. Once

 browser identifiers and site permissions operate on a URL bar basis, the same

 privacy window can represent browsing history, DOM Storage, HTTP Auth, search

 form history, login values, and so on within a context menu for each site.

-</div></div></div><br class="figure-break" /><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp55056352"></a>Identifier Unlinkability Defenses in the Tor Browser</h4></div></div></div><p>

+</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>

 Unfortunately, many aspects of browser state can serve as identifier storage,

 and no other browser vendor or standards body has invested the effort to

@@ -761,45 +831,61 @@ Firefox versions.

 As a stopgap to satisfy our design requirement of unlinkability, we currently

 entirely disable 3rd party cookies by setting

-<span class="command"><strong>network.cookie.cookieBehavior</strong></span> to 1. We would prefer that

-third party content continue to function, but we believe the requirement for 

-unlinkability trumps that desire.

+<span class="command"><strong>network.cookie.cookieBehavior</strong></span> to <span class="command"><strong>1</strong></span>. We

+would prefer that third party content continue to function, but we believe the

+requirement for unlinkability trumps that desire.

-     </p></li><li class="listitem"><span class="command"><strong>Cache</strong></span><p>

+     </p></li><li class="listitem"><span class="command"><strong>Cache</strong></span><p><span class="command"><strong>Design Goal:</strong></span>

+        All cache entries MUST be isolated to the URL bar domain.

+      </p><p><span class="command"><strong>Implementation Status:</strong></span>

-In Firefox, there are actually two distinct caching mechanisms: One for

-general content (HTML, Javascript, CSS), and one specifically for images. The

-content cache is isolated to the URL bar domain by <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0esr-4.5-1&amp;id=7c58be929777d386a03e1faaee648909151fd951" target="_top">altering

+In Firefox, there are actually several distinct caching mechanisms: One is for

+general content (HTML, JavaScript, CSS). That content cache is isolated to the

+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

 each cache key</a> to include an additional ID that includes the URL bar

 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

-entry. Each third party element should have an additional "id=string"

-property prepended, which will list the FQDN that was used to source it.

+entry. Each third party element should have an additional "string@:"

+property prepended, which will list the base domain that was used to source it.

      </p><p>

-Additionally, because the image cache is a separate entity from 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-31.6.0esr-4.5-1&amp;id=d8b98a75fb200268c40886d876adc19e00b933bf" target="_top">isolate

+Additionally, there is the image cache. Because it is a separate entity from

+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

 this cache per URL bar domain</a>.

+     </p><p>

+Furthermore there is the Cache API (CacheStorage). That one is currently not

+available in Tor Browser as we do not allow third party cookies and are in

+Private Browsing Mode by default.

+     </p><p>

+Finally, we have the asm.js cache. The cache entry of the sript is (among

+others things, like type of CPU, build ID, source characters of the asm.js

+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>.

+Lacking a good solution for binding it to the URL bar domain instead (and given

+the storage of asm.js modules in Private Browsing Mode) we decided to disable

+asm.js for the time being by setting <span class="command"><strong>javascript.options.asmjs</strong></span> to

+<span class="command"><strong>false</strong></span>. It remains to be seen whether keying the cache entry

+to the source characters of the asm.js module helps to avoid using it for

+cross-origin tracking of users. We did not investigate that yet.

      </p></li><li class="listitem"><span class="command"><strong>HTTP Authentication</strong></span><p>

 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

 third party tracking identifiers</a>. To prevent this, we remove HTTP

-authentication tokens for third party elements through a <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0esr-4.5-1&amp;id=b8ce4a0760759431f146c71184c89fbd5e1a27e4" target="_top">patch

+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

 to nsHTTPChannel</a>.

      </p></li><li class="listitem"><span class="command"><strong>DOM Storage</strong></span><p>

-DOM storage for third party domains MUST be isolated to the URL bar origin,

+DOM storage for third party domains MUST be isolated to the URL bar domain,

 to prevent linkability between sites. This functionality is provided through a

-<a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0esr-4.5-1&amp;id=97490c4a90ca1c43374486d9ec0c5593d5fe5720" target="_top">patch

+<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

 to Firefox</a>.

      </p></li><li class="listitem"><span class="command"><strong>Flash cookies</strong></span><p><span class="command"><strong>Design Goal:</strong></span>

 Users should be able to click-to-play flash objects from trusted sites. To

-make this behavior unlinkable, we wish to include a settings file for all 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

+make this behavior unlinkable, we wish to include a settings file for all

+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

 settings manager</a>.

      </p><p><span class="command"><strong>Implementation Status:</strong></span>

@@ -811,19 +897,19 @@ file on Windows, so Flash remains difficult to enable.

      </p></li><li class="listitem"><span class="command"><strong>SSL+TLS session resumption</strong></span><p><span class="command"><strong>Design Goal:</strong></span>

 TLS session resumption tickets and SSL Session IDs MUST be limited to the URL

-bar origin.

+bar domain.

      </p><p><span class="command"><strong>Implementation Status:</strong></span>

-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

-Identity</a>, we disable TLS Session Tickets via the Firefox Pref

-<span class="command"><strong>security.enable_tls_session_tickets</strong></span>. We disable SSL Session

-IDs via a <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0esr-4.5-1&amp;id=a01fb747d4b8b24687de538cb6a1304fe27d9d88" target="_top">patch

-to Firefox</a>. To compensate for the increased round trip latency from disabling

+We disable TLS Session Tickets and SSL Session IDs by

+setting <span class="command"><strong>security.ssl.disable_session_identifiers</strong></span> to

+<span class="command"><strong>true</strong></span>.

+To compensate for the increased round trip latency from disabling

 these performance optimizations, we also enable

 <a class="ulink" href="https://tools.ietf.org/html/draft-bmoeller-tls-falsestart-00" target="_top">TLS

 False Start</a> via the Firefox Pref

 <span class="command"><strong>security.ssl.enable_false_start</strong></span>.

+

     </p></li><li class="listitem"><span class="command"><strong>Tor circuit and HTTP connection linkability</strong></span><p>

 Tor circuits and HTTP connections from a third party in one URL bar origin

@@ -831,31 +917,31 @@ MUST NOT be reused for that same third party in another URL bar origin.

      </p><p>

-This isolation functionality is provided by the combination of a <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0esr-4.5-1&amp;id=b3ea705cc35b79a9ba27323cb3e32d5d004ea113" target="_top">Firefox

-patch to allow SOCKS usernames and passwords</a>, as well as a Torbutton

+This isolation functionality is provided by a Torbutton

 component that <a class="ulink" href="" target="_top">sets

 the SOCKS username and password for each request</a>. The Tor client has

 logic to prevent connections with different SOCKS usernames and passwords from

-using the same Tor circuit. Firefox has existing logic to ensure that connections with

-SOCKS proxies do not re-use existing HTTP Keep-Alive connections unless the

-proxy settings match.  We extended this logic to cover SOCKS username and

-password authentication, providing us with HTTP Keep-Alive unlinkability.

+using the same Tor circuit. Firefox has existing logic to ensure that

+connections with SOCKS proxies do not re-use existing HTTP Keep-Alive

+connections unless the proxy settings match.

+<a class="ulink" href="https://bugzilla.mozilla.org/show_bug.cgi?id=1200802" target="_top">We extended

+this logic</a> to cover SOCKS username and password authentication,

+providing us with HTTP Keep-Alive unlinkability.

      </p></li><li class="listitem"><span class="command"><strong>SharedWorkers</strong></span><p>

 <a class="ulink" href="https://developer.mozilla.org/en-US/docs/Web/API/SharedWorker" target="_top">SharedWorkers</a>

-are a special form of Javascript Worker Threads that have a shared scope

-between all threads from the same Javascript origin.

-     </p><p><span class="command"><strong>Design Goal:</strong></span>

+are a special form of JavaScript Worker threads that have a shared scope between

+all threads from the same Javascript origin.

-SharedWorker scope MUST be isolated to the URL bar domain. A SharedWorker

-launched from a third party from one URL bar domain MUST NOT have access to

-the objects created by that same third party loaded under another URL bar domain.

-

-     </p><p><span class="command"><strong>Implementation Status:</strong></span>

+     </p><p>

-For now, we disable SharedWorkers via the pref

-<span class="command"><strong>dom.workers.sharedWorkers.enabled</strong></span>.

+The SharedWorker scope MUST be isolated to the URL bar domain. I.e. a

+SharedWorker launched from a third party from one URL bar domain MUST NOT have

+access to the objects created by that same third party loaded under another URL

+bar domain. This functionality is provided by a

+<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">

+Firefox patch</a>.

      </p></li><li class="listitem"><span class="command"><strong>blob: URIs (URL.createObjectURL)</strong></span><p>

@@ -867,19 +953,33 @@ web. While this UUID value is neither under control of the site nor

 predictable, it can still be used to tag a set of users that are of high

 interest to an adversary.

-     </p><p>

+      </p><p><span class="command"><strong>Design Goal:</strong></span>

 URIs created with URL.createObjectURL MUST be limited in scope to the first

-party URL bar domain that created them. We provide this isolation in Tor

-Browser via a <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0esr-4.5-1&amp;id=0d67ab406bdd3cf095802cb25c081641aa1f0bcc" target="_top">direct

-patch to Firefox</a> and disable URL.createObjectURL in the WebWorker

-context as a stopgap, due to an edge case with enforcing this isolation in

-WebWorkers.

+party URL bar domain that created them.

+

+     </p><p><span class="command"><strong>Implementation Status:</strong></span>

+

+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

+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>.

-     </p></li><li class="listitem"><span class="command"><strong>SPDY</strong></span><p>

+     </p></li><li class="listitem"><span class="command"><strong>SPDY and HTTP/2</strong></span><p><span class="command"><strong>Design Goal:</strong></span>

-Because SPDY can store identifiers, it is disabled through the

-Firefox preference <span class="command"><strong>network.http.spdy.enabled</strong></span>.

+SPDY and HTTP/2 connections MUST be isolated to the URL bar domain. Furthermore,

+all associated means that could be used for cross-domain user tracking (alt-svc

+headers come to mind) MUST adhere to this design principle as well.

+

+    </p><p><span class="command"><strong>Implementation status:</strong></span>

+

+SPDY and HTTP/2 are currently disabled by setting the

+Firefox preferences <span class="command"><strong>network.http.spdy.enabled</strong></span>,

+<span class="command"><strong>network.http.spdy.enabled.v2</strong></span>,

+<span class="command"><strong>network.http.spdy.enabled.v3</strong></span>,

+<span class="command"><strong>network.http.spdy.enabled.v3-1</strong></span>,

+<span class="command"><strong>network.http.spdy.enabled.http2</strong></span>,

+<span class="command"><strong>network.http.spdy.enabled.http2draft</strong></span>,

+<span class="command"><strong>network.http.altsvc.enabled</strong></span>, and

+<span class="command"><strong>network.http.altsvc.oe</strong></span> to <span class="command"><strong>false</strong></span>.

      </p></li><li class="listitem"><span class="command"><strong>Automated cross-origin redirects</strong></span><p><span class="command"><strong>Design Goal:</strong></span>

@@ -926,32 +1026,112 @@ We disable the password saving functionality in the browser as part of our

 since users may decide to re-enable disk history records and password saving,

 we also set the <a class="ulink" href="http://kb.mozillazine.org/Signon.autofillForms" target="_top">signon.autofillForms</a>

 preference to false to prevent saved values from immediately populating

-fields upon page load. Since Javascript can read these values as soon as they

+fields upon page load. Since JavaScript can read these values as soon as they

 appear, setting this preference prevents automatic linkability from stored passwords.

-     </p></li><li class="listitem"><span class="command"><strong>HSTS supercookies</strong></span><p>

+     </p></li><li class="listitem"><span class="command"><strong>HSTS and HPKP supercookies</strong></span><p>

-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

+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>

+<a class="ulink" href="http://www.radicalresearch.co.uk/lab/hstssupercookies/" target="_top">

 supercookies</a>. Since HSTS effectively stores one bit of information per domain

 name, an adversary in possession of numerous domains can use them to construct

 cookies based on stored HSTS state.

+      </p><p>

+

+HPKP provides <a class="ulink" href="https://zyan.scripts.mit.edu/presentations/toorcon2015.pdf" target="_top">

+a mechanism for user tracking</a> across domains as well. It allows abusing the

+requirement to provide a backup pin and the option to report a pin validation

+failure. In a tracking scenario every user gets a unique SHA-256 value serving

+as backup pin. This value is sent back after (deliberate) pin validation failures

+working in fact as a cookie.

+

       </p><p><span class="command"><strong>Design Goal:</strong></span>

-There appears to be three options for us: 1. Disable HSTS entirely, and rely

-instead on HTTPS-Everywhere to crawl and ship rules for HSTS sites. 2.

-Restrict the number of HSTS-enabled third parties allowed per URL bar origin.

-3. Prevent third parties from storing HSTS rules. We have not yet decided upon

-the best approach.

+HSTS and HPKP MUST be isolated to the URL bar domain.

+

+      </p><p><span class="command"><strong>Implementation Status:</strong></span>

+

+Currently, HSTS and HPKP state is both cleared by <a class="link" href="#new-identity" title="4.7. Long-Term Unlinkability via &quot;New Identity&quot; button">New Identity</a>,

+but we don't defend against the creation and usage of any of these supercookies

+between <span class="command"><strong>New Identity</strong></span> invocations.

+

+      </p></li><li class="listitem"><span class="command"><strong>Broadcast Channels</strong></span><p>

+

+The BroadcastChannel API allows cross-site communication within the same

+origin. However, to avoid cross-origin linkability broadcast channels MUST

+instead be isolated to the URL bar domain.

+

+      </p><p>

+

+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

+patch to Firefox</a>. If we lack a window for determining the URL bar

+domain (e.g. in some worker contexts) the use of broadcast channels is disabled.

+

+      </p></li><li class="listitem"><span class="command"><strong>OCSP</strong></span><p>

+

+OCSP requests go to Certfication Authorities (CAs) to check for revoked

+certificates. They are sent once the browser is visiting a website via HTTPS and

+no cached results are available. Thus, to avoid information leaks, e.g. to exit

+relays, OCSP requests MUST go over the same circuit as the HTTPS request causing

+them and MUST therefore be isolated to the URL bar domain. The resulting cache

+entries MUST be bound to the URL bar domain as well. This functionality is

+provided by a

+<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>.

+

+       </p></li><li class="listitem"><span class="command"><strong>Favicons</strong></span><p>

+

+When visiting a website its favicon is fetched via a request originating from

+the browser itself (similar to the OCSP mechanism mentioned in the previous

+section). Those requests MUST be isolated to the URL bar domain. This

+functionality is provided by a

+<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>.

+

+      </p></li><li class="listitem"><span class="command"><strong>mediasource: URIs and MediaStreams</strong></span><p>

+

+Much like blob URLs, mediasource: URIs and MediaStreams can be used to tag

+users. Therefore, mediasource: URIs and MediaStreams MUST be isolated to the URL bar domain.

+This functionality is part of a