Update design doc with FF17-ESR changes. (7e670bf6e) - tor-webwml.git

projects/torbrowser/design/index.html.en
@@ -1,12 +1,10 @@
 <?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.75.2" /></head><body><div class="article" title="The Design and Implementation of the Tor Browser [DRAFT]"><div class="titlepage"><div><div><h2 class="title"><a id="design"></a>The Design and Implementation of the Tor Browser [DRAFT]</h2></div><div><div class="author"><h3 class="author"><span class="firstname">Mike</span> <span class="surname">Perry</span></h3><div class="affiliation"><div class="address"><p><code class="email">&lt;<a class="email" href="mailto:mikeperry#torproject org">mikeperry#torproject org</a>&gt;</code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Erinn</span> <span class="surname">Clark</span></h3><div class="affiliation"><div class="address"><p><code class="email">&lt;<a class="email" href="mailto:erinn#torproject org">erinn#torproject org</a>&gt;</code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Steven</span> <span class="surname">Murdoch</span></h3><div class="affiliation"><div class="address"><p><code class="email">&lt;<a class="email" href="mailto:sjmurdoch#torproject org">sjmurdoch#torproject org</a>&gt;</code></p></div></div></div></div><div><p class="pubdate">Dec 28 2011</p></div></div><hr /></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="#id2619754">1. Introduction</a></span></dt><dd><dl><dt><span class="sect2"><a href="#adversary">1.1. Adversary Model</a></span></dt></dl></dd><dt><span class="sect1"><a href="#DesignRequirements">2. Design Requirements and Philosophy</a></span></dt><dd><dl><dt><span class="sect2"><a href="#security">2.1. Security Requirements</a></span></dt><dt><span class="sect2"><a href="#privacy">2.2. Privacy Requirements</a></span></dt><dt><span class="sect2"><a href="#philosophy">2.3. Philosophy</a></span></dt></dl></dd><dt><span class="sect1"><a href="#Implementation">3. Implementation</a></span></dt><dd><dl><dt><span class="sect2"><a href="#proxy-obedience">3.1. Proxy Obedience</a></span></dt><dt><span class="sect2"><a href="#state-separation">3.2. State Separation</a></span></dt><dt><span class="sect2"><a href="#disk-avoidance">3.3. Disk Avoidance</a></span></dt><dt><span class="sect2"><a href="#app-data-isolation">3.4. Application Data Isolation</a></span></dt><dt><span class="sect2"><a href="#identifier-linkability">3.5. Cross-Origin Identifier Unlinkability</a></span></dt><dt><span class="sect2"><a href="#fingerprinting-linkability">3.6. Cross-Origin Fingerprinting Unlinkability</a></span></dt><dt><span class="sect2"><a href="#new-identity">3.7. Long-Term Unlinkability via "New Identity" button</a></span></dt><dt><span class="sect2"><a href="#click-to-play">3.8. Click-to-play for plugins and invasive content</a></span></dt><dt><span class="sect2"><a href="#firefox-patches">3.9. Description of Firefox Patches</a></span></dt></dl></dd><dt><span class="sect1"><a href="#Packaging">4. Packaging</a></span></dt><dd><dl><dt><span class="sect2"><a href="#build-security">4.1. Build Process Security</a></span></dt><dt><span class="sect2"><a href="#addons">4.2. External Addons</a></span></dt><dt><span class="sect2"><a href="#prefs">4.3. Pref Changes</a></span></dt><dt><span class="sect2"><a href="#update-mechanism">4.4. Update Security</a></span></dt></dl></dd><dt><span class="sect1"><a href="#Testing">5. Testing</a></span></dt><dd><dl><dt><span class="sect2"><a href="#SingleStateTesting">5.1. Single state testing</a></span></dt></dl></dd></dl></div><div class="sect1" title="1. Introduction"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2619754"></a>1. Introduction</h2></div></div></div><p>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml"><head><title>The Design and Implementation of the Tor Browser [DRAFT]</title><meta name="generator" content="DocBook XSL Stylesheets V1.75.2"/></head><body><div class="article" title="The Design and Implementation of the Tor Browser [DRAFT]"><div class="titlepage"><div><div><h2 class="title"><a id="design"/>The Design and Implementation of the Tor Browser [DRAFT]</h2></div><div><div class="author"><h3 class="author"><span class="firstname">Mike</span> <span class="surname">Perry</span></h3><div class="affiliation"><div class="address"><p><code class="email">&lt;<a class="email" href="mailto:mikeperry#torproject org">mikeperry#torproject org</a>&gt;</code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Erinn</span> <span class="surname">Clark</span></h3><div class="affiliation"><div class="address"><p><code class="email">&lt;<a class="email" href="mailto:erinn#torproject org">erinn#torproject org</a>&gt;</code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Steven</span> <span class="surname">Murdoch</span></h3><div class="affiliation"><div class="address"><p><code class="email">&lt;<a class="email" href="mailto:sjmurdoch#torproject org">sjmurdoch#torproject org</a>&gt;</code></p></div></div></div></div><div><p class="pubdate">Feb 23 2013</p></div></div><hr/></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="#idp3348944">1. Introduction</a></span></dt><dd><dl><dt><span class="sect2"><a href="#components">1.1. Browser Component Overview</a></span></dt></dl></dd><dt><span class="sect1"><a href="#DesignRequirements">2. Design Requirements and Philosophy</a></span></dt><dd><dl><dt><span class="sect2"><a href="#security">2.1. Security Requirements</a></span></dt><dt><span class="sect2"><a href="#privacy">2.2. Privacy Requirements</a></span></dt><dt><span class="sect2"><a href="#philosophy">2.3. Philosophy</a></span></dt></dl></dd><dt><span class="sect1"><a href="#adversary">3. Adversary Model</a></span></dt><dd><dl><dt><span class="sect2"><a href="#adversarygoals">3.1. Adversary Goals</a></span></dt><dt><span class="sect2"><a href="#adversarypositioning">3.2. Adversary Capabilities - Positioning</a></span></dt><dt><span class="sect2"><a href="#attacks">3.3. Adversary Capabilities - Attacks</a></span></dt></dl></dd><dt><span class="sect1"><a href="#Implementation">4. Implementation</a></span></dt><dd><dl><dt><span class="sect2"><a href="#proxy-obedience">4.1. Proxy Obedience</a></span></dt><dt><span class="sect2"><a href="#state-separation">4.2. State Separation</a></span></dt><dt><span class="sect2"><a href="#disk-avoidance">4.3. Disk Avoidance</a></span></dt><dt><span class="sect2"><a href="#app-data-isolation">4.4. Application Data Isolation</a></span></dt><dt><span class="sect2"><a href="#identifier-linkability">4.5. Cross-Origin Identifier Unlinkability</a></span></dt><dt><span class="sect2"><a href="#fingerprinting-linkability">4.6. Cross-Origin Fingerprinting Unlinkability</a></span></dt><dt><span class="sect2"><a href="#new-identity">4.7. Long-Term Unlinkability via "New Identity" button</a></span></dt><dt><span class="sect2"><a href="#firefox-patches">4.8. Description of Firefox Patches</a></span></dt></dl></dd><dt><span class="appendix"><a href="#Transparency">A. Towards Transparency in Navigation Tracking</a></span></dt></dl></div><div class="sect1" title="1. Introduction"><div class="titlepage"><div><div><h2 class="title"><a id="idp3348944"/>1. Introduction</h2></div></div></div><p>
 
-This document describes the <a class="link" href="#adversary" title="1.1. Adversary Model">adversary model</a>,
-<a class="link" href="#DesignRequirements" title="2. Design Requirements and Philosophy">design requirements</a>,
-<a class="link" href="#Implementation" title="3. Implementation">implementation</a>, <a class="link" href="#Packaging" title="4. Packaging">packaging</a> and <a class="link" href="#Testing" title="5. Testing">testing
-procedures</a> of the Tor Browser. It is
-current as of Tor Browser 2.2.35-1 and Torbutton 1.4.5.
+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 2.3.25-4
+and Torbutton 1.5.0.
 
   </p><p>
 
@@ -15,182 +13,27 @@ describe a reference implementation of a Private Browsing Mode that defends
 against active network adversaries, in addition to the passive forensic local
 adversary currently addressed by the major browsers.
 
-  </p><div class="sect2" title="1.1. Adversary Model"><div class="titlepage"><div><div><h3 class="title"><a id="adversary"></a>1.1. Adversary Model</h3></div></div></div><p>
+  </p><div class="sect2" title="1.1. Browser Component Overview"><div class="titlepage"><div><div><h3 class="title"><a id="components"/>1.1. Browser Component Overview</h3></div></div></div><p>
 
-A Tor web browser adversary has a number of goals, capabilities, and attack
-types that can be used to guide us towards a set of requirements for the
-Tor Browser. Let's start with the goals.
-
-   </p><div class="sect3" title="Adversary Goals"><div class="titlepage"><div><div><h4 class="title"><a id="adversarygoals"></a>Adversary Goals</h4></div></div></div><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><span class="command"><strong>Bypassing proxy settings</strong></span><p>The adversary's primary goal is direct compromise and bypass of 
-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
-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
-queries, or visited censored sites.
-     </p></li><li class="listitem"><span class="command"><strong>Location information</strong></span><p>
-
-Location information such as timezone and locality can be useful for the
-adversary to determine if a user is in fact originating from one of the
-regions they are attempting to control, or to zero-in on the geographical
-location of a particular dissident or whistleblower.
-
-     </p></li><li class="listitem"><span class="command"><strong>Miscellaneous anonymity set reduction</strong></span><p>
-
-Anonymity set reduction is also useful in attempting to zero in on a
-particular individual. If the dissident or whistleblower is using a rare build
-of Firefox for an obscure operating system, this can be very useful
-information for tracking them down, or at least <a class="link" href="#fingerprinting">tracking their activities</a>.
-
-     </p></li><li class="listitem"><span class="command"><strong>History records and other on-disk
-information</strong></span><p>
-In some cases, the adversary may opt for a heavy-handed approach, such as
-seizing the computers of all Tor users in an area (especially after narrowing
-the field by the above two pieces of information). History records and cache
-data are the primary goals here.
-     </p></li></ol></div></div><div class="sect3" title="Adversary Capabilities - Positioning"><div class="titlepage"><div><div><h4 class="title"><a id="adversarypositioning"></a>Adversary Capabilities - Positioning</h4></div></div></div><p>
-The adversary can position themselves at a number of different locations in
-order to execute their attacks.
-    </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><span class="command"><strong>Exit Node or Upstream Router</strong></span><p>
-The adversary can run exit nodes, or alternatively, they may control routers
-upstream of exit nodes. Both of these scenarios have been observed in the
-wild.
-     </p></li><li class="listitem"><span class="command"><strong>Ad servers and/or Malicious Websites</strong></span><p>
-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 
-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
-when they have Tor disabled, in an attempt to correlate their Tor and Non-Tor
-activity.
-     </p></li><li class="listitem"><span class="command"><strong>Physical Access</strong></span><p>
-Some users face adversaries with intermittent or constant physical access.
-Users in Internet cafes, for example, face such a threat. In addition, in
-countries where simply using tools like Tor is illegal, users may face
-confiscation of their computer equipment for excessive Tor usage or just
-general suspicion.
-     </p></li></ol></div></div><div class="sect3" title="Adversary Capabilities - Attacks"><div class="titlepage"><div><div><h4 class="title"><a id="attacks"></a>Adversary Capabilities - Attacks</h4></div></div></div><p>
-
-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 
-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.
-
-    </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><span class="command"><strong>Read and insert identifiers</strong></span><p>
-
-The browser contains multiple facilities for storing identifiers that the
-adversary creates for the purposes of tracking users. These identifiers are
-most obviously cookies, but also include HTTP auth, DOM storage, cached
-scripts and other elements with embedded identifiers, client certificates, and
-even TLS Session IDs.
-
-     </p><p>
-
-An adversary in a position to perform MITM content alteration can inject
-document content elements to both read and inject cookies for arbitrary
-domains. In fact, even many "SSL secured" websites are vulnerable to this sort of
-<a class="ulink" href="http://seclists.org/bugtraq/2007/Aug/0070.html" target="_top">active
-sidejacking</a>. In addition, the ad networks of course perform tracking
-with cookies as well.
-
-     </p></li><li class="listitem"><a id="fingerprinting"></a><span class="command"><strong>Fingerprint users based on browser
-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. 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
-done</a> by the EFF uses the actual entropy - 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 definitely useful, and the metric is probably the appropriate one for
-determining how identifying a particular browser property is. However, some
-quirks of their study means that they do not extract as much information as
-they could from display information: they only use desktop resolution and do
-not attempt to infer the size of toolbars. In the other direction, they may be
-over-counting in some areas, as they did not compute joint entropy over
-multiple attributes that may exhibit a high degree of correlation. Also, new
-browser features are added regularly, so the data should not be taken as
-final.
+The Tor Browser is based on <a class="ulink" href="https://www.mozilla.org/en-US/firefox/organizations/">Mozilla's Extended
+Support Release (ESR) Firefox branch</a>. We have a <a class="link" href="#firefox-patches" title="4.8. Description of Firefox Patches">series of patches</a> against this browser to
+enhance privacy and security. Browser behavior is additionally augmented
+through the <a class="ulink" href="https://gitweb.torproject.org/torbutton.git/tree/master">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/torbrowser.git/blob/HEAD:/build-scripts/config/pound_tor.js">change
+a number of Firefox preferences</a> from their defaults.
 
    </p><p>
 
