commit 7b06135737d39fe1a1e1a5cb67a2461d22ab571a Author: Mike Perry mikeperry-git@torproject.org Date: Wed Oct 29 22:00:02 2014 -0700
Update design doc for TBB 4.0. --- projects/torbrowser/design/index.html.en | 701 +++++++++++++++++------------- 1 file changed, 407 insertions(+), 294 deletions(-)
diff --git a/projects/torbrowser/design/index.html.en b/projects/torbrowser/design/index.html.en index de7b344..65b6e98 100644 --- a/projects/torbrowser/design/index.html.en +++ b/projects/torbrowser/design/index.html.en @@ -1,10 +1,9 @@ <?xml version="1.0" encoding="UTF-8"?> -<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> -<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>The Design and Implementation of the Tor Browser [DRAFT]</title><meta name="generator" content="DocBook XSL Stylesheets V1.76.1" /></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"><<a class="email" href="mailto:mikeperry#torproject org">mikeperry#torproject org</a>></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"> <<a class="email" href="mailto:erinn#torproject org">erinn#torproject org</a>></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"><<a class="email" href="mailto:sjmurdoch#torproject org">sjmurdoch#torproject org</a>></code></p></div></div></div></div><div><p class="pubdate">March 15, 2013</p></div></div><hr /></div><div class="toc"><p><strong>Table of Contents</strong></p><dl><dt><span class="sect1"><a href="#idp2182160">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="#privac y">2.2. Privacy Requirements</a></span></dt><dt><span class="sect2"><a href="#philosophy">2.3. Philosophy</a></span></dt></dl></dd><dt><span class="sect1"><a href="#adversary">3. Adversary Model</a></span></dt><dd><dl><dt><span class="sect2"><a href="#adversary-goals">3.1. Adversary Goals</a></span></dt><dt><span class="sect2"><a href="#adversary-positioning">3.2. Adversary Capabilities - Positioning</a></span></dt><dt><span class="sect2"><a href="#attacks">3.3. Adversary Capabilities - Attacks</a></span></dt></dl></dd><dt><span class="sect1"><a href="#Implementation">4. Implementation</a></span></dt><dd><dl><dt><span class="sect2"><a href="#proxy-obedience">4.1. Proxy Obedience</a></span></dt><dt><span class="sect2"><a href="#state-separation">4.2. State Separation</a></span></dt><dt><span class="sect2"><a href="#disk-avoidance">4.3. Disk Avoidance</a></span></dt><dt><span class="sect2"><a href="#app-data-isolation">4.4. Application Data Isolation</a></span></dt><dt><span class="se ct2"><a href="#identifier-linkability">4.5. Cross-Origin Identifier Unlinkability</a></span></dt><dt><span class="sect2"><a href="#fingerprinting-linkability">4.6. Cross-Origin Fingerprinting Unlinkability</a></span></dt><dt><span class="sect2"><a href="#new-identity">4.7. Long-Term Unlinkability via "New Identity" button</a></span></dt><dt><span class="sect2"><a href="#other-security">4.8. Other Security Measures</a></span></dt><dt><span class="sect2"><a href="#firefox-patches">4.9. 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><dd><dl><dt><span class="sect1"><a href="#deprecate">A.1. Deprecation Wishlist</a></span></dt><dt><span class="sect1"><a href="#idp5896048">A.2. Promising Standards</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="idp2182160"></a> 1. Introduction</h2></div></div></div><p> +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>The Design and Implementation of the Tor Browser [DRAFT]</title><meta name="generator" content="DocBook XSL Stylesheets V1.78.1" /></head><body><div class="article"><div class="titlepage"><div><div><h2 class="title"><a id="design"></a>The Design and Implementation of the Tor Browser [DRAFT]</h2></div><div><div class="author"><h3 class="author"><span class="firstname">Mike</span> <span class="surname">Perry</span></h3><div class="affiliation"><div class="address"><p><code class="email"><<a class="email" href="mailto:mikeperry#torproject org">mikeperry#torproject org</a>></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="a ffiliation"><div class="address"><p><code class="email"><<a class="email" href="mailto:erinn#torproject org">erinn#torproject org</a>></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"><<a class="email" href="mailto:sjmurdoch#torproject org">sjmurdoch#torproject org</a>></code></p></div></div></div></div><div><p class="pubdate">October 30th, 2014</p></div></div><hr /></div><div class="toc"><p><strong>Table of Contents</strong></p><dl class="toc"><dt><span class="sect1"><a href="#idp35210336">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. Secu rity Requirements</a></span></dt><dt><span class="sect2"><a href="#privacy">2.2. Privacy Requirements</a></span></dt><dt><span class="sect2"><a href="#philosophy">2.3. Philosophy</a></span></dt></dl></dd><dt><span class="sect1"><a href="#adversary">3. Adversary Model</a></span></dt><dd><dl><dt><span class="sect2"><a href="#adversary-goals">3.1. Adversary Goals</a></span></dt><dt><span class="sect2"><a href="#adversary-positioning">3.2. Adversary Capabilities - Positioning</a></span></dt><dt><span class="sect2"><a href="#attacks">3.3. Adversary Capabilities - Attacks</a></span></dt></dl></dd><dt><span class="sect1"><a href="#Implementation">4. Implementation</a></span></dt><dd><dl><dt><span class="sect2"><a href="#proxy-obedience">4.1. Proxy Obedience</a></span></dt><dt><span class="sect2"><a href="#state-separation">4.2. State Separation</a></span></dt><dt><span class="sect2"><a href="#disk-avoidance">4.3. Disk Avoidance</a></span></dt><dt><span class="sect2"><a href="#app-data-isol ation">4.4. Application Data Isolation</a></span></dt><dt><span class="sect2"><a href="#identifier-linkability">4.5. Cross-Origin Identifier Unlinkability</a></span></dt><dt><span class="sect2"><a href="#fingerprinting-linkability">4.6. Cross-Origin Fingerprinting Unlinkability</a></span></dt><dt><span class="sect2"><a href="#new-identity">4.7. Long-Term Unlinkability via "New Identity" button</a></span></dt><dt><span class="sect2"><a href="#other-security">4.8. Other Security Measures</a></span></dt></dl></dd><dt><span class="sect1"><a href="#BuildSecurity">5. Build Security and Package Integrity</a></span></dt><dd><dl><dt><span class="sect2"><a href="#idp37001088">5.1. Achieving Binary Reproducibility</a></span></dt><dt><span class="sect2"><a href="#idp37036336">5.2. Package Signatures and Verification</a></span></dt><dt><span class="sect2"><a href="#idp37040272">5.3. Anonymous Verification</a></span></dt></dl></dd><dt><span class="appendix"><a href="#Transparency">A. Towards Tran sparency in Navigation Tracking</a></span></dt><dd><dl><dt><span class="sect1"><a href="#deprecate">A.1. Deprecation Wishlist</a></span></dt><dt><span class="sect1"><a href="#idp37071376">A.2. Promising Standards</a></span></dt></dl></dd></dl></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="idp35210336"></a>1. Introduction</h2></div></div></div><p>
This document describes the <a class="link" href="#adversary" title="3. Adversary Model">adversary model</a>, <a class="link" href="#DesignRequirements" title="2. Design Requirements and Philosophy">design requirements</a>, and <a class="link" href="#Implementation" title="4. Implementation">implementation</a> of the Tor Browser. It is current as of Tor Browser -2.3.25-5 and Torbutton 1.5.1. +4.0.
</p><p>
@@ -13,27 +12,39 @@ 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. Browser Component Overview"><div class="titlepage"><div><div><h3 class="title"><a id="components"></a>1.1. Browser Component Overview</h3></div></div></div><p> + </p><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="components"></a>1.1. Browser Component Overview</h3></div></div></div><p>
The Tor Browser is based on <a class="ulink" href="https://www.mozilla.org/en-US/firefox/organizations/" target="_top">Mozilla's Extended -Support Release (ESR) Firefox branch</a>. We have a <a class="link" href="#firefox-patches" title="4.9. 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" target="_top">Torbutton -extension</a>, though we are in the process of moving this -functionality into direct Firefox patches. We also <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/HEAD:/build-scripts/config/pound_tor.js" target="_top">change +Support Release (ESR) Firefox branch</a>. We have a <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git" target="_top">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" target="_top">Torbutton +extension</a>, though we are in the process of moving this functionality +into direct Firefox patches. We also <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/blob/refs/heads/tor-browser-31.2.0esr-4.x-1:/browser/app/profile/000-tor-browser.js" target="_top">change a number of Firefox preferences</a> from their defaults.
</p><p> +Tor process management and configuration is accomplished through the <a class="ulink" href="https://gitweb.torproject.org/tor-launcher.git" target="_top">Tor Launcher</a> +addon, which provides the initial Tor configuration splash screen and +bootstrap progress bar. Tor Launcher is also compatible with Thunderbird, +InstantBird, and XULRunner. + + </p><p>
To help protect against potential Tor Exit Node eavesdroppers, we include <a class="ulink" href="https://www.eff.org/https-everywhere" target="_top">HTTPS-Everywhere</a>. To provide users with optional defense-in-depth against Javascript and other -potential exploit vectors, we also include <a class="ulink" href="http://noscript.net/" target="_top">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/" target="_top">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" target="_top">several +potential exploit vectors, we also include <a class="ulink" href="http://noscript.net/" target="_top">NoScript</a>. We also modify <a class="ulink" href="https://gitweb.torproject.org/builders/tor-browser-bundle.git/blob/refs/heads/master:/Bundle-Data/linux/Data/Browser/profile.default/preferences/extension-overrides.js" target="_top">several extension preferences</a> from their defaults.
- </p></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><p> + +To provide censorship circumvention in areas where the public Tor network is +blocked either by IP, or by protocol fingerprint, we include several <a class="ulink" href="https://trac.torproject.org/projects/tor/wiki/doc/AChildsGardenOfPluggableTransports" target="_top">Pluggable +Transports</a> in the distribution. As of this writing, we include <a class="ulink" href="https://gitweb.torproject.org/pluggable-transports/obfsproxy.git/blob/HEAD:/doc/obfs3/obfs3-protocol-spec.txt" target="_top">Obfsproxy</a>, +<a class="ulink" href="https://trac.torproject.org/projects/tor/wiki/doc/meek" target="_top">meek</a>, +<a class="ulink" href="https://fteproxy.org/" target="_top">FTE</a>, and <a class="ulink" href="https://crypto.stanford.edu/flashproxy/" target="_top">FlashProxy</a>. + + </p></div></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="DesignRequirements"></a>2. Design Requirements and Philosophy</h2></div></div></div><p>
The Tor Browser Design Requirements are meant to describe the properties of a Private Browsing Mode that defends against both network and local forensic @@ -59,7 +70,7 @@ browser distribution. "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>.
- </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"><div class="titlepage"><div><div><h3 class="title"><a id="security"></a>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 @@ -100,7 +111,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"><div class="titlepage"><div><div><h3 class="title"><a id="privacy"></a>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 @@ -144,7 +155,7 @@ its 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"><div class="titlepage"><div><div><h3 class="title"><a id="philosophy"></a>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. @@ -207,7 +218,7 @@ 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 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 +goes for exemptions to third party cookie policy, geolocation, and any other privacy permissions. </p><p> If the user has indicated they wish to record local history storage, these @@ -243,18 +254,18 @@ 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. Adversary Model"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="adversary"></a>3. Adversary Model</h2></div></div></div><p> + </p></li></ol></div></div></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="adversary"></a>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="adversary-goals"></a>3.1. Adversary Goals</h3></div></div></div><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><span class="command"><strong>Bypassing proxy settings</strong></span><p>The adversary's primary goal is direct compromise and bypass of + </p><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="adversary-goals"></a>3.1. Adversary Goals</h3></div></div></div><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><span class="command"><strong>Bypassing proxy settings</strong></span><p>The adversary's primary goal is direct compromise and bypass of Tor, causing the user to directly connect to an IP of the adversary's choosing.</p></li><li class="listitem"><span class="command"><strong>Correlation of Tor vs Non-Tor Activity</strong></span><p>If direct proxy bypass is not possible, the adversary will likely happily settle for the ability to correlate something a user did via Tor with their non-Tor activity. This can be done with cookies, cache identifiers, -javascript events, and even CSS. Sometimes the fact that a user uses Tor may +Javascript events, and even CSS. Sometimes the fact that a user uses Tor may be enough for some authorities.</p></li><li class="listitem"><span class="command"><strong>History disclosure</strong></span><p> The adversary may also be interested in history disclosure: the ability to query a user's history to see if they have issued certain censored search @@ -282,7 +293,7 @@ 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="adversary-positioning"></a>3.2. Adversary Capabilities - Positioning</h3></div></div></div><p> + </p></li></ol></div></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="adversary-positioning"></a>3.2. Adversary Capabilities - Positioning</h3></div></div></div><p> 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> @@ -311,7 +322,7 @@ 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"></a>3.3. Adversary Capabilities - Attacks</h3></div></div></div><p> + </p></li></ol></div></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="attacks"></a>3.3. Adversary Capabilities - Attacks</h3></div></div></div><p>
The adversary can perform the following attacks from a number of different positions to accomplish various aspects of their goals. It should be noted @@ -340,7 +351,7 @@ 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 "New Identity" button">Long-Term Unlikability</a> design requirements. +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 "New Identity" button">Long-Term Unlinkability</a> design requirements.
</p></li><li class="listitem"><a id="fingerprinting"></a><span class="command"><strong>Fingerprint users based on browser attributes</strong></span><p> @@ -350,7 +361,7 @@ 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 "New Identity" button">Long-Term Unlikability</a> design requirements. +Fingerprinting Unlinkability</a> and <a class="link" href="#new-identity" title="4.7. Long-Term Unlinkability via "New Identity" button">Long-Term Unlinkability</a> design requirements.
</p><p>
@@ -465,7 +476,7 @@ complexity (and thus hinder a real world adversary who attempts this attack) are large numbers of dynamically generated pages, partially cached content, and also the non-web activity of entire Tor network. This yields an effective number of "web pages" many orders of magnitude larger than even <a class="ulink" href="http://lorre.uni.lu/~andriy/papers/acmccs-wpes11-fingerprinting.pdf" target="_top">Panchenko's -"Open World" scenario</a>, which suffered continous near-constant decline +"Open World" scenario</a>, which suffered continuous near-constant decline in the true positive rate as the "Open World" size grew (see figure 4). This large level of classification complexity is further confounded by a noisy and low resolution featureset - one which is also relatively easy for the defender @@ -510,12 +521,12 @@ has taken place. This adversary motivates our
An adversary with arbitrary code execution typically has more power, though. It can be quite hard to really significantly limit the capabilities of such an -adversary. <a class="ulink" href="https://tails.boum.org/contribute/design/" target="_top">The Tails system</a> can +adversary. <a class="ulink" href="http://tails.boum.org/contribute/design/" target="_top">The Tails system</a> can provide some defense against this adversary through the use of readonly media and frequent reboots, but even this can be circumvented on machines without Secure Boot through the use of BIOS rootkits.
- </p></li></ol></div></div></div><div class="sect1" title="4. Implementation"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Implementation"></a>4. Implementation</h2></div></div></div><p> + </p></li></ol></div></div></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Implementation"></a>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>. @@ -531,38 +542,45 @@ between the <span class="command"><strong>Design Goal</strong></span> and the <s 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> are typically linked for these cases.
- </p><div class="sect2" title="4.1. Proxy Obedience"><div class="titlepage"><div><div><h3 class="title"><a id="proxy-obedience"></a>4.1. Proxy Obedience</h3></div></div></div><p> + </p><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="proxy-obedience"></a>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, patches, and build flags <p> -Our <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/HEAD:/build-scripts/config/pound_tor.js" target="_top">Firefox -preferences file</a> sets the Firefox proxy settings to use Tor directly as a -SOCKS proxy. It sets <span class="command"><strong>network.proxy.socks_remote_dns</strong></span>, + +Our <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/blob/refs/heads/tor-browser-31.2.0esr-4.x-1:/browser/app/profile/000-tor-browser.js" target="_top">Firefox +preferences file</a> sets the Firefox proxy settings to use Tor directly +as a SOCKS proxy. It sets <span class="command"><strong>network.proxy.socks_remote_dns</strong></span>, <span class="command"><strong>network.proxy.socks_version</strong></span>, <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" target="_top">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" target="_top">this DNS proxy leak -remains present in stock Firefox releases</a>. +To prevent proxy bypass by WebRTC calls, we disable WebRTC at compile time +with the <span class="command"><strong>--disable-webrtc</strong></span> configure switch, as well +as set the pref <span class="command"><strong>media.peerconnection.enabled</strong></span> to false.
</p><p>
-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>. +We also patch Firefox in order to provide several defense-in-depth mechanisms +for proxy safety. Notably, we <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/8527bec0ad59fb3d885c5639735fb188eefa336f" target="_top">patch +the DNS service</a> to prevent any browser or addon DNS resolution, and we +also <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/04c046e11f6622f44ca010bcb8ecf68cf470a4c0" target="_top">patch +OCSP and PKIX code</a> to prevent any use of the non-proxied command-line +tool utility functions from being functional while linked in to the browser. +In both cases, we could find no direct paths to these routines in the browser, +but it seemed better safe than sorry.
</p><p>
+During every Extended Support Release transition, we perform <a class="ulink" href="https://gitweb.torproject.org/tor-browser-spec.git/tree/HEAD:/audits" target="_top">in-depth +code audits</a> to verify that there were no system calls or XPCOM +activity in the source tree that did not use the browser proxy settings. + </p><p> + We have verified that these settings and patches properly proxy HTTPS, OCSP, -HTTP, FTP, gopher (now defunct), DNS, SafeBrowsing Queries, all javascript +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 @@ -590,10 +608,11 @@ 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> + 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" target="_top">prevent the load of any plugins except -for Flash and Gnash</a>. +also patch the Firefox source code to <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/2ecf6c33618ecee554155f735a3e92860f519f9c" target="_top"> +prevent the load of any plugins except for Flash and Gnash</a>.
</p></li><li class="listitem">External App Blocking and Drag Event Filtering <p> @@ -611,9 +630,8 @@ Additionally, modern desktops now pre-emptively fetch any URLs in Drag and Drop events as soon as the drag is initiated. This download happens independent of the browser's Tor settings, and can be triggered by something as simple as holding the mouse button down for slightly too long while -clicking on an image link. We had to patch Firefox to <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0018-Emit-observer-event-to-filter-the-Drag-Drop-url-list.patch" target="_top">emit -an observer event during dragging</a> to allow us to filter the drag -events from Torbutton before the OS downloads the URLs the events contained. +clicking on an image link. We filter drag and drop events events <a class="ulink" href="https://gitweb.torproject.org/torbutton.git/blob_plain/HEAD:/src/components/external-app-blocker.js" target="_top">from +Torbutton</a> before the OS downloads the URLs the events contained.
</p></li><li class="listitem">Disabling system extensions and clearing the addon whitelist <p> @@ -626,41 +644,39 @@ system-level addons from the browser through the use of <span class="command"><strong>extensions.enabledScopes</strong></span> and <span class="command"><strong>extensions.autoDisableScopes</strong></span>.
- </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"></a>4.2. State Separation</h3></div></div></div><p> + </p></li></ol></div></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="state-separation"></a>4.2. State Separation</h3></div></div></div><p>
Tor Browser State is separated from existing browser state through use of a custom Firefox profile, and by setting the $HOME environment variable to the root of the bundle's directory. The browser also does not load any system-wide extensions (through the use of <span class="command"><strong>extensions.enabledScopes</strong></span> and -<span class="command"><strong>extensions.autoDisableScopes</strong></span>. Furthermore, plugins are +<span class="command"><strong>extensions.autoDisableScopes</strong></span>). Furthermore, plugins are disabled, which prevents Flash cookies from leaking from a pre-existing Flash directory.
- </p></div><div class="sect2" title="4.3. Disk Avoidance"><div class="titlepage"><div><div><h3 class="title"><a id="disk-avoidance"></a>4.3. Disk Avoidance</h3></div></div></div><div class="sect3" title="Design Goal:"><div class="titlepage"><div><div><h4 class="title"><a id="idp5639136"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> + </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="disk-avoidance"></a>4.3. Disk Avoidance</h3></div></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp36779392"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote">
The User Agent MUST (at user option) prevent all disk records of browser activity. The user should be able to optionally enable URL history and other history features if they so desire.
- </blockquote></div></div><div class="sect3" title="Implementation Status:"><div class="titlepage"><div><div><h4 class="title"><a id="idp5640496"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> + </blockquote></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp36780752"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote">
We achieve this goal through several mechanisms. First, we set the Firefox Private Browsing preference <span class="command"><strong>browser.privatebrowsing.autostart</strong></span>. In addition, four Firefox patches are needed to prevent disk writes, even if Private Browsing Mode is enabled. We need to
-<a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/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.4:/src/current-patches/firefox/0003-Make-Intermediate-Cert-Store-memory-only.patch" target="_top">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" target="_top">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" target="_top">prevent -the content preferences service from recording site zoom</a>. - -For more details on these patches, <a class="link" href="#firefox-patches" title="4.9. Description of Firefox Patches">see the -Firefox Patches section</a>. +<a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/4ebc3cda4b704c0149fb9e0fdcbb6e5ee3a8e75c" target="_top">prevent +the permissions manager from recording HTTPS STS state</a>, <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/8904bfc10cd537bd35be5ddd23c58fdaa72baa21" target="_top">prevent +intermediate SSL certificates from being recorded</a>, <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/86f6bc9dc28b6f8d7eae7974c7e9b537c3a08e41" target="_top">prevent +the clipboard cache from being written to disk for large pastes</a>, and +<a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/d5da6f8b7de089335e49e2f7dbd2b8d74e4cb613" target="_top">prevent +the content preferences service from recording site zoom</a>. We also had +to disable the media cache with the pref <span class="command"><strong>media.cache_size</strong></span>, +to prevent HTML5 videos from being written to the OS temporary directory, +which happened regardless of the private browsing mode setting.
</blockquote></div><div class="blockquote"><blockquote class="blockquote">
@@ -681,11 +697,7 @@ auditing work to ensure that yet.
</blockquote></div><div class="blockquote"><blockquote class="blockquote">
-Torbutton also <a class="ulink" href="https://gitweb.torproject.org/torbutton.git/blob/HEAD:/src/components/tbSessionStore.js" target="_top">contains -code</a> to prevent the Firefox session store from writing to disk. - </blockquote></div><div class="blockquote"><blockquote class="blockquote"> - -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&status=!closed" target="_top">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"></a>4.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&status=!closed" target="_top">tbb-disk-leak tag in our bugtracker</a></blockquote></div></div></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="app-data-isolation"></a>4.4. Application Data Isolation</h3></div></div></div><p>
Tor Browser Bundle MUST NOT cause any information to be written outside of the bundle directory. This is to ensure that the user is able to completely and @@ -699,7 +711,7 @@ To ensure TBB directory isolation, we set <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"></a>4.5. Cross-Origin Identifier Unlinkability</h3></div></div></div><p> + </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="identifier-linkability"></a>4.5. Cross-Origin Identifier Unlinkability</h3></div></div></div><p>
The 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 @@ -723,7 +735,7 @@ 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="idp5664576"></a><p class="title"><strong>Figure 1. Improving the Privacy UI</strong></p><div class="figure-contents"><div class="mediaobject" align="center"><img src="NewCookieManager.png" align="middle" alt="Improving the Privacy UI" /></div><div class="caption"><p></p> + </p><div class="figure"><a id="idp36803456"></a><p class="title"><strong>Figure 1. Improving the Privacy UI</strong></p><div class="figure-contents"><div class="mediaobject" align="center"><img src="NewCookieManager.png" align="middle" alt="Improving the Privacy UI" /></div><div class="caption"><p></p>
This example UI is a mock-up of how isolating identifiers to the URL bar origin can simplify the privacy UI for all data - not just cookies. Once @@ -937,7 +949,7 @@ functionality.
</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&status=!closed" target="_top">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"></a>4.6. Cross-Origin Fingerprinting Unlinkability</h3></div></div></div><p> + </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="fingerprinting-linkability"></a>4.6. Cross-Origin Fingerprinting Unlinkability</h3></div></div></div><p>
In order to properly address the fingerprinting adversary on a technical level, we need a metric to measure linkability of the various browser @@ -950,11 +962,14 @@ determine how many bits of identifying information each attribute provided.
</p><p>
-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. +Because fingerprinting is problem that potentially touches every aspect of the +browser, 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. Similarly, we prioritize issues +that differentiate only MacOS, Windows, and Linux lower than those that +differentiate aspects of the hardware, third party installed software, and +configuration differences in those operating systems.
</p><p>
@@ -970,7 +985,15 @@ contrast to historical data. We have been <a class="ulink" href="https://trac.to 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"></a>Fingerprinting defenses in the Tor Browser</h4></div></div></div><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem">Plugins + </p><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="fingerprinting-defenses"></a>Fingerprinting defenses in the Tor Browser</h4></div></div></div><p> + +The following defenses are listed roughly in order of most severe +fingerprinting threat first, though we are desperately in need of updated +measurements to determine this with certainty. Where our actual implementation +differs from an ideal solution, we separately describe our <span class="command"><strong>Design +Goal</strong></span> and our <span class="command"><strong>Implementation Status</strong></span>. + + </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem">Plugins <p>
Plugins add to fingerprinting risk via two main vectors: their mere presence in @@ -984,7 +1007,9 @@ 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. For flash, we wish to <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3974" target="_top">provide a settings.sol file</a> to disable Flash cookies, and to restrict P2P -features that are likely to bypass proxy settings. +features that are likely to bypass proxy settings. We'd also like to restrict +access to fonts and other system information (such as IP address and MAC +address) in such a sandbox.
</p><p><span class="command"><strong>Implementation Status:</strong></span>
@@ -1015,11 +1040,49 @@ 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" target="_top">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. +In some sense, the canvas can be seen as the union of many other +fingerprinting vectors. If WebGL were normalized through software rendering, +and the browser shipped a fixed collection of fonts, it might not be necessary +to create a canvas permission. However, until then, to reduce the threat from +this vector, we have patched Firefox to <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/3b53f525cfb68880e676e64f13cbc0b928ae3ecf" target="_top">prompt +before returning valid image data</a> to the Canvas APIs, and for <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/fb9f463fe3a69499d6896c217786bafdf0cda62f" target="_top">access +to isPointInPath and related functions</a>. 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><p> + </p></li><li class="listitem">Open TCP Port Fingerprinting + <p> + +In Firefox, by using either WebSockets or XHR, it is possible for remote +content to <a class="ulink" href="http://www.andlabs.org/tools/jsrecon.html" target="_top">enumerate +the list of TCP ports open on 127.0.0.1</a>. In other browsers, this can +be accomplished by DOM events on image or script tags. This open vs filtered +vs closed port list can provide a very unique fingerprint of a machine. + + </p><p>In Tor Browser, we prevent access to +127.0.0.1/localhost by ensuring that even these requests are still sent by +Firefox to our SOCKS proxy (ie we set +<span class="command"><strong>network.proxy.no_proxies_on</strong></span> to the empty string). The local +Tor client then rejects them, since it is configured to proxy for internal IP +addresses by default. + </p></li><li class="listitem">USB Device ID enumeration + <p> + +The <a class="ulink" href="https://developer.mozilla.org/en-US/docs/Web/Guide/API/Gamepad" target="_top">GamePad +API</a> provides web pages with the <a class="ulink" href="https://dvcs.w3.org/hg/gamepad/raw-file/default/gamepad.html#widl-Gamepad-id" target="_top">USB +device id, product id, and driver name</a> of all connected game +controllers, as well as detailed information about their capabilities. This API +should be behind a site permission in Private Browsing Modes, or should present a generic +controller type (perhaps a two button controller that can be mapped to the keyboard) in all cases. +We simply disable it via the pref <span class="command"><strong>dom.gamepad.enabled</strong></span>.
+ </p></li><li class="listitem">Invasive Authentication Mechanisms (NTLM and SPNEGO) + <p> +Both NTLM and SPNEGO authentication mechanisms can leak the hostname, and in +some cases the machine username. These authentication mechanisms should either +be disabled, or placed behind a site permission before their use. We simply +disable them. </p></li><li class="listitem">WebGL <p>
@@ -1040,6 +1103,12 @@ provided by the following WebGL API calls: <span class="command"><strong>getPara <span class="command"><strong>getSupportedExtensions()</strong></span>, and <span class="command"><strong>getExtension()</strong></span>.
+ </p><p> + +Another option for WebGL might be to use software-only rendering, using a +library such as <a class="ulink" href="http://www.mesa3d.org/" target="_top">Mesa</a>. The use of +such a library would avoid hardware-specific rendering differences. + </p></li><li class="listitem">Fonts <p>
@@ -1050,28 +1119,33 @@ Javascript to query for the existence of specific fonts. With a large enough pre-built list to query, a large amount of fingerprintable information may still be available.
- </p><p> - -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 -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 -language issues of supporting a global font set. - + </p><p><span class="command"><strong>Design Goal:</strong></span> The sure-fire way to address font +linkability is to ship the browser with a font for every language, typeface, +and style, and to only use those fonts at the exclusion of system fonts. We are +<a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/13313" target="_top">currently +investigating</a> this approach, and our current favorite font sets for +this purpose are the <a class="ulink" href="http://www.droidfonts.com/droidfonts/" target="_top">Droid +fonts</a>, the <a class="ulink" href="http://hangeul.naver.com/" target="_top">Nanum fonts</a>, +and <a class="ulink" href="https://fedorahosted.org/lohit/" target="_top">Lohit fonts</a>. The Droid +font set is fairly complete by itself, but Nanum and Lohit have smaller +versions of many South Asian languages. When combined in a way that chooses the +smallest font implementations for each locale, these three font sets provide +which provide coverage for the all languages used on Wikipedia with more than +10,000 articles, and several others as well, in approximately 3MB of compressed +overhead. The <a class="ulink" href="https://www.google.com/get/noto/" target="_top">Noto font +set</a> is another font set that aims for complete coverage, but is +considerably larger than the combination of the Droid, Nanum, and Lohit fonts. </p><p><span class="command"><strong>Implementation Status:</strong></span>
-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 <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0011-Limit-the-number-of-fonts-per-document.patch" target="_top">with +In the meantime while we investigate shipping our own fonts, 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 <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0011-Limit-the-number-of-fonts-per-document.patch" target="_top">with 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 set. We are -still working to determine optimal values for these prefs. +<span class="command"><strong>browser.display.use_document_fonts</strong></span> was set.
</p><p>
@@ -1079,43 +1153,69 @@ To improve rendering, we exempt remote <a class="ulink" href="https://developer. 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.
- </p></li><li class="listitem">Desktop resolution, CSS Media Queries, and System Colors + </p></li><li class="listitem">Monitor and Desktop resolution <p>
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 +screen orientation, 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>
Our design goal here is to reduce the resolution information down to the bare -minimum required for properly rendering inside a content window. We intend to +minimum required for properly rendering inside a content window. We intend to 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 a few fixed sizes based on the user's -desktop resolution. +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 a few fixed sizes based on the user's desktop +resolution. In addition, to further reduce resolution-based fingerprinting, we +are <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/7256" target="_top">investigating +zoom/viewport-based mechanisms</a> that might allow us to always report the +same desktop resolution regardless of the actual size of the content window, +and simply scale to make up the difference. Until then, the user should also +be informed that maximizing their windows can lead to fingerprintability under +this scheme.
</p><p><span class="command"><strong>Implementation Status:</strong></span>
-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" 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#l2960" target="_top">resize new windows based on desktop resolution</a>. Additionally, we patch -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" target="_top">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" target="_top">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" target="_top">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" target="_top">report -a fixed set of system colors to content window CSS</a>. +Firefox to use the client content window size <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/8fc2421becd0ab0cfb5ebbc19af67469552202b2" target="_top">for +window.screen</a>. Similarly, we <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/81e7fc3a10d27b1d8f0832faf1685899d21f6fef" target="_top">patch +DOM events to return content window relative points</a>. We also force +popups to open in new tabs (via +<span class="command"><strong>browser.link.open_newwindow.restriction</strong></span>), to avoid +full-screen popups inferring information about the browser resolution. In +addition, we prevent auto-maximizing on browser start, and are investigating a +user-friendly way of informing users that maximized windows are detrimental +to privacy in this mode. + + </p></li><li class="listitem">CSS Media Queries + <p>
- </p><p> +Even without Javascript, CSS has 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. Most of this information comes from +<a class="ulink" href="https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Media_queries" target="_top">CSS Media Queries</a>, but +Mozilla has exposed <a class="ulink" href="https://developer.mozilla.org/en-US/docs/Web/CSS/color_value#System_Colors" target="_top">several user and OS theme defined color values</a> to CSS as well. + + </p><p><span class="command"><strong>Design Goal:</strong></span> +In Private Browsing Mode, CSS should not be able infer anything that the user +has configured about their computer. Additionally, it should not be able to +infer machine-specific details such as screen orientation or type. + + </p><p><span class="command"><strong>Implementation Status:</strong></span>
-To further reduce resolution-based fingerprinting, we are <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/7256" target="_top">investigating -zoom/viewport-based mechanisms</a> that might allow us to always report -the same desktop resolution regardless of the actual size of the content -window, and simply scale to make up the difference. However, the complexity -and rendering impact of such a change is not yet known. +We patch +Firefox to <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/30dc2c4290698af81ceafae9d628a34c53faabe1" target="_top">report +a fixed set of system colors to content window CSS</a>, and <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/8f6e979d30598569dea14ac6f4eef4e96543b3d7" target="_top">prevent +detection of font smoothing on OSX</a>. We also always +<a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/09561f0e5452305b9efcb4e6169c613c8db33246" target="_top">report +landscape-primary</a> for the screen orientation.
</p></li><li class="listitem">User Agent and HTTP Headers <p><span class="command"><strong>Design Goal:</strong></span> @@ -1132,8 +1232,29 @@ 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" 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">Timezone and clock offset - <p><span class="command"><strong>Design Goal:</strong></span> +used</a> to fingerprint OS, platform, and Firefox minor version. </p></li><li class="listitem">Locale Fingerprinting + <p> + +In Tor Browser, we provide non-English users the option of concealing their OS +and browser locale from websites. It is debatable if this should be as high of +a priority as information specific to the user's computer, but for +completeness, we attempt to maintain this property. + + </p><p><span class="command"><strong>Implementation Status:</strong></span> + +We set the fallback character set to set to windows-1252 for all locales, via +<span class="command"><strong>intl.charset.default</strong></span>. We also patch Firefox to allow us to +<a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/fe42a78575df7f460fa0ac48eabb57bc8812c23e" target="_top">instruct +the JS engine</a> to use en-US as its internal C locale for all Date, Math, +and exception handling. + + </p></li><li class="listitem">Timezone and clock offset + <p> + +While the latency in Tor connections varies anywhere from milliseconds to +several seconds, it is still possible for the remote site to detect large +differences between the user's clock and an official reference timesource. + </p><p><span class="command"><strong>Design Goal:</strong></span>
All Tor Browser users MUST report the same timezone to websites. Currently, we choose UTC for this purpose, although an equally valid argument could be made @@ -1141,7 +1262,9 @@ for EDT/EST due to the large English-speaking population density (coupled with the fact that we spoof a US English user agent). Additionally, the Tor software should detect if the users clock is significantly divergent from the clocks of the relays that it connects to, and use this to reset the clock -values used in Tor Browser to something reasonably accurate. +values used in Tor Browser to something reasonably accurate. Alternatively, +the browser can obtain this clock skew via a mechanism similar to that used in +<a class="ulink" href="" target="_top">tlsdate</a>.
</p><p><span class="command"><strong>Implementation Status:</strong></span>
@@ -1204,17 +1327,17 @@ fingerprinting: timestamp quantization and jitter. We have no implementation as of yet. </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&status=!closed" target="_top">tbb-fingerprinting tag in our bugtracker</a> - </p></div><div class="sect2" title="4.7. Long-Term Unlinkability via "New Identity" button"><div class="titlepage"><div><div><h3 class="title"><a id="new-identity"></a>4.7. Long-Term Unlinkability via "New Identity" button</h3></div></div></div><p> + </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="new-identity"></a>4.7. Long-Term Unlinkability via "New Identity" button</h3></div></div></div><p>
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><div class="sect3" title="Design Goal:"><div class="titlepage"><div><div><h4 class="title"><a id="idp5782640"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> + </p><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp36963888"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote">
All linkable identifiers and browser state MUST be cleared by this feature.
- </blockquote></div></div><div class="sect3" title="Implementation Status:"><div class="titlepage"><div><div><h4 class="title"><a id="idp5783888"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p> + </blockquote></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp36965136"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p>
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" target="_top">browser.docShell.allowJavascript</a> @@ -1232,8 +1355,9 @@ After closing all tabs, we then emit "<a class="ulink" href="https://developer.m state), and then manually 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, offline cache, Cookies, DOM -storage, DOM local storage, the safe browsing key, and the Google wifi geolocation -token (if it exists). +storage, crypto tokens, DOM local storage, the safe browsing key, and the +Google wifi geolocation token (if it exists). We also clear NoScript's site +and temporary permissions.
</p><p>
@@ -1246,7 +1370,7 @@ closed (this does not spawn a new Firefox process, only a new window). </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. Other Security Measures"><div class="titlepage"><div><div><h3 class="title"><a id="other-security"></a>4.8. Other Security Measures</h3></div></div></div><p> + </blockquote></div></div></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="other-security"></a>4.8. Other Security Measures</h3></div></div></div><p>
In addition to the above mechanisms that are devoted to preserving privacy while browsing, we also have a number of technical mechanisms to address other @@ -1258,7 +1382,7 @@ privacy and security issues. Fingerprinting</a> is a statistical attack to attempt to recognize specific encrypted website activity.
- </p><div class="sect3" title="Design Goal:"><div class="titlepage"><div><div><h4 class="title"><a id="idp5797920"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p> + </p><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp36979248"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p>
We want to deploy a mechanism that reduces the accuracy of <a class="ulink" href="https://en.wikipedia.org/wiki/Feature_selection" target="_top">useful features</a> available for classification. This mechanism would either impact the true and false @@ -1280,7 +1404,7 @@ Congestion-Sensitive BUFLO</a>. It may be also possible to <a class="ulink" href defenses</a> such that they only use existing spare Guard bandwidth capacity in the Tor network, making them also effectively no-overhead.
- </p></blockquote></div></div><div class="sect3" title="Implementation Status:"><div class="titlepage"><div><div><h4 class="title"><a id="idp5804816"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p> + </p></blockquote></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp36986144"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p> Currently, we patch Firefox to <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0017-Randomize-HTTP-request-order-and-pipeline-depth.patch" target="_top">randomize pipeline order and depth</a>. Unfortunately, pipelining is very fragile. Many sites do not support it, and even sites that advertise support for @@ -1330,199 +1454,188 @@ homepage to point to a <a class="ulink" href="https://check.torproject.org/?lang informs the user</a> that their browser is out of date.
- </p></li></ol></div></div><div class="sect2" title="4.9. Description of Firefox Patches"><div class="titlepage"><div><div><h3 class="title"><a id="firefox-patches"></a>4.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.4:/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"><a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0001-Block-Components.interfaces-from-content.patch" target="_top">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" target="_top">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> -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"><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" target="_top">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 -by a limited number of domains (and in some cases, only a single domain), -the intermediate certificate store can serve as a low-resolution record of -browsing history. - - </p><p><span class="command"><strong>Design Goal:</strong></span> - -As an additional design goal, we would like to later alter this patch to allow this -information to be cleared from memory. The implementation does not currently -allow this. - - </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" target="_top">Add -a string-based cacheKey property for domain isolation</a><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 patch -Firefox to provide a cacheDomain cache attribute. We use the url bar -FQDN as input to this field. - - </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" target="_top">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" target="_top"> -@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 -ruin our day, and censorship filters). Hence we rolled our own. - </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" target="_top">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"><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" target="_top">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 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></ol></div></div></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="BuildSecurity"></a>5. Build Security and Package Integrity</h2></div></div></div><p>
- </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" target="_top">Disable SSL Session ID tracking</a><p> +In the age of state-sponsored malware, <a class="ulink" href="https://blog.torproject.org/blog/deterministic-builds-part-one-cyberwar-and-global-compromise" target="_top">we +believe</a> it is impossible to expect to keep a single build machine or +software signing key secure, given the class of adversaries that Tor has to +contend with. For this reason, we have deployed a build system +that allows anyone to use our source code to reproduce byte-for-byte identical +binary packages to the ones that we distribute.
-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><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idp37001088"></a>5.1. Achieving Binary Reproducibility</h3></div></div></div><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" target="_top">Provide an observer event to close persistent connections</a><p> +The GNU toolchain has been working on providing reproducible builds for some +time, however a large software project such as Firefox typically ends up +embedding a large number of details about the machine it was built on, both +intentionally and inadvertently. Additionally, manual changes to the build +machine configuration can accumulate over time and are difficult for others to +replicate externally, which leads to difficulties with binary reproducibility.
-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="4.7. Long-Term Unlinkability via "New Identity" 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" target="_top">Limit Device and System Specific Media Queries</a><p> - -<a class="ulink" href="https://developer.mozilla.org/en-US/docs/CSS/Media_queries" target="_top">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" target="_top">Limit the number of fonts per document</a><p> - -Font availability can be <a class="ulink" href="http://flippingtypical.com/" target="_top">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. We do this by explicitly altering the -nsRuleNode rule represenation itself to remove the local font families before -the rule hits the font renderer. - - </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" target="_top">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" target="_top">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><p> +For this reason, we decided to leverage the work done by the <a class="ulink" href="http://gitian.org/" target="_top">Gitian Project</a> from the Bitcoin community. +Gitian is a wrapper around Ubuntu's virtualization tools that allows you to +specify an Ubuntu version, architecture, a set of additional packages, a set +of input files, and a bash build scriptlet in an YAML document called a +"Gitian Descriptor". This document is used to install a qemu-kvm image, and +execute your build scriptlet inside it. + </p><p>
- </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" target="_top">Add DDG and StartPage to Omnibox</a><p> +We have created a <a class="ulink" href="https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/refs/heads/master" target="_top">set +of wrapper scripts</a> around Gitian to automate dependency download and +authentication, as well as transfer intermediate build outputs between the +stages of the build process. Because Gitian creates an Ubuntu build +environment, we must use cross-compilation to create packages for Windows and +Mac OS. For Windows, we use mingw-w64 as our cross compiler. For Mac OS, we +use toolchain4 in combination with a binary redistribution of the Mac OS 10.6 +SDK.
-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><p>
- </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" target="_top">Make nsICacheService.EvictEntries() Synchronous</a><p> +The use of the Gitian system eliminates build non-determinism by normalizing +the build environment's hostname, username, build path, uname output, +toolchain versions, and time. On top of what Gitian provides, we also had to +address the following additional sources of non-determinism:
-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><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem">Filesystem and archive reordering + <p>
- </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" target="_top">Prevent WebSockets DNS Leak</a><p> +The most prevalent source of non-determinism in the components of Tor Browser +by far was various ways that archives (such as zip, tar, jar/ja, DMG, and +Firefox manifest lists) could be reordered. Many file archivers walk the +filesystem in inode structure order by default, which will result in ordering +differences between two different archive invocations, especially on machines +of different disk and hardware configurations.
-This patch prevents a DNS leak when using WebSockets. It also prevents other -similar types of DNS leaks. + </p><p>
- </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" target="_top">Randomize HTTP pipeline order and depth</a><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"><a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0018-Emit-observer-event-to-filter-the-Drag-Drop-url-list.patch" target="_top">Emit -an observer event to filter the Drag and Drop URL list</a><p> +The fix for this is to perform an additional sorting step on the input list +for archives, but care must be taken to instruct libc and other sorting routines +to use a fixed locale to determine lexicographic ordering, or machines with +different locale settings will produce different sort results. We chose the +'C' locale for this purpose. We created wrapper scripts for <a class="ulink" href="https://gitweb.torproject.org/builders/tor-browser-bundle.git/blob/HEAD:/gitian/build-helpers/dtar.sh" target="_top">tar</a>, +<a class="ulink" href="https://gitweb.torproject.org/builders/tor-browser-bundle.git/blob/HEAD:/gitian/build-helpers/dzip.sh" target="_top">zip</a>, +and <a class="ulink" href="https://gitweb.torproject.org/builders/tor-browser-bundle.git/blob/HEAD:/gitian/build-helpers/ddmg.sh" target="_top">DMG</a> +to aid in reproducible archive creation. + + </p></li><li class="listitem">Uninitialized memory in toolchain/archivers + <p> + +We ran into difficulties with both binutils and the DMG archive script using +uninitialized memory in certain data structures that ended up written to disk. +Our binutils fixes were merged upstream, but the DMG archive fix remains an +<a class="ulink" href="https://gitweb.torproject.org/builders/tor-browser-bundle.git/blob/HEAD:/gitian/patches/libdmg.patch" target="_top">independent +patch</a>. + + </p></li><li class="listitem">Fine-grained timestamps and timezone leaks + <p> + +The standard way of controlling timestamps in Gitian is to use libfaketime, +which hooks time-related library calls to provide a fixed timestamp. However, +libfaketime does not spoof the millisecond and microsecond components of +timestamps, which found their way into pyc files and also in explicit Firefox +build process timestamp embedding. + </p><p>
-This patch allows us to block external Drag and Drop events from Torbutton. -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). This can lead to proxy bypass -during user activity that is as basic as holding down the mouse button for -slightly too long while clicking on an image link. +We addressed the Firefox issues with direct patches to their build process, +which have since been merged. However, pyc timestamps had to be address with +an additional <a class="ulink" href="https://gitweb.torproject.org/builders/tor-browser-bundle.git/blob/HEAD:/gitian/build-helpers/pyc-timestamp.sh" target="_top">helper +script</a>. + </p><p>
- </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" target="_top">Add mozIThirdPartyUtil.getFirstPartyURI() API</a><p> +The timezone leaks were addressed by setting the <span class="command"><strong>TZ</strong></span> +environment variable to UTC in our descriptors.
-This patch provides an API that allows us to more easily isolate identifiers -to the URL bar domain. + </p></li><li class="listitem">Deliberately generated entropy + <p>
- </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" target="_top">Add canvas image extraction prompt</a><p> +In two circumstances, deliberately generated entropy was introduced in various +components of the build process. First, the BuildID Debuginfo identifier +(which associates detached debug files with their corresponding stripped +executables) was introducing entropy from some unknown source. We removed this +header using objcopy invocations in our build scriptlets, and opted to use GNU +DebugLink instead of BuildID for this association.
-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. + </p><p>
- </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" target="_top">Return client window coordinates for mouse events</a><p> +Second, on Linux, Firefox builds detached signatures of its cryptographic +libraries using a temporary key for FIPS-140 certification. A rather insane +subsection of the FIPS-140 certification standard requires that you distribute +signatures for all of your cryptographic libraries. The Firefox build process +meets this requirement by generating a temporary key, using it to sign the +libraries, and discarding the private portion of that key. Because there are +many other ways to intercept the crypto outside of modifying the actual DLL +images, we opted to simply remove these signature files from distribution. +There simply is no way to verify code integrity on a running system without +both OS and co-processor assistance. Download package signatures make sense of +course, but we handle those another way (as mentioned above).
-This patch causes mouse events to return coordinates relative to the content -window instead of the desktop.
- </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" target="_top">Do not expose physical screen info to window.screen</a><p> + </p></li><li class="listitem">LXC-specific leaks + <p>
-This patch causes window.screen to return the display resolution size of the -content window instead of the desktop resolution size. +Gitian provides an option to use LXC containers instead of full qemu-kvm +virtualization. Unfortunately, these containers can allow additional details +about the host OS to leak. In particular, umask settings as well as the +hostname and Linux kernel version can leak from the host OS into the LXC +container. We addressed umask by setting it explicitly in our Gitian +descriptor scriptlet, and addressed the hostname and kernel version leaks by +directly patching the aspects of the Firefox build process that included this +information into the build. + </p></li></ol></div></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idp37036336"></a>5.2. Package Signatures and Verification</h3></div></div></div><p> + +The build process produces a single sha256sums.txt file that contains a sorted +list the SHA-256 hashes of every package produced for that build version. Each +official builder uploads this file and a GPG signature of it to a directory +on a Tor Project's web server. The build scripts have an optional matching +step that downloads these signatures, verifies them, and ensures that the +local builds match this file.
- </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" target="_top">Do not expose system colors to CSS or canvas</a><p> + </p><p>
-This patch prevents CSS and Javascript from discovering your desktop color -scheme and/or theme. +When builds are published officially, the single sha256sums.txt file is +accompanied by a detached GPG signature from each official builder that +produced a matching build. The packages are additionally signed with detached +GPG signatures from an official signing key.
- </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" target="_top">Isolate the Image Cache per url bar domain</a><p> + </p><p>
-This patch prevents cached images from being used to store third party tracking -identifiers. +The fact that the entire set of packages for a given version can be +authenticated by a single hash of the sha256sums.txt file will also allow us +to create a number of auxiliary authentication mechanisms for our packages, +beyond just trusting a single offline build machine and a single cryptographic +key's integrity. Interesting examples include providing multiple independent +cryptographic signatures for packages, listing the package hashes in the Tor +consensus, and encoding the package hashes in the Bitcoin blockchain.
- </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" target="_top">nsIHTTPChannel.redirectTo() API</a><p> + </p><p>
-This patch provides HTTPS-Everywhere with an API to perform redirections more -securely and without addon conflicts. +At the time of this writing, we do not yet support native code signing for Mac +OS or Windows. Because these signatures are embedded in the actual packages, +and by their nature are based on non-public key material, providing native +code-signed packages while still preserving ease of reproducibility +verification has not yet been achieved.
- </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" target="_top">Isolate DOM Storage to first party URI</a><p> + </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idp37040272"></a>5.3. Anonymous Verification</h3></div></div></div><p>
-This patch prevents DOM Storage from being used to store third party tracking -identifiers. +Due to the fact that bit-identical packages can be produced by anyone, the +security of this build system extends beyond the security of the official +build machines. In fact, it is still possible for build integrity to be +achieved even if all official build machines are compromised.
- </p></li><li class="listitem"><a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0027-Remove-This-plugin-is-disabled-barrier.patch" target="_top">Remove -"This plugin is disabled" barrier</a><p> + </p><p>
-This patch removes a barrier that was informing users that plugins were -disabled and providing them with a link to enable them. We felt this was poor -user experience, especially since the barrier was displayed even for sites -with dual Flash+HTML5 video players, such as YouTube. +By default, all tor-specific dependencies and inputs to the build process are +downloaded over Tor, which allows build verifiers to remain anonymous and +hidden. Because of this, any individual can use our anonymity network to +privately download our source code, verify it against public signed, audited, +and mirrored git repositories, and reproduce our builds exactly, without being +subject to targeted attacks. If they notice any differences, they can alert +the public builders/signers, hopefully using a pseudonym or our anonymous +bugtracker account, to avoid revealing the fact that they are a build +verifier.
- </p></li></ol></div></div></div><div class="appendix" title="A. Towards Transparency in Navigation Tracking"><h2 class="title" style="clear: both"><a id="Transparency"></a>A. Towards Transparency in Navigation Tracking</h2><p> + </p></div></div><div class="appendix"><h2 class="title" style="clear: both"><a id="Transparency"></a>A. Towards Transparency in Navigation Tracking</h2><p>
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 @@ -1554,7 +1667,7 @@ also describe auditable alternatives and promising web draft standards that woul preserve this functionality while still providing transparency when tracking is occurring.
-</p><div class="sect1" title="A.1. Deprecation Wishlist"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="deprecate"></a>A.1. Deprecation Wishlist</h2></div></div></div><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem">The Referer Header +</p><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="deprecate"></a>A.1. Deprecation Wishlist</h2></div></div></div><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem">The Referer Header <p>
We haven't disabled or restricted the Referer ourselves because of the @@ -1617,7 +1730,7 @@ possible for us to <a class="ulink" href="https://trac.torproject.org/projects/t ourselves</a>, as they are comparatively rare and can be handled with site permissions.
- </p></li></ol></div></div><div class="sect1" title="A.2. Promising Standards"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="idp5896048"></a>A.2. Promising Standards</h2></div></div></div><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><a class="ulink" href="http://web-send.org" target="_top">Web-Send Introducer</a><p> + </p></li></ol></div></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="idp37071376"></a>A.2. Promising Standards</h2></div></div></div><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><a class="ulink" href="http://web-send.org" target="_top">Web-Send Introducer</a><p>
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 @@ -1633,4 +1746,4 @@ 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> + </p></li></ol></div></div></div></div></body></html> \ No newline at end of file
tor-commits@lists.torproject.org
-
mikeperry＠torproject.org