-Despite the uncertainty, all fingerprinting attacks leverage the following
-attack vectors:
-
-     </p><div class="orderedlist"><ol class="orderedlist" type="a"><li class="listitem"><span class="command"><strong>Observing Request Behavior</strong></span><p>
-
-Properties of the user's request behavior comprise the bulk of low-hanging
-fingerprinting targets. These include: User agent, Accept-* headers, pipeline
-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>
-
-Javascript can reveal a lot of fingerprinting information. It provides DOM
-objects such as window.screen and window.navigator to extract information
-about the useragent. 
-
-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.
-
-
-
-     </p></li><li class="listitem"><span class="command"><strong>Inserting Plugins</strong></span><p>
-
-The Panopticlick project found that the mere list of installed plugins (in
-navigator.plugins) was sufficient to provide a large degree of
-fingerprintability. Additionally, plugins are capable of extracting font lists,
-interface addresses, and other machine information that is beyond what the
-browser would normally provide to content. In addition, plugins can be used to
-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. 
-
-
-     </p></li><li class="listitem"><span class="command"><strong>Inserting CSS</strong></span><p>
+To help protect against potential Tor Exit Node eavesdroppers, we include
+<a class="ulink" href="https://www.eff.org/https-everywhere">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="http://noscript.net/">NoScript</a>. To protect against
+PDF-based Tor proxy bypass and to improve usability, we include the <a class="ulink" href="https://addons.mozilla.org/en-us/firefox/addon/pdfjs/">PDF.JS</a>
+extension. We also modify <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/HEAD:/build-scripts/config/extension-overrides.js">several
+extension preferences</a> from their defaults.
 
-<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.
-
-     </p></li></ol></div></li><li class="listitem"><span class="command"><strong>Remotely or locally exploit browser and/or
-OS</strong></span><p>
-
-Last, but definitely not least, the adversary can exploit either general
-browser vulnerabilities, plugin vulnerabilities, or OS vulnerabilities to
-install malware and surveillance software. An adversary with physical access
-can perform similar actions. Regrettably, this last attack capability is
-outside of our ability to defend against, but it is worth mentioning for
-completeness. <a class="ulink" href="http://tails.boum.org/contribute/design/" target="_top">The Tails
-system</a> however can provide some limited defenses against this
-adversary.
-
-     </p></li></ol></div></div></div></div><div class="sect1" title="2. Design Requirements and Philosophy"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="DesignRequirements"></a>2. Design Requirements and Philosophy</h2></div></div></div><p>
+   </p></div></div><div class="sect1" title="2. Design Requirements and Philosophy"><div class="titlepage"><div><div><h2 class="title"><a id="DesignRequirements"/>2. Design Requirements and Philosophy</h2></div></div></div><p>
 
 The Tor Browser Design Requirements are meant to describe the properties of a
 Private Browsing Mode that defends against both network and local forensic
@@ -214,9 +57,9 @@ browser distribution.
       The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
       NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
       "OPTIONAL" in this document are to be interpreted as described in
-      <a class="ulink" href="https://www.ietf.org/rfc/rfc2119.txt" target="_top">RFC 2119</a>.
+      <a class="ulink" href="https://www.ietf.org/rfc/rfc2119.txt">RFC 2119</a>.
 
-  </p><div class="sect2" title="2.1. Security Requirements"><div class="titlepage"><div><div><h3 class="title"><a id="security"></a>2.1. Security Requirements</h3></div></div></div><p>
+  </p><div class="sect2" title="2.1. Security Requirements"><div class="titlepage"><div><div><h3 class="title"><a id="security"/>2.1. Security Requirements</h3></div></div></div><p>
 
 The security requirements are primarily concerned with ensuring the safe use
 of Tor. Violations in these properties typically result in serious risk for
@@ -224,13 +67,13 @@ the user in terms of immediate deanonymization and/or observability. With
 respect to browser support, security requirements are the minimum properties
 in order for Tor to support the use of a particular browser.
 
-   </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><a class="link" href="#proxy-obedience" title="3.1. Proxy Obedience"><span class="command"><strong>Proxy
+   </p><div class="orderedlist"><ol class="orderedlist"><li class="listitem"><a class="link" href="#proxy-obedience" title="4.1. Proxy Obedience"><span class="command"><strong>Proxy
 Obedience</strong></span></a><p>The browser
-MUST NOT bypass Tor proxy settings for any content.</p></li><li class="listitem"><a class="link" href="#state-separation" title="3.2. State Separation"><span class="command"><strong>State
+MUST NOT bypass Tor proxy settings for any content.</p></li><li class="listitem"><a class="link" href="#state-separation" title="4.2. State Separation"><span class="command"><strong>State
 Separation</strong></span></a><p>The browser MUST NOT provide any stored state to the content window
 from other browsers or other browsing modes, including shared state from
 plugins, machine identifiers, and TLS session state.
-</p></li><li class="listitem"><a class="link" href="#disk-avoidance" title="3.3. Disk Avoidance"><span class="command"><strong>Disk
+</p></li><li class="listitem"><a class="link" href="#disk-avoidance" title="4.3. Disk Avoidance"><span class="command"><strong>Disk
 Avoidance</strong></span></a><p>
 
 The browser MUST NOT write any information that is derived from or that
@@ -238,7 +81,7 @@ reveals browsing activity to the disk, or store it in memory beyond the
 duration of one browsing session, unless the user has explicitly opted to
 store their browsing history information to disk.
 
-</p></li><li class="listitem"><a class="link" href="#app-data-isolation" title="3.4. Application Data Isolation"><span class="command"><strong>Application Data
+</p></li><li class="listitem"><a class="link" href="#app-data-isolation" title="4.4. Application Data Isolation"><span class="command"><strong>Application Data
 Isolation</strong></span></a><p>
 
 The components involved in providing private browsing MUST be self-contained,
@@ -253,7 +96,7 @@ to permissions issues with access to swap, implementations MAY choose to leave
 it out of scope, and/or leave it to the Operating System/platform to implement
 ephemeral-keyed encrypted swap.
 
-</p></li></ol></div></div><div class="sect2" title="2.2. Privacy Requirements"><div class="titlepage"><div><div><h3 class="title"><a id="privacy"></a>2.2. Privacy Requirements</h3></div></div></div><p>
+</p></li></ol></div></div><div class="sect2" title="2.2. Privacy Requirements"><div class="titlepage"><div><div><h3 class="title"><a id="privacy"/>2.2. Privacy Requirements</h3></div></div></div><p>
 
 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
@@ -264,13 +107,13 @@ to prefer one browser over another.
    </p><p>
 
 For the purposes of the unlinkability requirements of this section as well as
-the descriptions in the <a class="link" href="#Implementation" title="3. Implementation">implementation
+the descriptions in the <a class="link" href="#Implementation" title="4. Implementation">implementation
 section</a>, a <span class="command"><strong>url bar origin</strong></span> means at least the
 second-level DNS name.  For example, for mail.google.com, the origin would be
 google.com. Implementations MAY, at their option, restrict the url bar origin
 to be the entire fully qualified domain name.
 
-   </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><a class="link" href="#identifier-linkability" title="3.5. Cross-Origin Identifier Unlinkability"><span class="command"><strong>Cross-Origin
+   </p><div class="orderedlist"><ol class="orderedlist"><li class="listitem"><a class="link" href="#identifier-linkability" title="4.5. Cross-Origin Identifier Unlinkability"><span class="command"><strong>Cross-Origin
 Identifier Unlinkability</strong></span></a><p>
 
 User activity on one url bar origin MUST NOT be linkable to their activity in
@@ -279,16 +122,17 @@ interaction or approval. This requirement specifically applies to linkability
 from stored browser identifiers, authentication tokens, and shared state. The
 requirement does not apply to linkable information the user manually submits
 to sites, or due to information submitted during manual link traversal. This
-functionality SHOULD NOT interfere with federated login in a substantial way.
+functionality SHOULD NOT interfere with interactive, click-driven federated
+login in a substantial way.
 
-  </p></li><li class="listitem"><a class="link" href="#fingerprinting-linkability" title="3.6. Cross-Origin Fingerprinting Unlinkability"><span class="command"><strong>Cross-Origin
+  </p></li><li class="listitem"><a class="link" href="#fingerprinting-linkability" title="4.6. Cross-Origin Fingerprinting Unlinkability"><span class="command"><strong>Cross-Origin
 Fingerprinting Unlinkability</strong></span></a><p>
 
 User activity on one url bar origin MUST NOT be linkable to their activity in
 any other url bar origin by any third party. This property specifically applies to
 linkability from fingerprinting browser behavior.
 
-  </p></li><li class="listitem"><a class="link" href="#new-identity" title="3.7. Long-Term Unlinkability via &quot;New Identity&quot; button"><span class="command"><strong>Long-Term
+  </p></li><li class="listitem"><a class="link" href="#new-identity" title="4.7. Long-Term Unlinkability via &quot;New Identity&quot; button"><span class="command"><strong>Long-Term
 Unlinkability</strong></span></a><p>
 
 The browser SHOULD provide an obvious, easy way to remove all of its
@@ -296,12 +140,12 @@ authentication tokens and browser state and obtain a fresh identity.
 Additionally, the browser SHOULD clear linkable state by default automatically
 upon browser restart, except at user option.
 
-  </p></li></ol></div></div><div class="sect2" title="2.3. Philosophy"><div class="titlepage"><div><div><h3 class="title"><a id="philosophy"></a>2.3. Philosophy</h3></div></div></div><p>
+  </p></li></ol></div></div><div class="sect2" title="2.3. Philosophy"><div class="titlepage"><div><div><h3 class="title"><a id="philosophy"/>2.3. Philosophy</h3></div></div></div><p>
 
 In addition to the above design requirements, the technology decisions about
 Tor Browser are also guided by some philosophical positions about technology.
 
-   </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><span class="command"><strong>Preserve existing user model</strong></span><p>
+   </p><div class="orderedlist"><ol class="orderedlist"><li class="listitem"><span class="command"><strong>Preserve existing user model</strong></span><p>
 
 The existing way that the user expects to use a browser must be preserved. If
 the user has to maintain a different mental model of how the sites they are
@@ -312,7 +156,7 @@ result. Worse, they may just stop using the browser, assuming it is broken.
 
       </p><p>
 
-User model breakage was one of the <a class="ulink" href="https://blog.torproject.org/blog/toggle-or-not-toggle-end-torbutton" target="_top">failures
+User model breakage was one of the <a class="ulink" href="https://blog.torproject.org/blog/toggle-or-not-toggle-end-torbutton">failures
 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
@@ -340,20 +184,20 @@ be restricted from running automatically on every page (via click-to-play
 placeholders), and/or be sandboxed to restrict the types of system calls they
 can execute. If the user decides to craft an exemption to allow a plugin to be
 used, it MUST only apply to the top level url bar domain, and not to all sites,
-to reduce linkability.
+to reduce cross-origin fingerprinting linkability.
 
        </p></li><li class="listitem"><span class="command"><strong>Minimize Global Privacy Options</strong></span><p>
 
-<a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3100" target="_top">Another
-failure of Torbutton</a> was (and still is) the options panel. Each option
+<a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3100">Another
+failure of Torbutton</a> was the options panel. Each option
 that detectably alters browser behavior can be used as a fingerprinting tool.
-Similarly, all extensions <a class="ulink" href="http://blog.chromium.org/2010/06/extensions-in-incognito.html" target="_top">SHOULD be
+Similarly, all extensions <a class="ulink" href="http://blog.chromium.org/2010/06/extensions-in-incognito.html">SHOULD be
 disabled in the mode</a> except as an opt-in basis. We SHOULD NOT load
-system-wide addons or plugins.
+system-wide and/or Operating System provided addons or plugins.
 
      </p><p>
 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
+<a class="ulink" href="https://wiki.mozilla.org/Privacy/Features/Site-based_data_management_UI">per
 url bar origin</a> to eliminate the possibility of linkability
 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
@@ -361,16 +205,18 @@ allowing that plugin object for that url bar origin only. The same
 goes for exemptions to third party cookie policy, geo-location, and any other
 privacy permissions.
      </p><p>
-If the user has indicated they do not care about local history storage, these
-permissions can be written to disk. Otherwise, they should remain memory-only. 
+If the user has indicated they wish to record local history storage, these
+permissions can be written to disk. Otherwise, they MUST remain memory-only. 
      </p></li><li class="listitem"><span class="command"><strong>No filters</strong></span><p>
 
-Filter-based addons such as <a class="ulink" href="https://addons.mozilla.org/en-US/firefox/addon/adblock-plus/" target="_top">AdBlock
-Plus</a>, <a class="ulink" href="http://requestpolicy.com/" target="_top">Request Policy</a>,
-<a class="ulink" href="http://www.ghostery.com/about" target="_top">Ghostery</a>, <a class="ulink" href="http://priv3.icsi.berkeley.edu/" target="_top">Priv3</a>, and <a class="ulink" href="http://sharemenot.cs.washington.edu/" target="_top">Sharemenot</a> are to be
+Site-specific or filter-based addons such as <a class="ulink" href="https://addons.mozilla.org/en-US/firefox/addon/adblock-plus/">AdBlock
+Plus</a>, <a class="ulink" href="http://requestpolicy.com/">Request Policy</a>,
+<a class="ulink" href="http://www.ghostery.com/about">Ghostery</a>, <a class="ulink" href="http://priv3.icsi.berkeley.edu/">Priv3</a>, and <a class="ulink" href="http://sharemenot.cs.washington.edu/">Sharemenot</a> are to be
 avoided. We believe that these addons do not add any real privacy to a proper
-<a class="link" href="#Implementation" title="3. Implementation">implementation</a> of the above <a class="link" href="#privacy" title="2.2. Privacy Requirements">privacy requirements</a>, as all third parties are
-prevented from tracking users between sites by the implementation.
+<a class="link" href="#Implementation" title="4. Implementation">implementation</a> of the above <a class="link" href="#privacy" title="2.2. Privacy Requirements">privacy requirements</a>, and that development efforts
+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
@@ -382,7 +227,7 @@ fingerprinting targets.
 As a general matter, we are also generally opposed to shipping an always-on Ad
 blocker with Tor Browser. We feel that this would damage our credibility in
 terms of demonstrating that we are providing privacy through a sound design
-alone, as well as damage the acceptance of Tor users by sites who support
+alone, as well as damage the acceptance of Tor users by sites that support
 themselves through advertising revenue.
 
       </p><p>
@@ -393,7 +238,202 @@ We believe that if we do not stay current with the support of new web
 technologies, we cannot hope to substantially influence or be involved in
 their proper deployment or privacy realization. However, we will likely disable
 high-risk features pending analysis, audit, and mitigation.
-      </p></li></ol></div></div></div><div class="sect1" title="3. Implementation"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Implementation"></a>3. Implementation</h2></div></div></div><p>
+      </p></li></ol></div></div></div><div class="sect1" title="3. Adversary Model"><div class="titlepage"><div><div><h2 class="title"><a id="adversary"/>3. Adversary Model</h2></div></div></div><p>
+
+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" title="3.1. Adversary Goals"><div class="titlepage"><div><div><h3 class="title"><a id="adversarygoals"/>3.1. Adversary Goals</h3></div></div></div><div class="orderedlist"><ol class="orderedlist"><li class="listitem"><span class="command"><strong>Bypassing proxy settings</strong></span><p>The adversary's primary goal is direct compromise and bypass of 
+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
+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
+queries, or visited censored sites.
+     </p></li><li class="listitem"><span class="command"><strong>Location information</strong></span><p>
+
+Location information such as timezone and locality can be useful for the
+adversary to determine if a user is in fact originating from one of the
+regions they are attempting to control, or to zero-in on the geographical
+location of a particular dissident or whistleblower.
+
+     </p></li><li class="listitem"><span class="command"><strong>Correlate activity across multiple sites</strong></span><p>
+
+The primary goal of the advertising networks is to know that the user who
+visited siteX.com is the same user that visited siteY.com to serve them
+targeted ads. The advertising networks become our adversary insofar as they
+attempt to perform this correlation without the user's explicit consent.
+
+     </p></li><li class="listitem"><span class="command"><strong>Fingerprinting/anonymity set reduction</strong></span><p>
+
+Fingerprinting (more generally: "anonymity set reduction") is used to attempt
+to zero in on a particular individual without the use of tracking identifiers.
+If the dissident or whistleblower is using a rare build of Firefox for an
+obscure operating system, this can be very useful information for tracking
+them down, or at least <a class="link" href="#fingerprinting">tracking their
+activities</a>.
+
+     </p></li><li class="listitem"><span class="command"><strong>History records and other on-disk
+information</strong></span><p>
+In some cases, the adversary may opt for a heavy-handed approach, such as
+seizing the computers of all Tor users in an area (especially after narrowing
+the field by the above two pieces of information). History records and cache
+data are the primary goals here.
+     </p></li></ol></div></div><div class="sect2" title="3.2. Adversary Capabilities - Positioning"><div class="titlepage"><div><div><h3 class="title"><a id="adversarypositioning"/>3.2. Adversary Capabilities - Positioning</h3></div></div></div><p>
+The adversary can position themselves at a number of different locations in
+order to execute their attacks.
+    </p><div class="orderedlist"><ol class="orderedlist"><li class="listitem"><span class="command"><strong>Exit Node or Upstream Router</strong></span><p>
+The adversary can run exit nodes, or alternatively, they may control routers
+upstream of exit nodes. Both of these scenarios have been observed in the
+wild.
+     </p></li><li class="listitem"><span class="command"><strong>Ad servers and/or Malicious Websites</strong></span><p>
+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 
+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
+when they have Tor disabled, in an attempt to correlate their Tor and Non-Tor
+activity.
+     </p></li><li class="listitem"><span class="command"><strong>Physical Access</strong></span><p>
+Some users face adversaries with intermittent or constant physical access.
+Users in Internet cafes, for example, face such a threat. In addition, in
+countries where simply using tools like Tor is illegal, users may face
+confiscation of their computer equipment for excessive Tor usage or just
+general suspicion.
+     </p></li></ol></div></div><div class="sect2" title="3.3. Adversary Capabilities - Attacks"><div class="titlepage"><div><div><h3 class="title"><a id="attacks"/>3.3. Adversary Capabilities - Attacks</h3></div></div></div><p>
+
+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 
+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.
+
+    </p><div class="orderedlist"><ol class="orderedlist"><li class="listitem"><span class="command"><strong>Read and insert identifiers</strong></span><p>
+
+The browser contains multiple facilities for storing identifiers that the
+adversary creates for the purposes of tracking users. These identifiers are
+most obviously cookies, but also include HTTP auth, DOM storage, cached
+scripts and other elements with embedded identifiers, client certificates, and
+even TLS Session IDs.
+
+     </p><p>
+
+An adversary in a position to perform MITM content alteration can inject
+document content elements to both read and inject cookies for arbitrary
+domains. In fact, even many "SSL secured" websites are vulnerable to this sort of
+<a class="ulink" href="http://seclists.org/bugtraq/2007/Aug/0070.html">active
+sidejacking</a>. In addition, the ad networks of course perform tracking
+with cookies as well.
+
+     </p><p>
+
+These types of attacks are attempts at subverting our <a class="link" href="#identifier-linkability" title="4.5. Cross-Origin Identifier Unlinkability">Cross-Origin Identifier Unlinkability</a> and <a class="link" href="#new-identity" title="4.7. Long-Term Unlinkability via &quot;New Identity&quot; button">Long-Term Unlikability</a> design requirements.
+
+     </p></li><li class="listitem"><a id="fingerprinting"/><span class="command"><strong>Fingerprint users based on browser
+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
+Fingerprinting Unlinkability</a> and <a class="link" href="#new-identity" title="4.7. Long-Term Unlinkability via &quot;New Identity&quot; button">Long-Term Unlikability</a> design requirements.
+
+</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.
+
+</p><p>
+
+The <a class="ulink" href="https://panopticlick.eff.org/about.php">Panopticlick study
+done</a> by the EFF uses the <a class="ulink" href="https://en.wikipedia.org/wiki/Entropy_%28information_theory%29">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">result data</a> is
+definitely useful, and the metric is probably the appropriate one for
+determining how identifying a particular browser property is. However, some
+quirks of their study means that they do not extract as much information as
+they could from display information: they only use desktop resolution and do
+not attempt to infer the size of toolbars. In the other direction, they may be
+over-counting in some areas, as they did not compute joint entropy over
+multiple attributes that may exhibit a high degree of correlation. Also, new
+browser features are added regularly, so the data should not be taken as
+final.
+
+      </p><p>
+
+Despite the uncertainty, all fingerprinting attacks leverage the following
+attack vectors:
+
+     </p><div class="orderedlist"><ol class="orderedlist"><li class="listitem"><span class="command"><strong>Observing Request Behavior</strong></span><p>
+
+Properties of the user's request behavior comprise the bulk of low-hanging
+fingerprinting targets. These include: User agent, Accept-* headers, pipeline
+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>
+
+Javascript can reveal a lot of fingerprinting information. It provides DOM
+objects such as window.screen and window.navigator to extract information
+about the useragent. 
+
+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">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">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/">Resource
+Timing</a> may leak an unknown amount of network timing related
+information.
+
+
+
+     </p></li><li class="listitem"><span class="command"><strong>Inserting Plugins</strong></span><p>
+
+The Panopticlick project found that the mere list of installed plugins (in
+navigator.plugins) was sufficient to provide a large degree of
+fingerprintability. Additionally, plugins are capable of extracting font lists,
+interface addresses, and other machine information that is beyond what the
+browser would normally provide to content. In addition, plugins can be used to
+store unique identifiers that are more difficult to clear than standard
+cookies.  <a class="ulink" href="http://epic.org/privacy/cookies/flash.html">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. 
+
+
+     </p></li><li class="listitem"><span class="command"><strong>Inserting CSS</strong></span><p>
+
+<a class="ulink" href="https://developer.mozilla.org/En/CSS/Media_queries">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.
+
+     </p></li></ol></div></li><li class="listitem"><span class="command"><strong>Remotely or locally exploit browser and/or
+OS</strong></span><p>
+
+Last, but definitely not least, the adversary can exploit either general
+browser vulnerabilities, plugin vulnerabilities, or OS vulnerabilities to
+install malware and surveillance software. An adversary with physical access
+can perform similar actions. Regrettably, this last attack capability is
+outside of the browser's ability to defend against, but it is worth mentioning
+for completeness. In fact, <a class="ulink" href="http://tails.boum.org/contribute/design/">The Tails system</a> can
+provide some defense against this adversary, and it does include the Tor
+Browser.
+
+     </p></li></ol></div></div></div><div class="sect1" title="4. Implementation"><div class="titlepage"><div><div><h2 class="title"><a id="Implementation"/>4. Implementation</h2></div></div></div><p>
 
 The Implementation section is divided into subsections, each of which
 corresponds to a <a class="link" href="#DesignRequirements" title="2. Design Requirements and Philosophy">Design Requirement</a>.
@@ -406,121 +446,153 @@ In some cases, the implementation meets the design requirements in a non-ideal
 way (for example, by disabling features). In rare cases, there may be no
 implementation at all. Both of these cases are denoted by differentiating
 between the <span class="command"><strong>Design Goal</strong></span> and the <span class="command"><strong>Implementation
-Status</strong></span> for each property. Corresponding bugs in the <a class="ulink" href="https://trac.torproject.org/projects/tor/report" target="_top">Tor bug tracker</a>
+Status</strong></span> for each property. Corresponding bugs in the <a class="ulink" href="https://trac.torproject.org/projects/tor/report">Tor bug tracker</a>
 are typically linked for these cases.
 
-  </p><div class="sect2" title="3.1. Proxy Obedience"><div class="titlepage"><div><div><h3 class="title"><a id="proxy-obedience"></a>3.1. Proxy Obedience</h3></div></div></div><p>
+  </p><div class="sect2" title="4.1. Proxy Obedience"><div class="titlepage"><div><div><h3 class="title"><a id="proxy-obedience"/>4.1. Proxy Obedience</h3></div></div></div><p>
 
 Proxy obedience is assured through the following:
-   </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem">Firefox Proxy settings
+   </p><div class="orderedlist"><ol class="orderedlist"><li class="listitem">Firefox proxy settings, patches, and build flags
  <p>
-  The Torbutton xpi sets the Firefox proxy settings to use Tor directly as a
+Our <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/HEAD:/build-scripts/config/pound_tor.js">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>, and
-<span class="command"><strong>network.proxy.socks_port</strong></span>.
+<span class="command"><strong>network.proxy.socks_version</strong></span>,
+<span class="command"><strong>network.proxy.socks_port</strong></span>, and
+<span class="command"><strong>network.dns.disablePrefetch</strong></span>.
+ </p><p>
+
+We also patch Firefox in order to <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0016-Prevent-WebSocket-DNS-leak.patch">prevent
+a DNS leak due to a WebSocket rate-limiting check</a>. As stated in the
+patch, we believe the direct DNS resolution performed by this check is in
+violation of the W3C standard, but <a class="ulink" href="https://bugzilla.mozilla.org/show_bug.cgi?id=751465">this DNS proxy leak
+remains present in stock Firefox releases</a>.
+
  </p><p>
 
-We have verified that these settings 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, 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 handers are all blocked.
+During the transition to Firefox 17-ESR, a code audit was undertaken to verify
+that there were no system calls or XPCOM activity in the source tree that did
+not use the browser proxy settings. The only violation we found was that
+WebRTC was capable of creating UDP sockets and was compiled in by default. We
+subsequently disabled it using the Firefox build option
+<span class="command"><strong>--disable-webrtc</strong></span>.
 
  </p><p>
 
-Numerous other third parties have also reviewed and <a class="link" href="#SingleStateTesting" title="5.1. Single state testing">tested</a> the proxy settings
-and have provided test cases based on their work. See in particular <a class="ulink" href="http://decloak.net/" target="_top">decloak.net</a>. 
+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><p>
+
+Numerous other third parties have also reviewed and tested the proxy settings
+and have provided test cases based on their work. See in particular <a class="ulink" href="http://decloak.net/">decloak.net</a>. 
 
  </p></li><li class="listitem">Disabling plugins
 
- <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
+ <p>Plugins have the ability to make arbitrary OS system calls and  <a class="ulink" href="http://decloak.net/">bypass proxy settings</a>. This includes
 the ability to make UDP sockets and send arbitrary data independent of the
 browser proxy settings.
  </p><p>
 Torbutton disables plugins by using the
 <span class="command"><strong>@mozilla.org/plugin/host;1</strong></span> service to mark the plugin tags
-as disabled. Additionally, we set
-<span class="command"><strong>plugin.disable_full_page_plugin_for_types</strong></span> to the list of
-supported mime types for all currently installed plugins.
+as disabled. This block can be undone through both the Torbutton Security UI,
+and the Firefox Plugin Preferences.
  </p><p>
-In addition, to prevent any unproxied activity by plugins at load time, we
-also patch the Firefox source code to <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.2:/src/current-patches/firefox/0007-Block-all-plugins-except-flash.patch" target="_top">prevent the load of any plugins except
-for Flash and Gnash</a>.
-
+If the user does enable plugins in this way, plugin-handled objects are still
+restricted from automatic load through Firefox's click-to-play preference
+<span class="command"><strong>plugins.click_to_play</strong></span>.
  </p><p>
-
-Finally, even if the user alters their browser settings to re-enable the Flash
-plugin, we have configured NoScript to provide click-to-play placeholders, so
-that only desired objects will be loaded, and only after user confirmation.
+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/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0005-Block-all-plugins-except-flash.patch">prevent the load of any plugins except
+for Flash and Gnash</a>.
 
  </p></li><li class="listitem">External App Blocking
   <p>
 External apps, if launched automatically, can be induced to load files that
 perform network activity. In order to prevent this, Torbutton installs a
 component to 
-<a class="ulink" href="https://gitweb.torproject.org/torbutton.git/blob_plain/HEAD:/src/components/external-app-blocker.js" target="_top">
+<a class="ulink" href="https://gitweb.torproject.org/torbutton.git/blob_plain/HEAD:/src/components/external-app-blocker.js">
 provide the user with a popup</a> whenever the browser attempts to
 launch a helper app. 
 
-Additionally, due primarily to an issue with Ubuntu Unity, url-based drag and drop is
+Additionally, due to an issue with Ubuntu Unity, url-based drag and drop is
 filtered by this component. Unity was pre-fetching URLs without using the
 browser's proxy settings during a drag action, even if the drop was ultimately
-canceled by the user.
-  </p></li></ol></div></div><div class="sect2" title="3.2. State Separation"><div class="titlepage"><div><div><h3 class="title"><a id="state-separation"></a>3.2. State Separation</h3></div></div></div><p>
+canceled by the user. A similar issue was discovered on Mac OS.
+  </p></li></ol></div></div><div class="sect2" title="4.2. State Separation"><div class="titlepage"><div><div><h3 class="title"><a id="state-separation"/>4.2. State Separation</h3></div></div></div><p>
 Tor Browser State is separated from existing browser state through use of a
 custom Firefox profile. Furthermore, plugins are disabled, which prevents
 Flash cookies from leaking from a pre-existing Flash directory.
-   </p></div><div class="sect2" title="3.3. Disk Avoidance"><div class="titlepage"><div><div><h3 class="title"><a id="disk-avoidance"></a>3.3. Disk Avoidance</h3></div></div></div><div class="sect3" title="Design Goal:"><div class="titlepage"><div><div><h4 class="title"><a id="id2652153"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote">
-Tor Browser MUST (at user option) prevent all disk records of browser activity.
+   </p></div><div class="sect2" title="4.3. Disk Avoidance"><div class="titlepage"><div><div><h3 class="title"><a id="disk-avoidance"/>4.3. Disk Avoidance</h3></div></div></div><div class="sect3" title="Design Goal:"><div class="titlepage"><div><div><h4 class="title"><a id="idp5523344"/>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote">
+
+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. Once we <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3100" target="_top">simplify the
-preferences interface</a>, we will likely just enable Private Browsing
-mode by default to handle this goal.
-    </blockquote></div></div><div class="sect3" title="Implementation Status:"><div class="titlepage"><div><div><h4 class="title"><a id="id2650204"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote">
-For now, Tor Browser blocks write access to the disk through Torbutton
-using several Firefox preferences. 
+features if they so desire. 
+
+    </blockquote></div></div><div class="sect3" title="Implementation Status:"><div class="titlepage"><div><div><h4 class="title"><a id="idp5524704"/>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote">
+
+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/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0002-Make-Permissions-Manager-memory-only.patch">prevent
+the permissions manager from recording HTTPS STS state</a>,
+<a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0003-Make-Intermediate-Cert-Store-memory-only.patch">prevent
+intermediate SSL certificates from being recorded</a>,
+<a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0013-Make-Download-manager-memory-only.patch">prevent
+download history from being recorded</a>, and
+<a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0006-Make-content-pref-service-memory-only-clearable.patch">prevent
+the content preferences service from recording site zoom</a>.
 
+For more details on these patches, <a class="link" href="#firefox-patches" title="4.8. Description of Firefox Patches">see the
+Firefox Patches section</a>.
 
+    </blockquote></div><div class="blockquote"><blockquote class="blockquote">
 
-The set of prefs is:
-<span class="command"><strong>dom.storage.enabled</strong></span>,
-<span class="command"><strong>browser.cache.memory.enable</strong></span>,
-<span class="command"><strong>network.http.use-cache</strong></span>,
+As an additional defense-in-depth measure, we set the following preferences:
+<span class="command"><strong/></span>,
 <span class="command"><strong>browser.cache.disk.enable</strong></span>,
 <span class="command"><strong>browser.cache.offline.enable</strong></span>,
-<span class="command"><strong>general.open_location.last_url</strong></span>,
-<span class="command"><strong>places.history.enabled</strong></span>,
-<span class="command"><strong>browser.formfill.enable</strong></span>,
+<span class="command"><strong>dom.indexedDB.enabled</strong></span>,
+<span class="command"><strong>network.cookie.lifetimePolicy</strong></span>,
 <span class="command"><strong>signon.rememberSignons</strong></span>,
+<span class="command"><strong>browser.formfill.enable</strong></span>,
 <span class="command"><strong>browser.download.manager.retention</strong></span>,
-and <span class="command"><strong>network.cookie.lifetimePolicy</strong></span>.
-    </blockquote></div></div><p>
-In addition, three Firefox patches are needed to prevent disk writes, even if
-Private Browsing Mode is enabled. We need to
+<span class="command"><strong>browser.sessionstore.privacy_level</strong></span>,
+and <span class="command"><strong>network.cookie.lifetimePolicy</strong></span>. Many of these
+preferences are likely redundant with
+<span class="command"><strong>browser.privatebrowsing.autostart</strong></span>, but we have not done the
+auditing work to ensure that yet.
 
-<a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.2:/src/current-patches/firefox/0002-Make-Permissions-Manager-memory-only.patch" target="_top">prevent
-the permissions manager from recording HTTPS STS state</a>,
-<a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.2:/src/current-patches/firefox/0003-Make-Intermediate-Cert-Store-memory-only.patch" target="_top">prevent
-intermediate SSL certificates from being recorded</a>, and
-<a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.2:/src/current-patches/firefox/0008-Make-content-pref-service-memory-only-clearable.patch" target="_top">prevent
-the content preferences service from recording site zoom</a>.
+    </blockquote></div><div class="blockquote"><blockquote class="blockquote">
 
-For more details on these patches, <a class="link" href="#firefox-patches" title="3.9. Description of Firefox Patches">see the
-Firefox Patches section</a>.
+Torbutton also <a class="ulink" href="https://gitweb.torproject.org/torbutton.git/blob/HEAD:/src/components/tbSessionStore.js">contains
+code</a> to prevent the Firefox session store from writing to disk.
+    </blockquote></div><div class="blockquote"><blockquote class="blockquote">
 
-   </p></div><div class="sect2" title="3.4. Application Data Isolation"><div class="titlepage"><div><div><h3 class="title"><a id="app-data-isolation"></a>3.4. Application Data Isolation</h3></div></div></div><p>
+For more details on disk leak bugs and enhancements, see the <a class="ulink" href="https://trac.torproject.org/projects/tor/query?keywords=~tbb-disk-leak&amp;status=!closed">tbb-disk-leak tag in our bugtracker</a></blockquote></div></div></div><div class="sect2" title="4.4. Application Data Isolation"><div class="titlepage"><div><div><h3 class="title"><a id="app-data-isolation"/>4.4. Application Data Isolation</h3></div></div></div><p>
 
 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.
 
-   </p><p>FIXME: sjmurdoch, Erinn: explain what magic we do to satisfy this,
-and/or what additional work or auditing needs to be done.
-   </p></div><div class="sect2" title="3.5. Cross-Origin Identifier Unlinkability"><div class="titlepage"><div><div><h3 class="title"><a id="identifier-linkability"></a>3.5. Cross-Origin Identifier Unlinkability</h3></div></div></div><p>
+   </p><p>
+
+To ensure TBB 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.
+   </p></div><div class="sect2" title="4.5. Cross-Origin Identifier Unlinkability"><div class="titlepage"><div><div><h3 class="title"><a id="identifier-linkability"/>4.5. Cross-Origin Identifier Unlinkability</h3></div></div></div><p>
 
 The Tor Browser MUST prevent a user's activity on one site from being linked
 to their activity on another site. When this goal cannot yet be met with an
@@ -544,21 +616,19 @@ the url bar origin for which browser state exists, possibly with a
 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="id2634370"></a><p class="title"><b>Figure 1. Improving the Privacy UI</b></p><div class="figure-contents"><div class="mediaobject" align="center"><img src="CookieManagers.png" align="middle" alt="Improving the Privacy UI" /></div><div class="caption"><p></p>
+   </p><div class="figure"><a id="idp5548704"/><p class="title"><b>Figure 1. Improving the Privacy UI</b></p><div class="figure-contents"><div class="mediaobject" style="text-align: center"><img src="NewCookieManager.png" style="text-align: middle" alt="Improving the Privacy UI"/></div><div class="caption"><p/>
 
-On the left is the standard Firefox cookie manager. On the right is a mock-up
-of how isolating identifiers to the URL bar origin might simplify the privacy
-UI for all data - not just cookies. Both windows represent the set of
-Cookies accumulated after visiting just five sites, but the window on the
-right has the option of also representing history, DOM Storage, HTTP Auth,
-search form history, login values, and so on within a context menu for each
-site.
+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
+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="orderedlist"><ol class="orderedlist" type="1"><li class="listitem">Cookies
+</div></div></div><br class="figure-break"/><div class="orderedlist"><ol class="orderedlist"><li class="listitem">Cookies
      <p><span class="command"><strong>Design Goal:</strong></span>
 
 All cookies MUST be double-keyed to the url bar origin and third-party
-origin. There exists a <a class="ulink" href="https://bugzilla.mozilla.org/show_bug.cgi?id=565965" target="_top">Mozilla bug</a>
+origin. There exists a <a class="ulink" href="https://bugzilla.mozilla.org/show_bug.cgi?id=565965">Mozilla bug</a>
 that contains a prototype patch, but it lacks UI, and does not apply to modern
 Firefoxes.
 
@@ -574,17 +644,17 @@ unlinkability trumps that desire.
      <p>
 
 Cache is isolated to the url bar origin by using a technique pioneered by
-Colin Jackson et al, via their work on <a class="ulink" href="http://www.safecache.com/" target="_top">SafeCache</a>. The technique re-uses the
-<a class="ulink" href="https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsICachingChannel" target="_top">nsICachingChannel.cacheKey</a>
+Colin Jackson et al, via their work on <a class="ulink" href="http://www.safecache.com/">SafeCache</a>. The technique re-uses the
+<a class="ulink" href="https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsICachingChannel">nsICachingChannel.cacheKey</a>
 attribute that Firefox uses internally to prevent improper caching and reuse
 of HTTP POST data.  
 
      </p><p>
 
-However, to <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3666" target="_top">increase the
-security of the isolation</a> and to <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3754" target="_top">solve conflicts
+However, to <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3666">increase the
+security of the isolation</a> and to <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3754">solve conflicts
 with OCSP relying the cacheKey property for reuse of POST requests</a>, we
-had to <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.2:/src/current-patches/firefox/0005-Add-a-string-based-cacheKey.patch" target="_top">patch
+had to <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0004-Add-a-string-based-cacheKey.patch">patch
 Firefox to provide a cacheDomain cache attribute</a>. We use the fully
 qualified url bar domain as input to this field.
 
@@ -599,49 +669,49 @@ opposed to relying solely on the referer property.
 
      </p><p>
 
-Therefore, <a class="ulink" href="http://crypto.stanford.edu/sameorigin/safecachetest.html" target="_top">the original
+Therefore, <a class="ulink" href="http://crypto.stanford.edu/sameorigin/safecachetest.html">the original
 Stanford test cases</a> are expected to fail. Functionality can still be
-verified by navigating to <a class="ulink" href="about:cache" target="_top">about:cache</a> and
+verified by navigating to <a class="ulink" href="about:cache">about:cache</a> and
 viewing the key used for each cache entry. Each third party element should
 have an additional "domain=string" property prepended, which will list the
 FQDN that was used to source the third party element.
 
+     </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/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0024-Isolate-the-Image-Cache-per-url-bar-domain.patch">isolate
+this cache per url bar domain</a>.
+
      </p></li><li class="listitem">HTTP Auth
      <p>
 
 HTTP authentication tokens are removed for third party elements using the
-<a class="ulink" href="https://developer.mozilla.org/en/Setting_HTTP_request_headers#Observers" target="_top">http-on-modify-request
-observer</a> to remove the Authorization headers to prevent <a class="ulink" href="http://jeremiahgrossman.blogspot.com/2007/04/tracking-users-without-cookies.html" target="_top">silent
-linkability between domains</a>.  We also needed to <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.2:/src/current-patches/firefox/0004-Add-HTTP-auth-headers-before-the-modify-request-obse.patch" target="_top">patch
-Firefox to cause the headers to get added early enough</a> to allow the
-observer to modify it.
-
+<a class="ulink" href="https://developer.mozilla.org/en/Setting_HTTP_request_headers#Observers">http-on-modify-request
+observer</a> to remove the Authorization headers to prevent <a class="ulink" href="http://jeremiahgrossman.blogspot.com/2007/04/tracking-users-without-cookies.html">silent
+linkability between domains</a>. 
      </p></li><li class="listitem">DOM Storage
-     <p><span class="command"><strong>Design Goal:</strong></span>
+     <p>
 
 DOM storage for third party domains MUST be isolated to the url bar origin,
-to prevent linkability between sites.
-
-     </p><p><span class="command"><strong>Implementation Status:</strong></span>
-
-Because it is isolated to third party domain as opposed to top level url bar
-origin, we entirely disable DOM storage as a stopgap to ensure unlinkability.
+to prevent linkability between sites. This functionality is provided through a
+<a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0026-Isolate-DOM-storage-to-first-party-URI.patch">patch
+to Firefox</a>.
 
      </p></li><li class="listitem">Flash cookies
      <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
+cookies using the <a class="ulink" href="http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager03.html">Flash
 settings manager</a>.
 
      </p><p><span class="command"><strong>Implementation Status:</strong></span>
 
-We are currently <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3974" target="_top">having
+We are currently <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3974">having
 difficulties</a> causing Flash player to use this settings
 file on Windows, so Flash remains difficult to enable.
 
-     </p></li><li class="listitem">SSL+TLS session resumption and HTTP Keep-Alive
+     </p></li><li class="listitem">SSL+TLS session resumption, HTTP Keep-Alive and SPDY
      <p><span class="command"><strong>Design Goal:</strong></span>
 
 TLS session resumption tickets and SSL Session IDs MUST be limited to the url
@@ -650,24 +720,28 @@ origin MUST NOT be reused for that same third party in another url bar origin.
 
      </p><p><span class="command"><strong>Implementation Status:</strong></span>
 
-We currently clear SSL Session IDs upon <a class="link" href="#new-identity" title="3.7. Long-Term Unlinkability via &quot;New Identity&quot; button">New
+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/torbrowser.git/blob/maint-2.2:/src/current-patches/firefox/0010-Disable-SSL-Session-ID-tracking.patch" target="_top">patch
+IDs via a <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0008-Disable-SSL-Session-ID-tracking.patch">patch
 to Firefox</a>. 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
+<a class="ulink" href="https://tools.ietf.org/html/draft-bmoeller-tls-falsestart-00">TLS
 False Start</a> via the Firefox Pref 
 <span class="command"><strong>security.ssl.enable_false_start</strong></span>.
     </p><p>
 
-Becuase of the extreme performance benefits of HTTP Keep-Alive for interactive
+Because of the extreme performance benefits of HTTP Keep-Alive for interactive
 web apps, and because of the difficulties of conveying urlbar origin
 information down into the Firefox HTTP layer, as a compromise we currently
 merely reduce the HTTP Keep-Alive timeout to 20 seconds (which is measured
 from the last packet read on the connection) using the Firefox preference
 <span class="command"><strong>network.http.keep-alive.timeout</strong></span>.
 
+     </p><p>
+However, because SPDY can store identifiers and has extremely long keepalive
+duration, it is disabled through the Firefox preference
+<span class="command"><strong>network.http.spdy.enabled</strong></span>.
      </p></li><li class="listitem">Automated cross-origin redirects MUST NOT store identifiers
     <p><span class="command"><strong>Design Goal:</strong></span>
 
@@ -687,33 +761,34 @@ federated login systems) SHOULD still allow identifiers to persist.
     </p><p><span class="command"><strong>Implementation status:</strong></span>
 
 There are numerous ways for the user to be redirected, and the Firefox API
-support to detect each of them is poor. We have a <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3600" target="_top">trac bug
+support to detect each of them is poor. We have a <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3600">trac bug
 open</a> to implement what we can.
 
     </p></li><li class="listitem">window.name
      <p>
 
-<a class="ulink" href="https://developer.mozilla.org/En/DOM/Window.name" target="_top">window.name</a> is
+<a class="ulink" href="https://developer.mozilla.org/En/DOM/Window.name">window.name</a> is
 a magical DOM property that for some reason is allowed to retain a persistent value
 for the lifespan of a browser tab. It is possible to utilize this property for
-<a class="ulink" href="http://www.thomasfrank.se/sessionvars.html" target="_top">identifier
+<a class="ulink" href="http://www.thomasfrank.se/sessionvars.html">identifier
 storage</a>.
 
      </p><p>
 
-In order to eliminate linkability but still allow for sites that utilize this
-property to function, we reset the window.name property of tabs in Torbutton every
-time we encounter a blank referer. This behavior allows window.name to persist
-for the duration of a link-driven navigation session, but as soon as the user
-enters a new URL or navigates between https/http schemes, the property is cleared.
+In order to eliminate non-consensual linkability but still allow for sites
+that utilize this property to function, we reset the window.name property of
+tabs in Torbutton every time we encounter a blank referer. This behavior
+allows window.name to persist for the duration of a click-driven navigation
+session, but as soon as the user enters a new URL or navigates between
+https/http schemes, the property is cleared.
 
      </p></li><li class="listitem">Auto form-fill
      <p>
 
 We disable the password saving functionality in the browser as part of our
-<a class="link" href="#disk-avoidance" title="3.3. Disk Avoidance">Disk Avoidance</a> requirement. However,
+<a class="link" href="#disk-avoidance" title="4.3. Disk Avoidance">Disk Avoidance</a> requirement. However,
 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>
+we also set the <a class="ulink" href="http://kb.mozillazine.org/Signon.autofillForms">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
 appear, setting this preference prevents automatic linkability from stored passwords.
@@ -721,7 +796,7 @@ appear, setting this preference prevents automatic linkability from stored passw
      </p></li><li class="listitem">HSTS supercookies
       <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">HSTS
 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.
@@ -735,7 +810,7 @@ Restrict the number of HSTS-enabled third parties allowed per url bar origin.
 the best approach.
 
       </p><p><span class="command"><strong>Implementation Status:</strong></span> Currently, HSTS state is
-cleared by <a class="link" href="#new-identity" title="3.7. Long-Term Unlinkability via &quot;New Identity&quot; button">New Identity</a>, but we don't
+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 of these cookies between <span class="command"><strong>New
 Identity</strong></span> invocations.
       </p></li><li class="listitem">Exit node usage
@@ -748,39 +823,46 @@ observers from linking concurrent browsing activity.
      </p><p><span class="command"><strong>Implementation Status:</strong></span>
 
 The Tor feature that supports this ability only exists in the 0.2.3.x-alpha
-series. <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3455" target="_top">Ticket
+series. <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3455">Ticket
 #3455</a> is the Torbutton ticket to make use of the new Tor
 functionality.
 
-     </p></li></ol></div></div><div class="sect2" title="3.6. Cross-Origin Fingerprinting Unlinkability"><div class="titlepage"><div><div><h3 class="title"><a id="fingerprinting-linkability"></a>3.6. Cross-Origin Fingerprinting Unlinkability</h3></div></div></div><p>
+     </p></li></ol></div><p>
+For more details on identifier linkability bugs and enhancements, see the <a class="ulink" href="https://trac.torproject.org/projects/tor/query?keywords=~tbb-linkability&amp;status=!closed">tbb-linkability tag in our bugtracker</a>
+  </p></div><div class="sect2" title="4.6. Cross-Origin Fingerprinting Unlinkability"><div class="titlepage"><div><div><h3 class="title"><a id="fingerprinting-linkability"/>4.6. Cross-Origin Fingerprinting Unlinkability</h3></div></div></div><p>
 
 In order to properly address the fingerprinting adversary on a technical
 level, we need a metric to measure linkability of the various browser
-properties beyond any stored origin-related state. <a class="ulink" href="https://panopticlick.eff.org/about.php" target="_top">The Panopticlick Project</a>
-by the EFF provides us with exactly this metric. The researchers conducted a
-survey of volunteers who were asked to visit an experiment page that harvested
-many of the above components. They then computed the Shannon Entropy of the
-resulting distribution of each of several key attributes to determine how many
-bits of identifying information each attribute provided.
+properties beyond any stored origin-related state. <a class="ulink" href="https://panopticlick.eff.org/about.php">The Panopticlick Project</a>
+by the EFF provides us with a prototype of such a metric. The researchers
+conducted a survey of volunteers who were asked to visit an experiment page
+that harvested many of the above components. They then computed the Shannon
+Entropy of the resulting distribution of each of several key attributes to
+determine how many bits of identifying information each attribute provided.
 
    </p><p>
 
-The study is not exhaustive, though. In particular, the test does not take in
-all aspects of resolution information. It did not calculate the size of
-widgets, window decoration, or toolbar size, which we believe may add high
-amounts of entropy. It also did not measure clock offset and other time-based
-fingerprints. Furthermore, as new browser features are added, this experiment
-should be repeated to include them.
+Many browser features have been added since the EFF first ran their experiment
+and collected their data. To avoid an infinite sinkhole, we reduce the efforts
+for fingerprinting resistance by only concerning ourselves with reducing the
+fingerprintable differences <span class="emphasis"><em>among</em></span> Tor Browser users. We
+do not believe it is possible to solve cross-browser fingerprinting issues.
 
    </p><p>
 
-On the other hand, to avoid an infinite sinkhole, we reduce the efforts for
-fingerprinting resistance by only concerning ourselves with reducing the
-fingerprintable differences <span class="emphasis"><em>among</em></span> Tor Browser users. We
-do not believe it is productive to concern ourselves with cross-browser
-fingerprinting issues, at least not at this stage.
-
-   </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem">Plugins
+Unfortunately, the unsolvable nature of the cross-browser fingerprinting
+problem means that the Panopticlick test website itself is not useful for
+evaluating the actual effectiveness of our defenses, or the fingerprinting
+defenses of any other web browser. Because the Panopticlick dataset is based
+on browser data spanning a number of widely deployed browsers over a number of
+years, any fingerprinting defenses attempted by browsers today are very likely
+to cause Panopticlick to report an <span class="emphasis"><em>increase</em></span> in
+fingerprintability and entropy, because those defenses will stand out in sharp
+contrast to historical data. We have been <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/6119">working to convince
+the EFF</a> that it is worthwhile to release the source code to
+Panopticlick to allow us to run our own version for this reason.
+
+   </p><div class="sect3" title="Fingerprinting defenses in the Tor Browser"><div class="titlepage"><div><div><h4 class="title"><a id="fingerprinting-defenses"/>Fingerprinting defenses in the Tor Browser</h4></div></div></div><div class="orderedlist"><ol class="orderedlist"><li class="listitem">Plugins
      <p>
 
 Plugins add to fingerprinting risk via two main vectors: their mere presence in
@@ -792,17 +874,63 @@ All plugins that have not been specifically audited or sandboxed MUST be
 disabled. To reduce linkability potential, even sandboxed plugins should not
 be allowed to load objects until the user has clicked through a click-to-play
 barrier.  Additionally, version information should be reduced or obfuscated
-until the plugin object is loaded.
+until the plugin object is loaded. For flash, we wish to <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3974">provide a
+settings.sol file</a> to disable Flash cookies, and to restrict P2P
+features that are likely to bypass proxy settings.
 
      </p><p><span class="command"><strong>Implementation Status:</strong></span>
 
 Currently, we entirely disable all plugins in Tor Browser. However, as a
-compromise due to the popularity of Flash, we intend to <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3974" target="_top">work
-towards</a> a
-click-to-play barrier using NoScript that is available only after the user has
-specifically enabled plugins. Flash will be the only plugin available, and we
-will ship a settings.sol file to disable Flash cookies, and to restrict P2P
-features that likely bypass proxy settings.
+compromise due to the popularity of Flash, we allow users to re-enable Flash,
+and flash objects are blocked behind a click-to-play barrier that is available
+only after the user has specifically enabled plugins. Flash is the only plugin
+available, the rest are <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0005-Block-all-plugins-except-flash.patch">entirely
+blocked from loading by a Firefox patch</a>. We also set the Firefox
+preference <span class="command"><strong>plugin.expose_full_path</strong></span> to false, to avoid
+leaking plugin installation information.
+
+     </p></li><li class="listitem">HTML5 Canvas Image Extraction
+     <p>
+
+The <a class="ulink" href="https://developer.mozilla.org/en-US/docs/HTML/Canvas">HTML5
+Canvas</a> is a feature that has been added to major browsers after the
+EFF developed their Panopticlick study. After plugins and plugin-provided
+information, we believe that the HTML5 Canvas is the single largest
+fingerprinting threat browsers face today. <a class="ulink" href="http://www.w2spconf.com/2012/papers/w2sp12-final4.pdf">Initial
+studies</a> show that the Canvas can provide an easy-access fingerprinting
+target: The adversary simply renders WebGL, font, and named color data to a
+Canvas element, extracts the image buffer, and computes a hash of that image
+data. Subtle differences in the video card, font packs, and even font and
+graphics library versions allow the adversary to produce a stable, simple,
+high-entropy fingerprint of a computer. In fact, the hash of the rendered
+image can be used almost identically to a tracking cookie by the web server.
+
+     </p><p>
+
+To reduce the threat from this vector, we have patched Firefox to <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0020-Add-canvas-image-extraction-prompt.patch">prompt
+before returning valid image data</a> to the Canvas APIs. If the user
+hasn't previously allowed the site in the URL bar to access Canvas image data,
+pure white image data is returned to the Javascript APIs.
+
+     </p></li><li class="listitem">WebGL
+     <p>
+
+WebGL is fingerprintable both through information that is exposed about the
+underlying driver and optimizations, as well as through performance
+fingerprinting.
+
+     </p><p>
+
+Because of the large amount of potential fingerprinting vectors and the <a class="ulink" href="http://www.contextis.com/resources/blog/webgl/">previously unexposed
+vulnerability surface</a>, we deploy a similar strategy against WebGL as
+for plugins. First, WebGL Canvases have click-to-play placeholders (provided
+by NoScript), and do not run until authorized by the user. Second, we
+obfuscate driver information by setting the Firefox preferences
+<span class="command"><strong>webgl.disable-extensions</strong></span> and
+<span class="command"><strong>webgl.min_capability_mode</strong></span>, which reduce the information
+provided by the following WebGL API calls: <span class="command"><strong>getParameter()</strong></span>,
+<span class="command"><strong>getSupportedExtensions()</strong></span>, and
+<span class="command"><strong>getExtension()</strong></span>.
 
      </p></li><li class="listitem">Fonts
      <p>
@@ -819,7 +947,7 @@ still be available.
 The sure-fire way to address font linkability is to ship the browser with a
 font for every language, typeface, and style in use in the world, and to only
 use those fonts at the exclusion of system fonts.  However, this set may be
-impractically large. It is possible that a smaller <a class="ulink" href="https://secure.wikimedia.org/wikipedia/en/wiki/Unicode_typeface#List_of_Unicode_fonts" target="_top">common
+impractically large. It is possible that a smaller <a class="ulink" href="https://secure.wikimedia.org/wikipedia/en/wiki/Unicode_typeface#List_of_Unicode_fonts">common
 subset</a> may be found that provides total coverage. However, we believe
 that with strong url bar origin identifier isolation, a simpler approach can reduce the
 number of bits available to the adversary while avoiding the rendering and
@@ -829,35 +957,27 @@ language issues of supporting a global font set.
 
 We disable plugins, which prevents font enumeration. Additionally, we limit
 both the number of font queries from CSS, as well as the total number of 
-fonts that can be used in a document by patching Firefox. We create two prefs,
+fonts that can be used in a document <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0011-Limit-the-number-of-fonts-per-document.patch">with
+a Firefox patch</a>. We create two prefs,
 <span class="command"><strong>browser.display.max_font_attempts</strong></span> and
 <span class="command"><strong>browser.display.max_font_count</strong></span> for this purpose. Once these
 limits are reached, the browser behaves as if
 <span class="command"><strong>browser.display.use_document_fonts</strong></span> was reached. We are
 still working to determine optimal values for these prefs.
 
-     </p></li><li class="listitem">User Agent and HTTP Headers
-     <p><span class="command"><strong>Design Goal:</strong></span>
-
-All Tor Browser users MUST provide websites with an identical user agent and
-HTTP header set for a given request type. We omit the Firefox minor revision,
-and report a popular Windows platform. If the software is kept up to date,
-these headers should remain identical across the population even when updated.
+     </p><p>
 
-     </p><p><span class="command"><strong>Implementation Status:</strong></span>
+To improve rendering, we exempt remote <a class="ulink" href="https://developer.mozilla.org/en-US/docs/CSS/@font-face">@font-face
+fonts</a> from these counts, and if a font-family CSS rule lists a remote
+font (in any order), we use that font instead of any of the named local fonts.
 
-Firefox provides several options for controlling the browser user agent string
-which we leverage. We also set similar prefs for controlling the
-Accept-Language and Accept-Charset headers, which we spoof to English by default. Additionally, we
-<a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.2:/src/current-patches/firefox/0001-Block-Components.interfaces-lookupMethod-from-conten.patch" target="_top">remove
-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
-used</a> to fingerprint OS, platform, and Firefox minor version.  </p></li><li class="listitem">Desktop resolution and CSS Media Queries
+     </p></li><li class="listitem">Desktop resolution, CSS Media Queries, and System Colors
      <p>
 
-Both CSS and Javascript have a lot of irrelevant information about the screen
-resolution, usable desktop size, OS widget size, toolbar size, title bar size, and
-other desktop features that are not at all relevant to rendering and serve
-only to provide information for fingerprinting.
+Both CSS and Javascript have access to a lot of information about the screen
+resolution, usable desktop size, OS widget size, toolbar size, title bar size,
+system theme colors, and other desktop features that are not at all relevant
+to rendering and serve only to provide information for fingerprinting.
 
      </p><p><span class="command"><strong>Design Goal:</strong></span>
 
@@ -867,23 +987,36 @@ report all rendering information correctly with respect to the size and
 properties of the content window, but report an effective size of 0 for all
 border material, and also report that the desktop is only as big as the
 inner content window. Additionally, new browser windows are sized such that 
-their content windows are one of ~5 fixed sizes based on the user's
+their content windows are one of a few fixed sizes based on the user's
 desktop resolution.
 
      </p><p><span class="command"><strong>Implementation Status:</strong></span>
 
-We have implemented the above strategy for Javascript using Torbutton's <a class="ulink" href="https://gitweb.torproject.org/torbutton.git/blob/HEAD:/src/chrome/content/jshooks4.js" target="_top">JavaScript
-hooks</a> as well as a window observer to <a class="ulink" href="https://gitweb.torproject.org/torbutton.git/blob/HEAD:/src/chrome/content/torbutton.js#l4002" target="_top">resize
+We have implemented the above strategy using a window observer to <a class="ulink" href="https://gitweb.torproject.org/torbutton.git/blob/HEAD:/src/chrome/content/torbutton.js#l2004">resize
 new windows based on desktop resolution</a>. Additionally, we patch
-Firefox to cause CSS Media Queries to use the client content window size
-for all desktop size related media queries.  
+Firefox to use the client content window size <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0022-Do-not-expose-physical-screen-info.-via-window-and-w.patch">for
+window.screen</a> and <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0010-Limit-device-and-system-specific-CSS-Media-Queries.patch">for
+CSS Media Queries</a>. Similarly, we <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0021-Return-client-window-coordinates-for-mouse-event-scr.patch">patch
+DOM events to return content window relative points</a>. We also patch
+Firefox to <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0023-Do-not-expose-system-colors-to-CSS-or-canvas.patch">report
+a fixed set of system colors to content window CSS</a>.
 
-     </p><p>
+     </p></li><li class="listitem">User Agent and HTTP Headers
+     <p><span class="command"><strong>Design Goal:</strong></span>
+
+All Tor Browser users MUST provide websites with an identical user agent and
+HTTP header set for a given request type. We omit the Firefox minor revision,
+and report a popular Windows platform. If the software is kept up to date,
+these headers should remain identical across the population even when updated.
 
-As far as we know, this fully satisfies our design goals for desktop
-resolution information.
+     </p><p><span class="command"><strong>Implementation Status:</strong></span>
 
-     </p></li><li class="listitem">Timezone and clock offset
+Firefox provides several options for controlling the browser user agent string
+which we leverage. We also set similar prefs for controlling the
+Accept-Language and Accept-Charset headers, which we spoof to English by default. Additionally, we
+<a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0001-Block-Components.interfaces-from-content.patch">remove
+content script access</a> to Components.interfaces, which <a class="ulink" href="http://pseudo-flaw.net/tor/torbutton/fingerprint-firefox.html">can be
+used</a> to fingerprint OS, platform, and Firefox minor version.  </p></li><li class="listitem">Timezone and clock offset
      <p><span class="command"><strong>Design Goal:</strong></span>
 
 All Tor Browser users MUST report the same timezone to websites. Currently, we
@@ -897,26 +1030,26 @@ values used in Tor Browser to something reasonably accurate.
      </p><p><span class="command"><strong>Implementation Status:</strong></span>
 
 We set the timezone using the TZ environment variable, which is supported on
-all platforms. Additionally, we plan to <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3652" target="_top">obtain a clock
+all platforms. Additionally, we plan to <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3652">obtain a clock
 offset from Tor</a>, but this won't be available until Tor 0.2.3.x is in
 use.
 
      </p></li><li class="listitem">Javascript performance fingerprinting
      <p>
 
-<a class="ulink" href="http://w2spconf.com/2011/papers/jspriv.pdf" target="_top">Javascript performance
+<a class="ulink" href="http://w2spconf.com/2011/papers/jspriv.pdf">Javascript performance
 fingerprinting</a> is the act of profiling the performance
 of various Javascript functions for the purpose of fingerprinting the
 Javascript engine and the CPU.
 
      </p><p><span class="command"><strong>Design Goal:</strong></span>
 
-We have <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3059" target="_top">several potential
+We have <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3059">several potential
 mitigation approaches</a> to reduce the accuracy of performance
 fingerprinting without risking too much damage to functionality. Our current
 favorite is to reduce the resolution of the Event.timeStamp and the Javascript
 Date() object, while also introducing jitter. Our goal is to increase the
-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
+amount of time it takes to mount a successful attack. <a class="ulink" href="http://w2spconf.com/2011/papers/jspriv.pdf">Mowery et al</a> found that
 even with the default precision in most browsers, they required up to 120
 seconds of amortization and repeated trials to get stable results from their
 feature set. We intend to work with the research community to establish the
@@ -925,7 +1058,20 @@ optimum trade-off between quantization+jitter and amortization time.
 
      </p><p><span class="command"><strong>Implementation Status:</strong></span>
 
-We have no implementation as of yet.
+Currently, the only mitigation against performance fingerprinting is to
+disable <a class="ulink" href="http://www.w3.org/TR/navigation-timing/">Navigation
+Timing</a> through the Firefox preference
+<span class="command"><strong>dom.enable_performance</strong></span>.
+
+     </p></li><li class="listitem">Non-Uniform HTML5 API Implementations
+     <p>
+
+At least two HTML5 features have different implementation status across the
+major OS vendors: the <a class="ulink" href="https://developer.mozilla.org/en-US/docs/DOM/window.navigator.battery">Battery
+API</a> and the <a class="ulink" href="https://developer.mozilla.org/en-US/docs/DOM/window.navigator.connection">Network
+Connection API</a>. We disable these APIs
+through the Firefox preferences <span class="command"><strong>dom.battery.enabled</strong></span> and
+<span class="command"><strong>dom.network.enabled</strong></span>. 
 
      </p></li><li class="listitem">Keystroke fingerprinting
      <p>
@@ -940,90 +1086,71 @@ fingerprinting: timestamp quantization and jitter.
 
      </p><p><span class="command"><strong>Implementation Status:</strong></span>
 We have no implementation as of yet.
-     </p></li><li class="listitem">WebGL
-     <p>
+     </p></li></ol></div></div><p>
+For more details on identifier linkability bugs and enhancements, see the <a class="ulink" href="https://trac.torproject.org/projects/tor/query?keywords=~tbb-fingerprinting&amp;status=!closed">tbb-fingerprinting tag in our bugtracker</a>
+  </p></div><div class="sect2" title="4.7. Long-Term Unlinkability via &quot;New Identity&quot; button"><div class="titlepage"><div><div><h3 class="title"><a id="new-identity"/>4.7. Long-Term Unlinkability via "New Identity" button</h3></div></div></div><p>
 
-WebGL is fingerprintable both through information that is exposed about the
-underlying driver and optimizations, as well as through performance
-fingerprinting.
+In order to avoid long-term linkability, we provide a "New Identity" context
+menu option in Torbutton. This context menu option is active if Torbutton can
+read the environment variables $TOR_CONTROL_PASSWD and $TOR_CONTROL_PORT.
 
-     </p><p><span class="command"><strong>Design Goal:</strong></span>
+   </p><div class="sect3" title="Design Goal:"><div class="titlepage"><div><div><h4 class="title"><a id="idp5665856"/>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote">
 
-Because of the large amount of potential fingerprinting vectors, we intend to
-deploy a similar strategy against WebGL as for plugins. First, WebGL canvases
-will have click-to-play placeholders, and will not run until authorized by the
-user. Second, we intend to <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3323" target="_top">obfuscate driver
-information</a> by hooking
-<span class="command"><strong>getParameter()</strong></span>,
-<span class="command"><strong>getSupportedExtensions()</strong></span>,
-<span class="command"><strong>getExtension()</strong></span>, and
-<span class="command"><strong>getContextAttributes()</strong></span> to provide standard minimal,
-driver-neutral information.
+All linkable identifiers and browser state MUST be cleared by this feature.
 
-     </p><p><span class="command"><strong>Implementation Status:</strong></span>
+    </blockquote></div></div><div class="sect3" title="Implementation Status:"><div class="titlepage"><div><div><h4 class="title"><a id="idp5667104"/>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p>
 
-Currently we simply disable WebGL. 
+First, Torbutton disables Javascript in all open tabs and windows by using
+both the <a class="ulink" href="https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIDocShell#Attributes">browser.docShell.allowJavascript</a>
+attribute as well as <a class="ulink" href="https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIDOMWindowUtils#suppressEventHandling%28%29">nsIDOMWindowUtil.suppressEventHandling()</a>.
+We then stop all page activity for each tab using <a class="ulink" href="https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIWebNavigation#stop%28%29">browser.webNavigation.stop(nsIWebNavigation.STOP_ALL)</a>.
+We then clear the site-specific Zoom by temporarily disabling the preference
+<span class="command"><strong>browser.zoom.siteSpecific</strong></span>, and clear the GeoIP wiki token
+URL and the last opened URL prefs (if they exist). Each tab is then closed.
 
-     </p></li></ol></div></div><div class="sect2" title="3.7. Long-Term Unlinkability via &quot;New Identity&quot; button"><div class="titlepage"><div><div><h3 class="title"><a id="new-identity"></a>3.7. Long-Term Unlinkability via "New Identity" button</h3></div></div></div><p>
-In order to avoid long-term linkability, we provide a "New Identity" context
-menu option in Torbutton.
-   </p><div class="sect3" title="Design Goal:"><div class="titlepage"><div><div><h4 class="title"><a id="id2637889"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote">
+     </p><p>
 
-All linkable identifiers and browser state MUST be cleared by this feature.
+After closing all tabs, we then clear the following state: searchbox and
+findbox text, HTTP auth, SSL state, OCSP state, site-specific content
+preferences (including HSTS state), content and image cache, Cookies, DOM
+storage, safe browsing key, and the Google wifi geolocation token (if it
+exists). 
 
-    </blockquote></div></div><div class="sect3" title="Implementation Status:"><div class="titlepage"><div><div><h4 class="title"><a id="id2630536"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote">
-
-First, Torbutton disables all open tabs and windows by tagging them and
-blocking them via the nsIContentPolicy, and then closes each tab and
-window. The extra step for blocking tabs is done as a precaution to ensure
-that any asynchronous Javascript is in fact properly disabled. After closing
-all of the windows, we then clear the following state: OCSP (by toggling
-security.OCSP.enabled), cache, site-specific zoom and content preferences,
-Cookies, DOM storage, safe browsing key, the Google wifi geolocation token (if
-exists), HTTP auth, SSL Session IDs, HSTS state, close all remaining HTTP
-keep-alive connections, and clear the last opened URL field (via the pref
-general.open_location.last_url).  After clearing the browser state, we then
-send the NEWNYM signal to the Tor control port to cause a new circuit to be
-created.
+     </p><p>
 
-    </blockquote></div><div class="blockquote"><blockquote class="blockquote">
-Additionally, the user is allowed to "protect" cookies of their choosing from
-deletion during New Identity by using the Torbutton Cookie Protections UI to
-protect the cookies they would like to keep across New Identity invocations.
-    </blockquote></div></div></div><div class="sect2" title="3.8. Click-to-play for plugins and invasive content"><div class="titlepage"><div><div><h3 class="title"><a id="click-to-play"></a>3.8. Click-to-play for plugins and invasive content</h3></div></div></div><p>
-Some content types are too invasive and/or too opaque for us to properly
-eliminate their linkability properties. For these content types, we use
-NoScript to provide click-to-play placeholders that do not activate the
-content until the user clicks on it. This will eliminate the ability for an
-adversary to use such content types to link users in a dragnet fashion across
-arbitrary sites.
+After the state is cleared, we then close all remaining HTTP keep-alive
+connections and then send the NEWNYM signal to the Tor control port to cause a
+new circuit to be created.
      </p><p>
-Currently, the content types isolated in this way include Flash, WebGL, and
-audio and video objects.
-   </p></div><div class="sect2" title="3.9. Description of Firefox Patches"><div class="titlepage"><div><div><h3 class="title"><a id="firefox-patches"></a>3.9. Description of Firefox Patches</h3></div></div></div><p>
-The set of patches we have against Firefox can be found in the <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/tree/maint-2.2:/src/current-patches/firefox" target="_top">current-patches directory of the torbrowser git repository</a>. They are:
-   </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem">Block Components.interfaces and Components.lookupMethod
-     <p>
+Finally, a fresh browser window is opened, and the current browser window is
+closed.
+     </p></blockquote></div><div class="blockquote"><blockquote class="blockquote">
+If the user chose to "protect" any cookies by using the Torbutton Cookie
+Protections UI, those cookies are not cleared as part of the above.
+    </blockquote></div></div></div><div class="sect2" title="4.8. Description of Firefox Patches"><div class="titlepage"><div><div><h3 class="title"><a id="firefox-patches"/>4.8. Description of Firefox Patches</h3></div></div></div><p>
 
-In order to reduce fingerprinting, we block access to these two interfaces
-from content script. Components.lookupMethod can undo our <a class="ulink" href="https://gitweb.torproject.org/torbutton.git/blob/HEAD:/src/chrome/content/jshooks4.js" target="_top">Javascript
-hooks</a>,
-and Components.interfaces can be used for fingerprinting the platform, OS, and
-Firebox version, but not much else.
+The set of patches we have against Firefox can be found in the <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/tree/maint-2.4:/src/current-patches/firefox">current-patches directory of the torbrowser git repository</a>. They are:
 
-     </p></li><li class="listitem">Make Permissions Manager memory only
-     <p>
+   </p><div class="orderedlist"><ol class="orderedlist"><li class="listitem"><a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0001-Block-Components.interfaces-from-content.patch">Block
+Components.interfaces</a><p>
+
+In order to reduce fingerprinting, we block access to this interface from
+content script. Components.interfaces can be used for fingerprinting the
+platform, OS, and Firebox version, but not much else.
+
+     </p></li><li class="listitem"><a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0002-Make-Permissions-Manager-memory-only.patch">Make
+Permissions Manager memory only</a><p>
 
 This patch exposes a pref 'permissions.memory_only' that properly isolates the
 permissions manager to memory, which is responsible for all user specified
-site permissions, as well as stored <a class="ulink" href="https://secure.wikimedia.org/wikipedia/en/wiki/HTTP_Strict_Transport_Security" target="_top">HSTS</a>
+site permissions, as well as stored <a class="ulink" href="https://secure.wikimedia.org/wikipedia/en/wiki/HTTP_Strict_Transport_Security">HSTS</a>
 policy from visited sites.
 
 The pref does successfully clear the permissions manager memory if toggled. It
 does not need to be set in prefs.js, and can be handled by Torbutton.
 
-     </p></li><li class="listitem">Make Intermediate Cert Store memory-only
-     <p>
+     </p></li><li class="listitem"><a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0003-Make-Intermediate-Cert-Store-memory-only.patch">Make
+Intermediate Cert Store memory-only</a><p>
 
 The intermediate certificate store records the intermediate SSL certificates
 the browser has seen to date. Because these intermediate certificates are used 
@@ -1037,153 +1164,257 @@ As an additional design goal, we would like to later alter this patch to allow t
 information to be cleared from memory. The implementation does not currently
 allow this.
 
-     </p></li><li class="listitem">Add HTTP auth headers before on-modify-request fires
-     <p>
-
-This patch provides a trivial modification to allow us to properly remove HTTP
-auth for third parties. This patch allows us to defend against an adversary
-attempting to use <a class="ulink" href="http://jeremiahgrossman.blogspot.com/2007/04/tracking-users-without-cookies.html" target="_top">HTTP
-auth to silently track users between domains</a>.
+     </p></li><li class="listitem"><a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0004-Add-a-string-based-cacheKey.patch">Add
+a string-based cacheKey property for domain isolation</a><p>
 
-     </p></li><li class="listitem">Add a string-based cacheKey property for domain isolation
-     <p>
-
-To <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3666" target="_top">increase the
-security of cache isolation</a> and to <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3754" target="_top">solve strange and
-unknown conflicts with OCSP</a>, we had to <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/refs/heads/maint-2.2:/src/current-patches/0005-Add-a-string-based-cacheKey.patch" target="_top">patch
-Firefox to provide a cacheDomain cache attribute</a>. We use the url bar
+To <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3666">increase the
+security of cache isolation</a> and to <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3754">solve strange and
+unknown conflicts with OCSP</a>, we had to patch
+Firefox to provide a cacheDomain cache attribute. We use the url bar
 FQDN as input to this field.
 
-     </p></li><li class="listitem">Randomize HTTP pipeline order and depth
-     <p>
-As an 
-<a class="ulink" href="https://blog.torproject.org/blog/experimental-defense-website-traffic-fingerprinting" target="_top">experimental
-defense against Website Traffic Fingerprinting</a>, we patch the standard
-HTTP pipelining code to randomize the number of requests in a
-pipeline, as well as their order.
-     </p></li><li class="listitem">Block all plugins except flash
-     <p>
-We cannot use the <a class="ulink" href="http://www.oxymoronical.com/experiments/xpcomref/applications/Firefox/3.5/components/@mozilla.org/extensions/blocklist%3B1" target="_top">
+     </p></li><li class="listitem"><a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0005-Block-all-plugins-except-flash.patch">Block
+all plugins except flash</a><p>
+We cannot use the <a class="ulink" href="http://www.oxymoronical.com/experiments/xpcomref/applications/Firefox/3.5/components/@mozilla.org/extensions/blocklist%3B1">
 @mozilla.org/extensions/blocklist;1</a> service, because we
 actually want to stop plugins from ever entering the browser's process space
 and/or executing code (for example, AV plugins that collect statistics/analyze
-URLs, magical toolbars that phone home or "help" the user, skype buttons that
+URLs, magical toolbars that phone home or "help" the user, Skype buttons that
 ruin our day, and censorship filters). Hence we rolled our own.
-     </p></li><li class="listitem">Make content-prefs service memory only
-     <p>
-This patch prevents random URLs from being inserted into content-prefs.sqllite in
+     </p></li><li class="listitem"><a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0006-Make-content-pref-service-memory-only-clearable.patch">Make content-prefs service memory only</a><p>
+This patch prevents random URLs from being inserted into content-prefs.sqlite in
 the profile directory as content prefs change (includes site-zoom and perhaps
 other site prefs?).
-     </p></li><li class="listitem">Make Tor Browser exit when not launched from Vidalia
-     <p>
+     </p></li><li class="listitem"><a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0007-Make-Tor-Browser-exit-when-not-launched-from-Vidalia.patch">Make Tor Browser exit when not launched from Vidalia</a><p>
 
 It turns out that on Windows 7 and later systems, the Taskbar attempts to
 automatically learn the most frequent apps used by the user, and it recognizes
-Tor Browser as a seperate app from Vidalia. This can cause users to try to
-launch Tor Brower without Vidalia or a Tor instance running. Worse, the Tor
+Tor Browser as a separate app from Vidalia. This can cause users to try to
+launch Tor Browser without Vidalia or a Tor instance running. Worse, the Tor
 Browser will automatically find their default Firefox profile, and properly
 connect directly without using Tor. This patch is a simple hack to cause Tor
 Browser to immediately exit in this case.
 
-     </p></li><li class="listitem">Disable SSL Session ID tracking
-     <p>
+     </p></li><li class="listitem"><a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0008-Disable-SSL-Session-ID-tracking.patch">Disable SSL Session ID tracking</a><p>
 
 This patch is a simple 1-line hack to prevent SSL connections from caching
 (and then later transmitting) their Session IDs. There was no preference to
 govern this behavior, so we had to hack it by altering the SSL new connection
 defaults.
 
-     </p></li><li class="listitem">Provide an observer event to close persistent connections
-     <p>
+     </p></li><li class="listitem"><a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0009-Provide-an-observer-event-to-close-persistent-connec.patch">Provide an observer event to close persistent connections</a><p>
 
 This patch creates an observer event in the HTTP connection manager to close
 all keep-alive connections that still happen to be open. This event is emitted
-by the <a class="link" href="#new-identity" title="3.7. Long-Term Unlinkability via &quot;New Identity&quot; button">New Identity</a> button.
+by the <a class="link" href="#new-identity" title="4.7. Long-Term Unlinkability via &quot;New Identity&quot; button">New Identity</a> button.
+
+     </p></li><li class="listitem"><a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0010-Limit-device-and-system-specific-CSS-Media-Queries.patch">Limit Device and System Specific Media Queries</a><p>
+
+<a class="ulink" href="https://developer.mozilla.org/en-US/docs/CSS/Media_queries">CSS
+Media Queries</a> have a fingerprinting capability approaching that of
+Javascript. This patch causes such Media Queries to evaluate as if the device
+resolution was equal to the content window resolution.
+
+     </p></li><li class="listitem"><a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0011-Limit-the-number-of-fonts-per-document.patch">Limit the number of fonts per document</a><p>
+
+Font availability can be <a class="ulink" href="http://flippingtypical.com/">queried by
+CSS and Javascript</a> and is a fingerprinting vector. This patch limits
+the number of times CSS and Javascript can cause font-family rules to
+evaluate. Remote @font-face fonts are exempt from the limits imposed by this
+patch, and remote fonts are given priority over local fonts whenever both
+appear in the same font-family rule.
+
+     </p></li><li class="listitem"><a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0012-Rebrand-Firefox-to-TorBrowser.patch">Rebrand Firefox to Tor Browser</a><p>
+
+This patch updates our branding in compliance with Mozilla's trademark policy.
+
+     </p></li><li class="listitem"><a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0013-Make-Download-manager-memory-only.patch">Make Download Manager Memory Only</a><p>
+
+This patch prevents disk leaks from the download manager. The original
+behavior is to write the download history to disk and then delete it, even if
+you disable download history from your Firefox preferences.
+
+     </p></li><li class="listitem"><a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0014-Add-DDG-and-StartPage-to-Omnibox.patch">Add DDG and StartPage to Omnibox</a><p>
+
+This patch adds DuckDuckGo and StartPage to the Search Box, and sets our
+default search engine to StartPage. We deployed this patch due to excessive
+Captchas and complete 403 bans from Google.
+
+     </p></li><li class="listitem"><a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0015-Make-nsICacheService.EvictEntries-synchronous.patch">Make nsICacheService.EvictEntries() Synchronous</a><p>
+
+This patch eliminates a race condition with "New Identity". Without it,
+cache-based Evercookies survive for up to a minute after clearing the cache
+on some platforms.
+
+     </p></li><li class="listitem"><a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0016-Prevent-WebSocket-DNS-leak.patch">Prevent WebSockets DNS Leak</a><p>
+
+This patch prevents a DNS leak when using WebSockets. It also prevents other
+similar types of DNS leaks.
+
+     </p></li><li class="listitem"><a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0017-Randomize-HTTP-request-order-and-pipeline-depth.patch">Randomize HTTP pipeline order and depth</a><p>
+As an 
+<a class="ulink" href="https://blog.torproject.org/blog/experimental-defense-website-traffic-fingerprinting">experimental
+defense against Website Traffic Fingerprinting</a>, we patch the standard
+HTTP pipelining code to randomize the number of requests in a
+pipeline, as well as their order.
+     </p></li><li class="listitem"><a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0018-Adapt-Steven-Michaud-s-Mac-crashfix-patch.patch">Adapt Steve Michaud's Mac crashfix patch</a><p>
+
+This patch allows us to block Drag and Drop without causing crashes on Mac OS.
+We need to block Drag and Drop because Mac OS and Ubuntu both immediately load
+any URLs they find in your drag buffer before you even drop them (without
+using your browser's proxy settings, of course).
+
+     </p></li><li class="listitem"><a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0019-Add-mozIThirdPartyUtil.getFirstPartyURI-API.patch">Add mozIThirdPartyUtil.getFirstPartyURI() API</a><p>
 
-     </p></li></ol></div></div></div><div class="sect1" title="4. Packaging"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Packaging"></a>4. Packaging</h2></div></div></div><p> </p><div class="sect2" title="4.1. Build Process Security"><div class="titlepage"><div><div><h3 class="title"><a id="build-security"></a>4.1. Build Process Security</h3></div></div></div><p> </p></div><div class="sect2" title="4.2. External Addons"><div class="titlepage"><div><div><h3 class="title"><a id="addons"></a>4.2. External Addons</h3></div></div></div><p> </p><div class="sect3" title="Included Addons"><div class="titlepage"><div><div><h4 class="title"><a id="id2611402"></a>Included Addons</h4></div></div></div></div><div class="sect3" title="Excluded Addons"><div class="titlepage"><div><div><h4 class="title"><a id="id2611409"></a>Excluded Addons</h4></div></div></div></div><div class="sect3" title="Dangerous Addons"><div class="titlepage"><div><div><h4 class="title"><a id="id2611419"></a>Dangerous Addons</h4></div></div></div></div></div><div class="sect2" title="4.3. Pref Changes"><div class="titlepage"><div><div><h3 class="title"><a id="prefs"></a>4.3. Pref Changes</h3></div></div></div><p> </p></div><div class="sect2" title="4.4. Update Security"><div class="titlepage"><div><div><h3 class="title"><a id="update-mechanism"></a>4.4. Update Security</h3></div></div></div><p> </p></div></div><div class="sect1" title="5. Testing"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Testing"></a>5. Testing</h2></div></div></div><p>
+This patch provides an API that allows us to more easily isolate identifiers
+to the URL bar domain.
 
-The purpose of this section is to cover all the known ways that Tor browser
-security can be subverted from a penetration testing perspective. The hope
-is that it will be useful both for creating a "Tor Safety Check"
-page, and for developing novel tests and actively attacking Torbutton with the
-goal of finding vulnerabilities in either it or the Mozilla components,
-interfaces and settings upon which it relies.
+     </p></li><li class="listitem"><a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0020-Add-canvas-image-extraction-prompt.patch">Add canvas image extraction prompt</a><p>
 
-  </p><div class="sect2" title="5.1. Single state testing"><div class="titlepage"><div><div><h3 class="title"><a id="SingleStateTesting"></a>5.1. Single state testing</h3></div></div></div><p>
+This patch prompts the user before returning canvas image data. Canvas image
+data can be used to create an extremely stable, high-entropy fingerprint based
+on the unique rendering behavior of video cards, OpenGL behavior,
+system fonts, and supporting library versions.
 
-Torbutton is a complicated piece of software. During development, changes to
-one component can affect a whole slough of unrelated features.  A number of
-aggregated test suites exist that can be used to test for regressions in
-Torbutton and to help aid in the development of Torbutton-like addons and
-other privacy modifications of other browsers. Some of these test suites exist
-as a single automated page, while others are a series of pages you must visit
-individually. They are provided here for reference and future regression
-testing, and also in the hope that some brave soul will one day decide to
-combine them into a comprehensive automated test suite.
+     </p></li><li class="listitem"><a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0021-Return-client-window-coordinates-for-mouse-event-scr.patch">Return client window coordinates for mouse events</a><p>
 
-     </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><a class="ulink" href="http://decloak.net/" target="_top">Decloak.net</a><p>
+This patch causes mouse events to return coordinates relative to the content
+window instead of the desktop.
 
-Decloak.net is the canonical source of plugin and external-application based
-proxy-bypass exploits. It is a fully automated test suite maintained by <a class="ulink" href="http://digitaloffense.net/" target="_top">HD Moore</a> as a service for people to
-use to test their anonymity systems.
+     </p></li><li class="listitem"><a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0022-Do-not-expose-physical-screen-info.-via-window-and-w.patch">Do not expose physical screen info to window.screen</a><p>
 
-       </p></li><li class="listitem"><a class="ulink" href="http://deanonymizer.com/" target="_top">Deanonymizer.com</a><p>
+This patch causes window.screen to return the display resolution size of the
+content window instead of the desktop resolution size.
 
-Deanonymizer.com is another automated test suite that tests for proxy bypass
-and other information disclosure vulnerabilities. It is maintained by Kyle
-Williams, the author of <a class="ulink" href="http://www.janusvm.com/" target="_top">JanusVM</a>
-and <a class="ulink" href="http://www.januspa.com/" target="_top">JanusPA</a>.
+     </p></li><li class="listitem"><a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0023-Do-not-expose-system-colors-to-CSS-or-canvas.patch">Do not expose system colors to CSS or canvas</a><p>
 
-       </p></li><li class="listitem"><a class="ulink" href="https://ip-check.info" target="_top">JonDos
-AnonTest</a><p>
+This patch prevents CSS and Javascript from discovering your desktop color
+scheme and/or theme.
 
-The <a class="ulink" href="https://anonymous-proxy-servers.net/" target="_top">JonDos people</a> also provide an
-anonymity tester. It is more focused on HTTP headers and behaviors than plugin bypass, and
-points out a couple of headers Torbutton could do a better job with
-obfuscating.
+     </p></li><li class="listitem"><a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0024-Isolate-the-Image-Cache-per-url-bar-domain.patch">Isolate the Image Cache per url bar domain</a><p>
 
-       </p></li><li class="listitem"><a class="ulink" href="http://browserspy.dk" target="_top">Browserspy.dk</a><p>
+This patch prevents cached images from being used to store third party tracking
+identifiers.
 
-Browserspy.dk provides a tremendous collection of browser fingerprinting and
-general privacy tests. Unfortunately they are only available one page at a
-time, and there is not really solid feedback on good vs bad behavior in
-the test results.
+     </p></li><li class="listitem"><a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0025-nsIHTTPChannel.redirectTo-API.patch">nsIHTTPChannel.redirectTo() API</a><p>
 
-       </p></li><li class="listitem"><a class="ulink" href="http://analyze.privacy.net/" target="_top">Privacy
-Analyzer</a><p>
+This patch provides HTTPS-Everywhere with an API to perform redirections more
+securely and without addon conflicts.
 
-The Privacy Analyzer provides a dump of all sorts of browser attributes and
-settings that it detects, including some information on your original IP
-address. Its page layout and lack of good vs bad test result feedback makes it
-not as useful as a user-facing testing tool, but it does provide some
-interesting checks in a single page.
+     </p></li><li class="listitem"><a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0026-Isolate-DOM-storage-to-first-party-URI.patch">Isolate DOM Storage to first party URI</a><p>
 
-       </p></li><li class="listitem"><a class="ulink" href="http://ha.ckers.org/mr-t/" target="_top">Mr. T</a><p>
+This patch prevents DOM Storage from being used to store third party tracking
+identifiers.
 
-Mr. T is a collection of browser fingerprinting and deanonymization exploits
-discovered by the <a class="ulink" href="http://ha.ckers.org" target="_top">ha.ckers.org</a> crew
-and others. It is also not as user friendly as some of the above tests, but it
-is a useful collection.
+     </p></li></ol></div></div></div><div class="appendix" title="A. Towards Transparency in Navigation Tracking"><h2 class="title"><a id="Transparency"/>A. Towards Transparency in Navigation Tracking</h2><p>
 
-       </p></li><li class="listitem">Gregory Fleischer's <a class="ulink" href="http://pseudo-flaw.net/content/tor/torbutton/" target="_top">Torbutton</a> and
-<a class="ulink" href="http://pseudo-flaw.net/content/defcon/dc-17-demos/d.html" target="_top">Defcon
-17</a> Test Cases
+The <a class="link" href="#privacy" title="2.2. Privacy Requirements">privacy properties</a> of Tor Browser are based
+upon the assumption that link-click navigation indicates user consent to
+tracking between the linking site and the destination site.  While this
+definition is sufficient to allow us to eliminate cross-site third party
+tracking with only minimal site breakage, it is our long-term goal to further
+reduce cross-origin click navigation tracking to mechanisms that are
+detectable by attentive users, so they can alert the general public if
+cross-origin click navigation tracking is happening where it should not be.
+
+</p><p>
+
+In an ideal world, the mechanisms of tracking that can be employed during a
+link click would be limited to the contents of URL parameters and other
+properties that are fully visible to the user before they click. However, the
+entrenched nature of certain archaic web features make it impossible for us to
+achieve this transparency goal by ourselves without substantial site breakage.
+So, instead we maintain a <a class="link" href="#deprecate" title="A.1. Deprecation Wishlist">Deprecation
+Wishlist</a> of archaic web technologies that are currently being (ab)used
+to facilitate federated login and other legitimate click-driven cross-domain
+activity but that can one day be replaced with more privacy friendly,
+auditable alternatives.
+
+</p><p>
+
+Because the total elimination of side channels during cross-origin navigation
+will undoubtedly break federated login as well as destroy ad revenue, we
+also describe auditable alternatives and promising web draft standards that would
+preserve this functionality while still providing transparency when tracking is
+occurring. 
+
+</p><div class="sect2" title="A.1. Deprecation Wishlist"><div class="titlepage"><div><div><h3 class="title"><a id="deprecate"/>A.1. Deprecation Wishlist</h3></div></div></div><div class="orderedlist"><ol class="orderedlist"><li class="listitem">The Referer Header
   <p>
 
-Gregory Fleischer has been hacking and testing Firefox and Torbutton privacy
-issues for the past 2 years. He has an excellent collection of all his test
-cases that can be used for regression testing. In his Defcon work, he
-demonstrates ways to infer Firefox version based on arcane browser properties.
-We are still trying to determine the best way to address some of those test
-cases.
+We haven't disabled or restricted the referer ourselves because of the
+non-trivial number of sites that rely on the referer header to "authenticate"
+image requests and deep-link navigation on their sites. Furthermore, there
+seems to be no real privacy benefit to taking this action by itself in a
+vacuum, because many sites have begun encoding referer URL information into
+GET parameters when they need it to cross http to https scheme transitions.
+Google's +1 buttons are the best example of this activity.
 
-       </p></li><li class="listitem"><a class="ulink" href="https://torcheck.xenobite.eu/index.php" target="_top">Xenobite's
-TorCheck Page</a><p>
+  </p><p>
 
-This page checks to ensure you are using a valid Tor exit node and checks for
-some basic browser properties related to privacy. It is not very fine-grained
-or complete, but it is automated and could be turned into something useful
-with a bit of work.
+Because of the availability of these other explicit vectors, we believe the
+main risk of the referer header is through inadvertent and/or covert data
+leakage.  In fact, <a class="ulink" href="http://www2.research.att.com/~bala/papers/wosn09.pdf">a great deal of
+personal data</a> is inadvertently leaked to third parties through the
+source URL parameters. 
 
-       </p></li></ol></div><p>
-    </p></div></div></div></body></html>
+  </p><p>
+
+We believe the Referer header should be made explicit. If a site wishes to
+transmit its URL to third party content elements during load or during
+link-click, it should have to specify this as a property of the associated
+HTML tag. With an explicit property, it would then be possible for the user
+agent to inform the user if they are about to click on a link that will
+transmit referer information (perhaps through something as subtle as a
+different color for the destination URL). This same UI notification can also
+be used for links with the <a class="ulink" href="https://developer.mozilla.org/en-US/docs/HTML/Element/a#Attributes">"ping"</a>
+attribute.
+
+  </p></li><li class="listitem">window.name
+   <p>
+<a class="ulink" href="https://developer.mozilla.org/En/DOM/Window.name">window.name</a> is
+a DOM property that for some reason is allowed to retain a persistent value
+for the lifespan of a browser tab. It is possible to utilize this property for
+<a class="ulink" href="http://www.thomasfrank.se/sessionvars.html">identifier
+storage</a> during click navigation. This is sometimes used for additional
+XSRF protection and federated login.
+   </p><p>
+
+It's our opinion that the contents of window.name should not be preserved for
+cross-origin navigation, but doing so may break federated login for some sites.
+
+   </p></li><li class="listitem">Javascript link rewriting
+   <p>
+
+In general, it should not be possible for onclick handlers to alter the
+navigation destination of 'a' tags, silently transform them into POST
+requests, or otherwise create situations where a user believes they are
+clicking on a link leading to one URL that ends up on another. This
+functionality is deceptive and is frequently a vector for malware and phishing
+attacks. Unfortunately, many legitimate sites also employ such transparent
+link rewriting, and blanket disabling this functionality ourselves will simply
+cause Tor Browser to fail to navigate properly on these sites.
+
+   </p><p>
+
+Automated cross-origin redirects are one form of this behavior that is
+possible for us to <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3600">address
+ourselves</a>, as they are comparatively rare and can be handled with site
+permissions.
+
+   </p></li></ol></div></div><div class="sect2" title="A.2. Promising Standards"><div class="titlepage"><div><div><h3 class="title"><a id="idp5752304"/>A.2. Promising Standards</h3></div></div></div><div class="orderedlist"><ol class="orderedlist"><li class="listitem"><a class="ulink" href="http://web-send.org">Web-Send Introducer</a><p>
+
+Web-Send is a browser-based link sharing and federated login widget that is
+designed to operate without relying on third-party tracking or abusing other
+cross-origin link-click side channels. It has a compelling list of <a class="ulink" href="http://web-send.org/features.html">privacy and security features</a>,
+especially if used as a "Like button" replacement.
+
+   </p></li><li class="listitem"><a class="ulink" href="https://developer.mozilla.org/en-US/docs/Persona">Mozilla Persona</a><p>
+
+Mozilla's Persona is designed to provide decentralized, cryptographically
+authenticated federated login in a way that does not expose the user to third
+party tracking or require browser redirects or side channels. While it does
+not directly provide the link sharing capabilities that Web-Send does, it is a
+better solution to the privacy issues associated with federated login than
+Web-Send is.
+
+   </p></li></ol></div></div></div></div></body></html>
