commit a7b44b6f813146d2f0fc4a138d8b33208291df67 Author: Mike Perry mikeperry-git@torproject.org Date: Mon Apr 28 17:16:29 2014 +0200

Relocate some directories. --- design-doc/CookieManagers.png | Bin 0 -> 113551 bytes design-doc/Firefox17-TODO | 82 ++ design-doc/NewCookieManager.png | Bin 0 -> 27939 bytes design-doc/build.sh | 1 + design-doc/design.xml | 2733 ++++++++++++++++++++++++++++++++++++++ design-doc/outline.txt | 52 + docs/audits/FF17_FEATURE_AUDIT | 19 - docs/audits/FF17_NETWORK_AUDIT | 84 -- docs/audits/FF3.5_AUDIT | 195 --- docs/audits/FF4_AUDIT | 50 - docs/design/CookieManagers.png | Bin 113551 -> 0 bytes docs/design/Firefox17-TODO | 82 -- docs/design/NewCookieManager.png | Bin 27939 -> 0 bytes docs/design/build.sh | 1 - docs/design/design.xml | 2733 -------------------------------------- docs/design/outline.txt | 52 - 16 files changed, 2868 insertions(+), 3216 deletions(-)

diff --git a/design-doc/CookieManagers.png b/design-doc/CookieManagers.png new file mode 100644 index 0000000..0fc3e64 Binary files /dev/null and b/design-doc/CookieManagers.png differ diff --git a/design-doc/Firefox17-TODO b/design-doc/Firefox17-TODO new file mode 100644 index 0000000..41ef38e --- /dev/null +++ b/design-doc/Firefox17-TODO @@ -0,0 +1,82 @@ ++ Cleanups + + We specify browser.cache.memory.enable under disk avoidance. That's + wrong. We don't even set it at all. Torbutton relic? + + Disk leak documentation + + Firefox 17 will mess up all patch links + +- Heavy Writing by section + + Intro: + + We target Firefox ESR + + Component description + + Deprecation List/Future Philosophy: + + Linkability Transparency from + https://trac.torproject.org/projects/tor/ticket/5273#comment:12 + + Adversary Goals + + Describe how each adversary attack violates design goals + + "Correlate activity across multiple site visits" as one of the adversary + goals. This is the primary goal of the ad networks, though. We need to + explicitly mention it in the Adversary Goals section for completeness. + + Misc implementation + + Link to prefs.js and describe omni.ja and extension-overrides hacks + + document the environment variables and settings used to provide a non-grey "New Identity" button. + + Mockup privacy UI + + Identifier Linkability + + Image cache jail + + DOM storage jail + + 3.5.8 is not clear that what we're trying to limit is non-click + driven/non-interactive linkability rather than linkability in all cases. + Other sections may have this problem, too. + + This is a subtlety that arises from both the impossibility of satisfying + unlinkability due to covert channels in GET/POST, as well as the desire + to avoid breaking thinks like consensual federated login. + - Fingerprinting + + @font-face exemption and preference + + Canvas prompt + + describe our resolution defenses + + Limit CSS media queries + + System colors + fonts + + Explain why panopticlick is weirdsauce + + We report our useragent as 17.0 + + Click-to-play WebGL + + We should perhaps be more vocal about the fingerprinting issues with + some or all of http://www.w3.org/TR/navigation-timing/. I think I agree. + - provide an entropy count estimate for fingerprinting defenses + + Disk avoidance + + Private browsing + pref changes + + He reminded me about documenting disabling IndexedDB, but that is just one + of the many prefs.js changes we need to document. + - Testing + - Explain why panopticlick is weirdsauce + - Sync with QA pages + - Many are out of date + - http://www.stayinvisible.com/ + - Evercookie test page, and perhaps also + http://jeremiahgrossman.blogspot.de/2007/04/tracking-users-without-cookies.h... + +- Misc changes: + + Plugin handling + + All-but-flash patch + + Plugin manager manipulation + + We use Firefox's click-to-play + + Addons + + PDF.js inclusion + + List links to design violations/enhancements: + + https://trac.torproject.org/projects/tor/query?keywords=~tbb-linkability + + https://trac.torproject.org/projects/tor/query?keywords=~tbb-fingerprinting + - Update notification/version checking? + - Create a deprecation list and link to it: + - Referer Header + - Window.name + - We should only preserve window.name if the url bar domain remains the + same. I could be convinced of this, but it's going to be trickier to + implement and I think it's not really possible to remove linkability for user + clicks in general. + - Torbutton Security Settings + +- Packaging + - Pref changes + - Socks ports + - Torbutton does not update + + + diff --git a/design-doc/NewCookieManager.png b/design-doc/NewCookieManager.png new file mode 100644 index 0000000..97a0b40 Binary files /dev/null and b/design-doc/NewCookieManager.png differ diff --git a/design-doc/build.sh b/design-doc/build.sh new file mode 100755 index 0000000..5ffb650 --- /dev/null +++ b/design-doc/build.sh @@ -0,0 +1 @@ +xsltproc --output index.html.en -stringparam chunker.output.encoding UTF-8 --stringparam section.autolabel.max.depth 2 -stringparam section.label.includes.component.label 1 --stringparam section.autolabel 1 /usr/share/xml/docbook/stylesheet/docbook-xsl/xhtml/docbook.xsl design.xml diff --git a/design-doc/design.xml b/design-doc/design.xml new file mode 100644 index 0000000..d1cdf0f --- /dev/null +++ b/design-doc/design.xml @@ -0,0 +1,2733 @@ +<?xml version="1.0" encoding="ISO-8859-1"?> +<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN" + "file:///usr/share/sgml/docbook/xml-dtd-4.4-1.0-30.1/docbookx.dtd"> + +<article id="design"> + <articleinfo> + <title>The Design and Implementation of the Tor Browser [DRAFT]</title> + <author> + <firstname>Mike</firstname><surname>Perry</surname> + <affiliation> + <address><email>mikeperry#torproject org</email></address> + </affiliation> + </author> + <author> + <firstname>Erinn</firstname><surname>Clark</surname> + <affiliation> + <address><email>erinn#torproject org</email></address> + </affiliation> + </author> + <author> + <firstname>Steven</firstname><surname>Murdoch</surname> + <affiliation> + <address><email>sjmurdoch#torproject org</email></address> + </affiliation> + </author> + <pubdate>March 15, 2013</pubdate> + </articleinfo> + +<!-- +- Introduction and Threat model: [Mostly Torbutton] + - [Remove the security requirements section] +--> + +<sect1> + <title>Introduction</title> + <para> + +This document describes the <link linkend="adversary">adversary model</link>, +<link linkend="DesignRequirements">design requirements</link>, and <link +linkend="Implementation">implementation</link> <!-- <link +linkend="Packaging">packaging</link> and <link linkend="Testing">testing +procedures</link> --> of the Tor Browser. It is current as of Tor Browser +2.3.25-5 and Torbutton 1.5.1. + + </para> + <para> + +This document is also meant to serve as a set of design requirements and to +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. + + </para> + <sect2 id="components"> + <title>Browser Component Overview</title> + <para> + +The Tor Browser is based on <ulink +url="https://www.mozilla.org/en-US/firefox/organizations/%22%3EMozilla%27s Extended +Support Release (ESR) Firefox branch</ulink>. We have a <link +linkend="firefox-patches">series of patches</link> against this browser to +enhance privacy and security. Browser behavior is additionally augmented +through the <ulink +url="https://gitweb.torproject.org/torbutton.git/tree/master%22%3ETorbutton +extension</ulink>, though we are in the process of moving this +functionality into direct Firefox patches. We also <ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/HEAD:/build-scripts/config... +a number of Firefox preferences</ulink> from their defaults. + + </para> + <para> + +To help protect against potential Tor Exit Node eavesdroppers, we include +<ulink url="https://www.eff.org/https-everywhere">HTTPS-Everywhere</ulink>. To +provide users with optional defense-in-depth against Javascript and other +potential exploit vectors, we also include <ulink +url="http://noscript.net/%22%3ENoScript</ulink>. To protect against +PDF-based Tor proxy bypass and to improve usability, we include the <ulink +url="https://addons.mozilla.org/en-us/firefox/addon/pdfjs/%22%3EPDF.JS</ulink> +extension. We also modify <ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/HEAD:/build-scripts/config... +extension preferences</ulink> from their defaults. + + </para> + </sect2> +</sect1> + +<!-- +- Design overview and philosophy + - Security requirements [Torbutton] + + local leaks? + - state issues + - Privacy Requirements [Mostly blog post] + - Avoid Cross-Domain Linkability + - Indentifiers + - Fingerprinting + - 100% self-contained + - Does not share state with other modes/browsers + - Easy to remove + wipe with external tools + - click-to-play for "troublesome" features + - Philosophy + - No filters +--> + + +<sect1 id="DesignRequirements"> + <title>Design Requirements and Philosophy</title> + <para> + +The Tor Browser Design Requirements are meant to describe the properties of a +Private Browsing Mode that defends against both network and local forensic +adversaries. + + </para> + <para> + +There are two main categories of requirements: <link +linkend="security">Security Requirements</link>, and <link +linkend="privacy">Privacy Requirements</link>. Security Requirements are the +minimum properties in order for a browser to be able to support Tor and +similar privacy proxies safely. Privacy requirements are the set of properties +that cause us to prefer one browser over another. + + </para> + <para> + +While we will endorse the use of browsers that meet the security requirements, +it is primarily the privacy requirements that cause us to maintain our own +browser distribution. + + </para> + <para> + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL + NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + <ulink url="https://www.ietf.org/rfc/rfc2119.txt">RFC 2119</ulink>. + + </para> + + <sect2 id="security"> + <title>Security Requirements</title> + <para> + +The security requirements are primarily concerned with ensuring the safe use +of Tor. Violations in these properties typically result in serious risk for +the user in terms of immediate deanonymization and/or observability. With +respect to browser support, security requirements are the minimum properties +in order for Tor to support the use of a particular browser. + + </para> + +<orderedlist> + <listitem><link linkend="proxy-obedience"><command>Proxy +Obedience</command></link> + <para>The browser +MUST NOT bypass Tor proxy settings for any content.</para></listitem> + + <listitem><link linkend="state-separation"><command>State +Separation</command></link> + + <para> + +The browser MUST NOT provide the content window with any state from any other +browsers or any non-Tor browsing modes. This includes shared state from +independent plugins, and shared state from Operating System implementations of +TLS and other support libraries. + +</para></listitem> + + <listitem><link linkend="disk-avoidance"><command>Disk +Avoidance</command></link> + +<para> + +The browser MUST NOT write any information that is derived from or that +reveals browsing activity to the disk, or store it in memory beyond the +duration of one browsing session, unless the user has explicitly opted to +store their browsing history information to disk. + +</para></listitem> + <listitem><link linkend="app-data-isolation"><command>Application Data +Isolation</command></link> + +<para> + +The components involved in providing private browsing MUST be self-contained, +or MUST provide a mechanism for rapid, complete removal of all evidence of the +use of the mode. In other words, the browser MUST NOT write or cause the +operating system to write <emphasis>any information</emphasis> about the use +of private browsing to disk outside of the application's control. The user +must be able to ensure that secure deletion of the software is sufficient to +remove evidence of the use of the software. All exceptions and shortcomings +due to operating system behavior MUST be wiped by an uninstaller. However, due +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. + +</para></listitem> + +<!-- + <listitem><link linkend="update-safety"><command>Update +Safety</command></link> + +<para>The browser SHOULD NOT perform unsafe updates or upgrades.</para></listitem> +--> +</orderedlist> + + </sect2> + + <sect2 id="privacy"> + <title>Privacy Requirements</title> + <para> + +The privacy requirements are primarily concerned with reducing linkability: +the ability for a user's activity on one site to be linked with their activity +on another site without their knowledge or explicit consent. With respect to +browser support, privacy requirements are the set of properties that cause us +to prefer one browser over another. + + </para> + + <para> + +For the purposes of the unlinkability requirements of this section as well as +the descriptions in the <link linkend="Implementation">implementation +section</link>, a <command>url bar origin</command> means at least the +second-level DNS name. For example, for mail.google.com, the origin would be +google.com. Implementations MAY, at their option, restrict the url bar origin +to be the entire fully qualified domain name. + + </para> + +<orderedlist> + <listitem><link linkend="identifier-linkability"><command>Cross-Origin +Identifier Unlinkability</command></link> + <para> + +User activity on one url bar origin MUST NOT be linkable to their activity in +any other url bar origin by any third party automatically or without user +interaction or approval. This requirement specifically applies to linkability +from stored browser identifiers, authentication tokens, and shared state. The +requirement does not apply to linkable information the user manually submits +to sites, or due to information submitted during manual link traversal. This +functionality SHOULD NOT interfere with interactive, click-driven federated +login in a substantial way. + + </para> + </listitem> + <listitem><link linkend="fingerprinting-linkability"><command>Cross-Origin +Fingerprinting Unlinkability</command></link> + <para> + +User activity on one url bar origin MUST NOT be linkable to their activity in +any other url bar origin by any third party. This property specifically applies to +linkability from fingerprinting browser behavior. + + </para> + </listitem> + <listitem><link linkend="new-identity"><command>Long-Term +Unlinkability</command></link> + <para> + +The browser MUST provide an obvious, easy way for the user to remove all of +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. + + </para> + </listitem> +</orderedlist> + + </sect2> + <sect2 id="philosophy"> + <title>Philosophy</title> + <para> + +In addition to the above design requirements, the technology decisions about +Tor Browser are also guided by some philosophical positions about technology. + + </para> + <orderedlist> + <listitem><command>Preserve existing user model</command> + <para> + +The existing way that the user expects to use a browser must be preserved. If +the user has to maintain a different mental model of how the sites they are +using behave depending on tab, browser state, or anything else that would not +normally be what they experience in their default browser, the user will +inevitably be confused. They will make mistakes and reduce their privacy as a +result. Worse, they may just stop using the browser, assuming it is broken. + + </para> + <para> + +User model breakage was one of the <ulink +url="https://blog.torproject.org/blog/toggle-or-not-toggle-end-torbutton%22%3Efai... +of Torbutton</ulink>: Even if users managed to install everything properly, +the toggle model was too hard for the average user to understand, especially +in the face of accumulating tabs from multiple states crossed with the current +Tor-state of the browser. + + </para> + </listitem> + <listitem><command>Favor the implementation mechanism least likely to +break sites</command> + <para> + +In general, we try to find solutions to privacy issues that will not induce +site breakage, though this is not always possible. + + </para> + </listitem> + <listitem><command>Plugins must be restricted</command> + <para> + +Even if plugins always properly used the browser proxy settings (which none of +them do) and could not be induced to bypass them (which all of them can), the +activities of closed-source plugins are very difficult to audit and control. +They can obtain and transmit all manner of system information to websites, +often have their own identifier storage for tracking users, and also +contribute to fingerprinting. + + </para> + <para> + +Therefore, if plugins are to be enabled in private browsing modes, they must +be restricted from running automatically on every page (via click-to-play +placeholders), and/or be sandboxed to restrict the types of system calls they +can execute. If the user agent allows the user to craft an exemption to allow +a plugin to be used automatically, it must only apply to the top level url bar +domain, and not to all sites, to reduce cross-origin fingerprinting +linkability. + + </para> + </listitem> + <listitem><command>Minimize Global Privacy Options</command> + <para> + +<ulink url="https://trac.torproject.org/projects/tor/ticket/3100">Another +failure of Torbutton</ulink> was the options panel. Each option +that detectably alters browser behavior can be used as a fingerprinting tool. +Similarly, all extensions <ulink +url="http://blog.chromium.org/2010/06/extensions-in-incognito.html%22%3Eshould be +disabled in the mode</ulink> except as an opt-in basis. We should not load +system-wide and/or Operating System provided addons or plugins. + + </para> + <para> +Instead of global browser privacy options, privacy decisions should be made +<ulink +url="https://wiki.mozilla.org/Privacy/Features/Site-based_data_management_UI%22%3... +url bar origin</ulink> 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 +privacy permissions. + </para> + <para> +If the user has indicated they wish to record local history storage, these +permissions can be written to disk. Otherwise, they should remain memory-only. + </para> + </listitem> + <listitem><command>No filters</command> + <para> + +Site-specific or filter-based addons such as <ulink +url="https://addons.mozilla.org/en-US/firefox/addon/adblock-plus/%22%3EAdBlock +Plus</ulink>, <ulink url="http://requestpolicy.com/">Request Policy</ulink>, +<ulink url="http://www.ghostery.com/about">Ghostery</ulink>, <ulink +url="http://priv3.icsi.berkeley.edu/%22%3EPriv3</ulink>, and <ulink +url="http://sharemenot.cs.washington.edu/%22%3ESharemenot</ulink> are to be +avoided. We believe that these addons do not add any real privacy to a proper +<link linkend="Implementation">implementation</link> of the above <link +linkend="privacy">privacy requirements</link>, and that development efforts +should be focused on general solutions that prevent tracking by all +third parties, rather than a list of specific URLs or hosts. + </para> + <para> +Filter-based addons can also introduce strange breakage and cause usability +nightmares, and will also fail to do their job if an adversary simply +registers a new domain or creates a new url path. Worse still, the unique +filter sets that each user creates or installs will provide a wealth of +fingerprinting targets. + </para> + <para> + +As a general matter, we are also generally opposed to shipping an always-on Ad +blocker with Tor Browser. We feel that this would damage our credibility in +terms of demonstrating that we are providing privacy through a sound design +alone, as well as damage the acceptance of Tor users by sites that support +themselves through advertising revenue. + + </para> + <para> +Users are free to install these addons if they wish, but doing +so is not recommended, as it will alter the browser request fingerprint. + </para> + </listitem> + <listitem><command>Stay Current</command> + <para> +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. + </para> + </listitem> +<!-- + <listitem><command>Transparency in Navigation Tracking</command> + <para> + +While we believe it is possible to restrict third party tracking with only +minimal site breakage, it is our long-term goal to further reduce cross-origin +click navigation tracking to mechanisms that are detectable by experts and +attentive users, so they can alert the general public if cross-origin +click navigation tracking is happening where it should not be. + + </para> + <para> + +However, the entrenched nature of certain archaic web features make it +impossible for us to achieve this wider goal by ourselves without substantial +site breakage. So, instead we maintain a <link linkend="deprecate">Deprecation +Wishlist</link> of archaic web technologies that are currently being (ab)used +to facilitate federated login and other legitimate click-driven cross-domain +activity but that can one day be replaced with more privacy friendly, +auditable alternatives. + + </para> + </listitem> +--> + </orderedlist> + </sect2> +</sect1> + +<!-- +- Implementation + - Section Template + - Sub Section + - "Design Goal": + - "Implementation Status" + - Local Privacy + - Linkability + - Stored State + - Cookies + - Cache + - DOM Storage + - HTTP Auth + - SSL state + - Plugins + - Fingerprinting + - Location + timezone is part of this + - Patches? +--> + <sect1 id="adversary"> + <title>Adversary Model</title> + <para> + +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. + + </para> + <sect2 id="adversary-goals"> + <title>Adversary Goals</title> + <orderedlist> +<!-- These aren't really commands.. But it's the closest I could find in an +acceptable style.. Don't really want to make my own stylesheet --> + <listitem><command>Bypassing proxy settings</command> + <para>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.</para> + </listitem> + <listitem><command>Correlation of Tor vs Non-Tor Activity</command> + <para>If direct proxy bypass is not possible, the adversary will likely +happily settle for the ability to correlate something a user did via Tor with +their non-Tor activity. This can be done with cookies, cache identifiers, +javascript events, and even CSS. Sometimes the fact that a user uses Tor may +be enough for some authorities.</para> + </listitem> + <listitem><command>History disclosure</command> + <para> +The adversary may also be interested in history disclosure: the ability to +query a user's history to see if they have issued certain censored search +queries, or visited censored sites. + </para> + </listitem> + <listitem><command>Correlate activity across multiple sites</command> + <para> + +The primary goal of the advertising networks is to know that the user who +visited siteX.com is the same user that visited siteY.com to serve them +targeted ads. The advertising networks become our adversary insofar as they +attempt to perform this correlation without the user's explicit consent. + + </para> + </listitem> + <listitem><command>Fingerprinting/anonymity set reduction</command> + <para> + +Fingerprinting (more generally: "anonymity set reduction") is used to attempt +to gather identifying information on a particular individual without the use +of tracking identifiers. If the dissident or whistleblower's timezone is +available, and they are using a rare build of Firefox for an obscure operating +system, and they have a specific display resolution only used on one type of +laptop, this can be very useful information for tracking them down, or at +least <link linkend="fingerprinting">tracking their activities</link>. + + </para> + </listitem> + <listitem><command>History records and other on-disk +information</command> + <para> +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. + </para> + </listitem> + </orderedlist> + </sect2> + + <sect2 id="adversary-positioning"> + <title>Adversary Capabilities - Positioning</title> + <para> +The adversary can position themselves at a number of different locations in +order to execute their attacks. + </para> + <orderedlist> + <listitem><command>Exit Node or Upstream Router</command> + <para> +The adversary can run exit nodes, or alternatively, they may control routers +upstream of exit nodes. Both of these scenarios have been observed in the +wild. + </para> + </listitem> + <listitem><command>Ad servers and/or Malicious Websites</command> + <para> +The adversary can also run websites, or more likely, they can contract out +ad space from a number of different ad servers and inject content that way. For +some users, the adversary may be the ad servers themselves. It is not +inconceivable that ad servers may try to subvert or reduce a user's anonymity +through Tor for marketing purposes. + </para> + </listitem> + <listitem><command>Local Network/ISP/Upstream Router</command> + <para> +The adversary can also inject malicious content at the user's upstream router +when they have Tor disabled, in an attempt to correlate their Tor and Non-Tor +activity. + </para> + <para> + +Additionally, at this position the adversary can block Tor, or attempt to +recognize the traffic patterns of specific web pages at the entrance to the Tor +network. + + </para> + </listitem> + <listitem><command>Physical Access</command> + <para> +Some users face adversaries with intermittent or constant physical access. +Users in Internet cafes, for example, face such a threat. In addition, in +countries where simply using tools like Tor is illegal, users may face +confiscation of their computer equipment for excessive Tor usage or just +general suspicion. + </para> + </listitem> + </orderedlist> + </sect2> + + <sect2 id="attacks"> + <title>Adversary Capabilities - Attacks</title> + <para> + +The adversary can perform the following attacks from a number of different +positions to accomplish various aspects of their goals. It should be noted +that many of these attacks (especially those involving IP address leakage) are +often performed by accident by websites that simply have Javascript, dynamic +CSS elements, and plugins. Others are performed by ad servers seeking to +correlate users' activity across different IP addresses, and still others are +performed by malicious agents on the Tor network and at national firewalls. + + </para> + <orderedlist> + <listitem><command>Read and insert identifiers</command> + <para> + +The browser contains multiple facilities for storing identifiers that the +adversary creates for the purposes of tracking users. These identifiers are +most obviously cookies, but also include HTTP auth, DOM storage, cached +scripts and other elements with embedded identifiers, client certificates, and +even TLS Session IDs. + + </para> + <para> + +An adversary in a position to perform MITM content alteration can inject +document content elements to both read and inject cookies for arbitrary +domains. In fact, even many "SSL secured" websites are vulnerable to this sort of +<ulink url="http://seclists.org/bugtraq/2007/Aug/0070.html">active +sidejacking</ulink>. In addition, the ad networks of course perform tracking +with cookies as well. + + </para> + <para> + +These types of attacks are attempts at subverting our <link +linkend="identifier-linkability">Cross-Origin Identifier Unlinkability</link> and <link +linkend="new-identity">Long-Term Unlikability</link> design requirements. + + </para> + </listitem> + <listitem id="fingerprinting"><command>Fingerprint users based on browser +attributes</command> +<para> + +There is an absurd amount of information available to websites via attributes +of the browser. This information can be used to reduce anonymity set, or even +uniquely fingerprint individual users. Attacks of this nature are typically +aimed at tracking users across sites without their consent, in an attempt to +subvert our <link linkend="fingerprinting-linkability">Cross-Origin +Fingerprinting Unlinkability</link> and <link +linkend="new-identity">Long-Term Unlikability</link> design requirements. + +</para> + +<para> + +Fingerprinting is an intimidating +problem to attempt to tackle, especially without a metric to determine or at +least intuitively understand and estimate which features will most contribute +to linkability between visits. + +</para> + +<para> + +The <ulink url="https://panopticlick.eff.org/about.php">Panopticlick study +done</ulink> by the EFF uses the <ulink +url="https://en.wikipedia.org/wiki/Entropy_%28information_theory%29%22%3EShannon +entropy</ulink> - the number of identifying bits of information encoded in +browser properties - as this metric. Their <ulink +url="https://wiki.mozilla.org/Fingerprinting#Data%22%3Eresult data</ulink> is +definitely useful, and the metric is probably the appropriate one for +determining how identifying a particular browser property is. However, some +quirks of their study means that they do not extract as much information as +they could from display information: they only use desktop resolution and do +not attempt to infer the size of toolbars. In the other direction, they may be +over-counting in some areas, as they did not compute joint entropy over +multiple attributes that may exhibit a high degree of correlation. Also, new +browser features are added regularly, so the data should not be taken as +final. + + </para> + <para> + +Despite the uncertainty, all fingerprinting attacks leverage the following +attack vectors: + + </para> + <orderedlist> + <listitem><command>Observing Request Behavior</command> + <para> + +Properties of the user's request behavior comprise the bulk of low-hanging +fingerprinting targets. These include: User agent, Accept-* headers, pipeline +usage, and request ordering. Additionally, the use of custom filters such as +AdBlock and other privacy filters can be used to fingerprint request patterns +(as an extreme example). + + </para> + </listitem> + + <listitem><command>Inserting Javascript</command> + <para> + +Javascript can reveal a lot of fingerprinting information. It provides DOM +objects such as window.screen and window.navigator to extract information +about the useragent. + +Also, Javascript can be used to query the user's timezone via the +<function>Date()</function> object, <ulink +url="https://www.khronos.org/registry/webgl/specs/1.0/#5.13%22%3EWebGL</ulink> can +reveal information about the video card in use, and high precision timing +information can be used to <ulink +url="http://w2spconf.com/2011/papers/jspriv.pdf%22%3Efingerprint the CPU and +interpreter speed</ulink>. In the future, new JavaScript features such as +<ulink url="http://w3c-test.org/webperf/specs/ResourceTiming/">Resource +Timing</ulink> may leak an unknown amount of network timing related +information. + +<!-- FIXME: resource-timing stuff? --> + + </para> + </listitem> + + <listitem><command>Inserting Plugins</command> + <para> + +The Panopticlick project found that the mere list of installed plugins (in +navigator.plugins) was sufficient to provide a large degree of +fingerprintability. Additionally, plugins are capable of extracting font lists, +interface addresses, and other machine information that is beyond what the +browser would normally provide to content. In addition, plugins can be used to +store unique identifiers that are more difficult to clear than standard +cookies. <ulink url="http://epic.org/privacy/cookies/flash.html">Flash-based +cookies</ulink> fall into this category, but there are likely numerous other +examples. Beyond fingerprinting, plugins are also abysmal at obeying the proxy +settings of the browser. + + + </para> + </listitem> + <listitem><command>Inserting CSS</command> + <para> + +<ulink url="https://developer.mozilla.org/En/CSS/Media_queries">CSS media +queries</ulink> can be inserted to gather information about the desktop size, +widget size, display type, DPI, user agent type, and other information that +was formerly available only to Javascript. + + </para> + </listitem> + </orderedlist> + </listitem> + <listitem id="website-traffic-fingerprinting"><command>Website traffic fingerprinting</command> + <para> + +Website traffic fingerprinting is an attempt by the adversary to recognize the +encrypted traffic patterns of specific websites. In the case of Tor, this +attack would take place between the user and the Guard node, or at the Guard +node itself. + </para> + + <para> The most comprehensive study of the statistical properties of this +attack against Tor was done by <ulink +url="http://lorre.uni.lu/~andriy/papers/acmccs-wpes11-fingerprinting.pdf%22%3EPan... +et al</ulink>. Unfortunately, the publication bias in academia has encouraged +the production of a number of follow-on attack papers claiming "improved" +success rates, in some cases even claiming to completely invalidate any +attempt at defense. These "improvements" are actually enabled primarily by +taking a number of shortcuts (such as classifying only very small numbers of +web pages, neglecting to publish ROC curves or at least false positive rates, +and/or omitting the effects of dataset size on their results). Despite these +subsequent "improvements", we are skeptical of the efficacy of this attack in +a real world scenario, <emphasis>especially</emphasis> in the face of any +defenses. + + </para> + <para> + +In general, with machine learning, as you increase the <ulink +url="https://en.wikipedia.org/wiki/VC_dimension%22%3Enumber and/or complexity of +categories to classify</ulink> while maintaining a limit on reliable feature +information you can extract, you eventually run out of descriptive feature +information, and either true positive accuracy goes down or the false positive +rate goes up. This error is called the <ulink +url="http://www.cs.washington.edu/education/courses/csep573/98sp/lectures/lecture... +in your hypothesis space</ulink>. In fact, even for unbiased hypothesis +spaces, the number of training examples required to achieve a reasonable error +bound is <ulink +url="https://en.wikipedia.org/wiki/Probably_approximately_correct_learning#Equiva... +function of the complexity of the categories</ulink> you need to classify. + + </para> + <para> + + +In the case of this attack, the key factors that increase the classification +complexity (and thus hinder a real world adversary who attempts this attack) +are large numbers of dynamically generated pages, partially cached content, +and also the non-web activity of entire Tor network. This yields an effective +number of "web pages" many orders of magnitude larger than even <ulink +url="http://lorre.uni.lu/~andriy/papers/acmccs-wpes11-fingerprinting.pdf%22%3EPan... +"Open World" scenario</ulink>, which suffered continous 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 +to manipulate at low cost. + + </para> + <para> + +To make matters worse for a real-world adversary, the ocean of Tor Internet +activity (at least, when compared to a lab setting) makes it a certainty that +an adversary attempting examine large amounts of Tor traffic will ultimately +be overwhelmed by false positives (even after making heavy tradeoffs on the +ROC curve to minimize false positives to below 0.01%). This problem is known +in the IDS literature as the <ulink +url="http://www.raid-symposium.org/raid99/PAPERS/Axelsson.pdf%22%3EBase Rate +Fallacy</ulink>, and it is the primary reason that anomaly and activity +classification-based IDS and antivirus systems have failed to materialize in +the marketplace (despite early success in academic literature). + + </para> + <para> + +Still, we do not believe that these issues are enough to dismiss the attack +outright. But we do believe these factors make it both worthwhile and +effective to <link linkend="traffic-fingerprinting-defenses">deploy +light-weight defenses</link> that reduce the accuracy of this attack by +further contributing noise to hinder successful feature extraction. + + </para> + </listitem> + <listitem><command>Remotely or locally exploit browser and/or +OS</command> + <para> + +Last, but definitely not least, the adversary can exploit either general +browser vulnerabilities, plugin vulnerabilities, or OS vulnerabilities to +install malware and surveillance software. An adversary with physical access +can perform similar actions. + + </para> + <para> + +For the purposes of the browser itself, we limit the scope of this adversary +to one that has passive forensic access to the disk after browsing activity +has taken place. This adversary motivates our +<link linkend="disk-avoidance">Disk Avoidance</link> defenses. + + </para> + <para> + +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. <ulink +url="http://tails.boum.org/contribute/design/%22%3EThe Tails system</ulink> 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. + + </para> + </listitem> + </orderedlist> + </sect2> + +</sect1> + +<sect1 id="Implementation"> + <title>Implementation</title> + <para> + +The Implementation section is divided into subsections, each of which +corresponds to a <link linkend="DesignRequirements">Design Requirement</link>. +Each subsection is divided into specific web technologies or properties. The +implementation is then described for that property. + + </para> + <para> + +In some cases, the implementation meets the design requirements in a non-ideal +way (for example, by disabling features). In rare cases, there may be no +implementation at all. Both of these cases are denoted by differentiating +between the <command>Design Goal</command> and the <command>Implementation +Status</command> for each property. Corresponding bugs in the <ulink +url="https://trac.torproject.org/projects/tor/report%22%3ETor bug tracker</ulink> +are typically linked for these cases. + + </para> + <sect2 id="proxy-obedience"> + <title>Proxy Obedience</title> + <para> + +Proxy obedience is assured through the following: + </para> +<orderedlist> + <listitem>Firefox proxy settings, patches, and build flags + <para> +Our <ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/HEAD:/build-scripts/config... +preferences file</ulink> sets the Firefox proxy settings to use Tor directly as a +SOCKS proxy. It sets <command>network.proxy.socks_remote_dns</command>, +<command>network.proxy.socks_version</command>, +<command>network.proxy.socks_port</command>, and +<command>network.dns.disablePrefetch</command>. + </para> + <para> + +We also patch Firefox in order to <ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... +a DNS leak due to a WebSocket rate-limiting check</ulink>. As stated in the +patch, we believe the direct DNS resolution performed by this check is in +violation of the W3C standard, but <ulink +url="https://bugzilla.mozilla.org/show_bug.cgi?id=751465%22%3Ethis DNS proxy leak +remains present in stock Firefox releases</ulink>. + + </para> + <para> + +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 +<command>--disable-webrtc</command>. + + </para> + <para> + +We have verified that these settings and patches properly proxy HTTPS, OCSP, +HTTP, FTP, gopher (now defunct), DNS, SafeBrowsing Queries, all javascript +activity, including HTML5 audio and video objects, addon updates, wifi +geolocation queries, searchbox queries, XPCOM addon HTTPS/HTTP activity, +WebSockets, and live bookmark updates. We have also verified that IPv6 +connections are not attempted, through the proxy or otherwise (Tor does not +yet support IPv6). We have also verified that external protocol helpers, such +as smb urls and other custom protocol handlers are all blocked. + + </para> + <para> + +Numerous other third parties have also reviewed and tested the proxy settings +and have provided test cases based on their work. See in particular <ulink +url="http://decloak.net/%22%3Edecloak.net</ulink>. + + </para> +</listitem> + + <listitem>Disabling plugins + + <para>Plugins have the ability to make arbitrary OS system calls and <ulink +url="http://decloak.net/%22%3Ebypass proxy settings</ulink>. This includes +the ability to make UDP sockets and send arbitrary data independent of the +browser proxy settings. + </para> + <para> +Torbutton disables plugins by using the +<command>@mozilla.org/plugin/host;1</command> service to mark the plugin tags +as disabled. This block can be undone through both the Torbutton Security UI, +and the Firefox Plugin Preferences. + </para> + <para> +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 +<command>plugins.click_to_play</command>. + </para> + <para> +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 <ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... the load of any plugins except +for Flash and Gnash</ulink>. + + </para> + </listitem> + <listitem>External App Blocking and Drag Event Filtering + <para> + +External apps can be induced to load files that perform network activity. +Unfortunately, there are cases where such apps can be launched automatically +with little to no user input. In order to prevent this, Torbutton installs a +component to <ulink +url="https://gitweb.torproject.org/torbutton.git/blob_plain/HEAD:/src/components/... +provide the user with a popup</ulink> whenever the browser attempts to launch +a helper app. + + </para> + <para> + +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 <ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... +an observer event during dragging</ulink> to allow us to filter the drag +events from Torbutton before the OS downloads the URLs the events contained. + + </para> + </listitem> + <listitem>Disabling system extensions and clearing the addon whitelist + <para> + +Firefox addons can perform arbitrary activity on your computer, including +bypassing Tor. It is for this reason we disable the addon whitelist +(<command>xpinstall.whitelist.add</command>), so that users are prompted +before installing addons regardless of the source. We also exclude +system-level addons from the browser through the use of +<command>extensions.enabledScopes</command> and +<command>extensions.autoDisableScopes</command>. + + </para> + </listitem> + </orderedlist> + </sect2> + <sect2 id="state-separation"> + <title>State Separation</title> + <para> + +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 +<command>extensions.enabledScopes</command> and +<command>extensions.autoDisableScopes</command>. Furthermore, plugins are +disabled, which prevents Flash cookies from leaking from a pre-existing Flash +directory. + + </para> + </sect2> + <sect2 id="disk-avoidance"> + <title>Disk Avoidance</title> + <sect3> + <title>Design Goal:</title> + <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> + </sect3> + <sect3> + <title>Implementation Status:</title> + <blockquote> + +We achieve this goal through several mechanisms. First, we set the Firefox +Private Browsing preference +<command>browser.privatebrowsing.autostart</command>. In addition, four Firefox patches are needed to prevent disk writes, even if +Private Browsing Mode is enabled. We need to + +<ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... +the permissions manager from recording HTTPS STS state</ulink>, +<ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... +intermediate SSL certificates from being recorded</ulink>, +<ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... +download history from being recorded</ulink>, and +<ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... +the content preferences service from recording site zoom</ulink>. + +For more details on these patches, <link linkend="firefox-patches">see the +Firefox Patches section</link>. + + </blockquote> + <blockquote> + +As an additional defense-in-depth measure, we set the following preferences: +<command></command>, +<command>browser.cache.disk.enable</command>, +<command>browser.cache.offline.enable</command>, +<command>dom.indexedDB.enabled</command>, +<command>network.cookie.lifetimePolicy</command>, +<command>signon.rememberSignons</command>, +<command>browser.formfill.enable</command>, +<command>browser.download.manager.retention</command>, +<command>browser.sessionstore.privacy_level</command>, +and <command>network.cookie.lifetimePolicy</command>. Many of these +preferences are likely redundant with +<command>browser.privatebrowsing.autostart</command>, but we have not done the +auditing work to ensure that yet. + + </blockquote> + <blockquote> + +Torbutton also <ulink +url="https://gitweb.torproject.org/torbutton.git/blob/HEAD:/src/components/tbSess... +code</ulink> to prevent the Firefox session store from writing to disk. + </blockquote> + <blockquote> + +For more details on disk leak bugs and enhancements, see the <ulink +url="https://trac.torproject.org/projects/tor/query?keywords=~tbb-disk-leak&s... tag in our bugtracker</ulink> + </blockquote> + </sect3> + </sect2> + <sect2 id="app-data-isolation"> + <title>Application Data Isolation</title> + <para> + +Tor Browser Bundle MUST NOT cause any information to be written outside of the +bundle directory. This is to ensure that the user is able to completely and +safely remove the bundle without leaving other traces of Tor usage on their +computer. + + </para> + <para> + +To ensure TBB directory isolation, we set +<command>browser.download.useDownloadDir</command>, +<command>browser.shell.checkDefaultBrowser</command>, and +<command>browser.download.manager.addToRecentDocs</command>. We also set the +$HOME environment variable to be the TBB extraction directory. + </para> + + </sect2> +<!-- FIXME: Write me... + <sect2 id="update-safety"> + <title>Update Safety</title> + <para>FIXME: Write me.. + </para> + </sect2> +--> + <sect2 id="identifier-linkability"> + <title>Cross-Origin Identifier Unlinkability</title> + <!-- FIXME: Mention web-send?? --> + <para> + +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 +existing web technology, that technology or functionality is disabled. Our +<link linkend="privacy">design goal</link> is to ultimately eliminate the need to disable arbitrary +technologies, and instead simply alter them in ways that allows them to +function in a backwards-compatible way while avoiding linkability. Users +should be able to use federated login of various kinds to explicitly inform +sites who they are, but that information should not transparently allow a +third party to record their activity from site to site without their prior +consent. + + </para> + <para> + +The benefit of this approach comes not only in the form of reduced +linkability, but also in terms of simplified privacy UI. If all stored browser +state and permissions become associated with the url bar origin, the six or +seven different pieces of privacy UI governing these identifiers and +permissions can become just one piece of UI. For instance, a window that lists +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. + + </para> + <figure><title>Improving the Privacy UI</title> + <mediaobject> + <imageobject> + <imagedata align="center" fileref="NewCookieManager.png"/> + </imageobject> + </mediaobject> + <caption> <para/> + +This example UI is a mock-up of how isolating identifiers to the URL bar +origin can simplify the privacy UI for all data - not just cookies. Once +browser identifiers and site permissions operate on a url bar basis, the same +privacy window can represent browsing history, DOM Storage, HTTP Auth, search +form history, login values, and so on within a context menu for each site. + +</caption> + </figure> + <orderedlist> + <listitem>Cookies + <para><command>Design Goal:</command> + +All cookies MUST be double-keyed to the url bar origin and third-party +origin. There exists a <ulink +url="https://bugzilla.mozilla.org/show_bug.cgi?id=565965%22%3EMozilla bug</ulink> +that contains a prototype patch, but it lacks UI, and does not apply to modern +Firefoxes. + + </para> + <para><command>Implementation Status:</command> + +As a stopgap to satisfy our design requirement of unlinkability, we currently +entirely disable 3rd party cookies by setting +<command>network.cookie.cookieBehavior</command> to 1. We would prefer that +third party content continue to function, but we believe the requirement for +unlinkability trumps that desire. + + </para> + </listitem> + <listitem>Cache + <para> + +Cache is isolated to the url bar origin by using a technique pioneered by +Colin Jackson et al, via their work on <ulink +url="http://www.safecache.com/%22%3ESafeCache</ulink>. The technique re-uses the +<ulink +url="https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsICachingChannel...</ulink> +attribute that Firefox uses internally to prevent improper caching and reuse +of HTTP POST data. + + </para> + <para> + +However, to <ulink +url="https://trac.torproject.org/projects/tor/ticket/3666%22%3Eincrease the +security of the isolation</ulink> and to <ulink +url="https://trac.torproject.org/projects/tor/ticket/3754%22%3Esolve conflicts +with OCSP relying the cacheKey property for reuse of POST requests</ulink>, we +had to <ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... +Firefox to provide a cacheDomain cache attribute</ulink>. We use the fully +qualified url bar domain as input to this field, to avoid the complexities +of heuristically determining the second-level DNS name. + + </para> + <para> + +<!-- FIXME: This could use a few more specifics.. Maybe. The Chrome folks +won't care, but the Mozilla folks might. --> Furthermore, we chose a different +isolation scheme than the Stanford implementation. First, we decoupled the +cache isolation from the third party cookie attribute. Second, we use several +mechanisms to attempt to determine the actual location attribute of the +top-level window (to obtain the url bar FQDN) used to load the page, as +opposed to relying solely on the Referer property. + + </para> + <para> + +Therefore, <ulink +url="http://crypto.stanford.edu/sameorigin/safecachetest.html%22%3Ethe original +Stanford test cases</ulink> are expected to fail. Functionality can still be +verified by navigating to <ulink url="about:cache">about:cache</ulink> and +viewing the key used for each cache entry. Each third party element should +have an additional "domain=string" property prepended, which will list the +FQDN that was used to source the third party element. + + </para> + <para> + +Additionally, because the image cache is a separate entity from the content +cache, we had to patch Firefox to also <ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... +this cache per url bar domain</ulink>. + + </para> + </listitem> + <listitem>HTTP Auth + <para> + +HTTP authentication tokens are removed for third party elements using the +<ulink +url="https://developer.mozilla.org/en/Setting_HTTP_request_headers#Observers%22%3... +observer</ulink> to remove the Authorization headers to prevent <ulink +url="http://jeremiahgrossman.blogspot.com/2007/04/tracking-users-without-cookies.... +linkability between domains</ulink>. + </para> + </listitem> + <listitem>DOM Storage + <para> + +DOM storage for third party domains MUST be isolated to the url bar origin, +to prevent linkability between sites. This functionality is provided through a +<ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... +to Firefox</ulink>. + + </para> + </listitem> + <listitem>Flash cookies + <para><command>Design Goal:</command> + +Users should be able to click-to-play flash objects from trusted sites. To +make this behavior unlinkable, we wish to include a settings file for all platforms that disables flash +cookies using the <ulink +url="http://www.macromedia.com/support/documentation/en/flashplayer/help/settings... +settings manager</ulink>. + + </para> + <para><command>Implementation Status:</command> + +We are currently <ulink +url="https://trac.torproject.org/projects/tor/ticket/3974%22%3Ehaving +difficulties</ulink> causing Flash player to use this settings +file on Windows, so Flash remains difficult to enable. + + </para> + </listitem> + <listitem>SSL+TLS session resumption, HTTP Keep-Alive and SPDY + <para><command>Design Goal:</command> + +TLS session resumption tickets and SSL Session IDs MUST be limited to the url +bar origin. HTTP Keep-Alive connections from a third party in one url bar +origin MUST NOT be reused for that same third party in another url bar origin. + + </para> + <para><command>Implementation Status:</command> + +We currently clear SSL Session IDs upon <link linkend="new-identity">New +Identity</link>, we disable TLS Session Tickets via the Firefox Pref +<command>security.enable_tls_session_tickets</command>. We disable SSL Session +IDs via a <ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... +to Firefox</ulink>. To compensate for the increased round trip latency from disabling +these performance optimizations, we also enable +<ulink url="https://tools.ietf.org/html/draft-bmoeller-tls-falsestart-00">TLS +False Start</ulink> via the Firefox Pref +<command>security.ssl.enable_false_start</command>. + </para> + <para> + +Because of the extreme performance benefits of HTTP Keep-Alive for interactive +web apps, and because of the difficulties of conveying urlbar origin +information down into the Firefox HTTP layer, as a compromise we currently +merely reduce the HTTP Keep-Alive timeout to 20 seconds (which is measured +from the last packet read on the connection) using the Firefox preference +<command>network.http.keep-alive.timeout</command>. + + </para> + <para> +However, because SPDY can store identifiers and has extremely long keepalive +duration, it is disabled through the Firefox preference +<command>network.http.spdy.enabled</command>. + </para> + </listitem> + <listitem>Automated cross-origin redirects MUST NOT store identifiers + <para><command>Design Goal:</command> + +To prevent attacks aimed at subverting the Cross-Origin Identifier +Unlinkability <link linkend="privacy">privacy requirement</link>, the browser +MUST NOT store any identifiers (cookies, cache, DOM storage, HTTP auth, etc) +for cross-origin redirect intermediaries that do not prompt for user input. +For example, if a user clicks on a bit.ly url that redirects to a +doubleclick.net url that finally redirects to a cnn.com url, only cookies from +cnn.com should be retained after the redirect chain completes. + + </para> + <para> + +Non-automated redirect chains that require user input at some step (such as +federated login systems) SHOULD still allow identifiers to persist. + + </para> + <para><command>Implementation status:</command> + +There are numerous ways for the user to be redirected, and the Firefox API +support to detect each of them is poor. We have a <ulink +url="https://trac.torproject.org/projects/tor/ticket/3600%22%3Etrac bug +open</ulink> to implement what we can. + + </para> + </listitem> + <listitem>window.name + <para> + +<ulink +url="https://developer.mozilla.org/En/DOM/Window.name%22%3Ewindow.name</ulink> is +a magical DOM property that for some reason is allowed to retain a persistent value +for the lifespan of a browser tab. It is possible to utilize this property for +<ulink url="http://www.thomasfrank.se/sessionvars.html">identifier +storage</ulink>. + + </para> + <para> + +In order to eliminate non-consensual linkability but still allow for sites +that utilize this property to function, we reset the window.name property of +tabs in Torbutton every time we encounter a blank Referer. This behavior +allows window.name to persist for the duration of a click-driven navigation +session, but as soon as the user enters a new URL or navigates between +https/http schemes, the property is cleared. + + </para> + </listitem> + <listitem>Auto form-fill + <para> + +We disable the password saving functionality in the browser as part of our +<link linkend="disk-avoidance">Disk Avoidance</link> requirement. However, +since users may decide to re-enable disk history records and password saving, +we also set the <ulink +url="http://kb.mozillazine.org/Signon.autofillForms%22%3Esignon.autofillForms</ulink> +preference to false to prevent saved values from immediately populating +fields upon page load. Since Javascript can read these values as soon as they +appear, setting this preference prevents automatic linkability from stored passwords. + + </para> + </listitem> + <listitem>HSTS supercookies + <para> + +An extreme (but not impossible) attack to mount is the creation of <ulink +url="http://www.leviathansecurity.com/blog/archives/12-The-Double-Edged-Sword-of-... +supercookies</ulink>. Since HSTS effectively stores one bit of information per domain +name, an adversary in possession of numerous domains can use them to construct +cookies based on stored HSTS state. + + </para> + <para><command>Design Goal:</command> + +There appears to be three options for us: 1. Disable HSTS entirely, and rely +instead on HTTPS-Everywhere to crawl and ship rules for HSTS sites. 2. +Restrict the number of HSTS-enabled third parties allowed per url bar origin. +3. Prevent third parties from storing HSTS rules. We have not yet decided upon +the best approach. + + </para> + <para><command>Implementation Status:</command> Currently, HSTS state is +cleared by <link linkend="new-identity">New Identity</link>, but we don't +defend against the creation of these cookies between <command>New +Identity</command> invocations. + </para> + </listitem> + <listitem>Exit node usage + <para><command>Design Goal:</command> + +Every distinct navigation session (as defined by a non-blank Referer header) +MUST exit through a fresh Tor circuit in Tor Browser to prevent exit node +observers from linking concurrent browsing activity. + + </para> + <para><command>Implementation Status:</command> + +The Tor feature that supports this ability only exists in the 0.2.3.x-alpha +series. <ulink +url="https://trac.torproject.org/projects/tor/ticket/3455%22%3ETicket +#3455</ulink> is the Torbutton ticket to make use of the new Tor +functionality. + + </para> + </listitem> + </orderedlist> + <para> +For more details on identifier linkability bugs and enhancements, see the <ulink +url="https://trac.torproject.org/projects/tor/query?keywords=~tbb-linkability&... tag in our bugtracker</ulink> + </para> + </sect2> + <sect2 id="fingerprinting-linkability"> + <title>Cross-Origin Fingerprinting Unlinkability</title> + <para> + +In order to properly address the fingerprinting adversary on a technical +level, we need a metric to measure linkability of the various browser +properties beyond any stored origin-related state. <ulink +url="https://panopticlick.eff.org/about.php%22%3EThe Panopticlick Project</ulink> +by the EFF provides us with a prototype of such a metric. The researchers +conducted a survey of volunteers who were asked to visit an experiment page +that harvested many of the above components. They then computed the Shannon +Entropy of the resulting distribution of each of several key attributes to +determine how many bits of identifying information each attribute provided. + + </para> + <para> + +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 <emphasis>among</emphasis> Tor Browser users. We +do not believe it is possible to solve cross-browser fingerprinting issues. + + </para> + <para> + +Unfortunately, the unsolvable nature of the cross-browser fingerprinting +problem means that the Panopticlick test website itself is not useful for +evaluating the actual effectiveness of our defenses, or the fingerprinting +defenses of any other web browser. Because the Panopticlick dataset is based +on browser data spanning a number of widely deployed browsers over a number of +years, any fingerprinting defenses attempted by browsers today are very likely +to cause Panopticlick to report an <emphasis>increase</emphasis> in +fingerprintability and entropy, because those defenses will stand out in sharp +contrast to historical data. We have been <ulink +url="https://trac.torproject.org/projects/tor/ticket/6119%22%3Eworking to convince +the EFF</ulink> that it is worthwhile to release the source code to +Panopticlick to allow us to run our own version for this reason. + + </para> + <sect3 id="fingerprinting-defenses"> + <title>Fingerprinting defenses in the Tor Browser</title> + + <orderedlist> + <listitem>Plugins + <para> + +Plugins add to fingerprinting risk via two main vectors: their mere presence in +window.navigator.plugins, as well as their internal functionality. + + </para> + <para><command>Design Goal:</command> + +All plugins that have not been specifically audited or sandboxed MUST be +disabled. To reduce linkability potential, even sandboxed plugins should not +be allowed to load objects until the user has clicked through a click-to-play +barrier. Additionally, version information should be reduced or obfuscated +until the plugin object is loaded. For flash, we wish to <ulink +url="https://trac.torproject.org/projects/tor/ticket/3974%22%3Eprovide a +settings.sol file</ulink> to disable Flash cookies, and to restrict P2P +features that are likely to bypass proxy settings. + + </para> + <para><command>Implementation Status:</command> + +Currently, we entirely disable all plugins in Tor Browser. However, as a +compromise due to the popularity of Flash, we allow users to re-enable Flash, +and flash objects are blocked behind a click-to-play barrier that is available +only after the user has specifically enabled plugins. Flash is the only plugin +available, the rest are <ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... +blocked from loading by a Firefox patch</ulink>. We also set the Firefox +preference <command>plugin.expose_full_path</command> to false, to avoid +leaking plugin installation information. + + </para> + </listitem> + <listitem>HTML5 Canvas Image Extraction + <para> + +The <ulink url="https://developer.mozilla.org/en-US/docs/HTML/Canvas">HTML5 +Canvas</ulink> is a feature that has been added to major browsers after the +EFF developed their Panopticlick study. After plugins and plugin-provided +information, we believe that the HTML5 Canvas is the single largest +fingerprinting threat browsers face today. <ulink +url="http://www.w2spconf.com/2012/papers/w2sp12-final4.pdf%22%3EInitial +studies</ulink> show that the Canvas can provide an easy-access fingerprinting +target: The adversary simply renders WebGL, font, and named color data to a +Canvas element, extracts the image buffer, and computes a hash of that image +data. Subtle differences in the video card, font packs, and even font and +graphics library versions allow the adversary to produce a stable, simple, +high-entropy fingerprint of a computer. In fact, the hash of the rendered +image can be used almost identically to a tracking cookie by the web server. + + </para> + <para> + +To reduce the threat from this vector, we have patched Firefox to <ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... +before returning valid image data</ulink> 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. + + </para> + </listitem> + <listitem>WebGL + <para> + +WebGL is fingerprintable both through information that is exposed about the +underlying driver and optimizations, as well as through performance +fingerprinting. + + </para> + <para> + +Because of the large amount of potential fingerprinting vectors and the <ulink +url="http://www.contextis.com/resources/blog/webgl/%22%3Epreviously unexposed +vulnerability surface</ulink>, we deploy a similar strategy against WebGL as +for plugins. First, WebGL Canvases have click-to-play placeholders (provided +by NoScript), and do not run until authorized by the user. Second, we +obfuscate driver information by setting the Firefox preferences +<command>webgl.disable-extensions</command> and +<command>webgl.min_capability_mode</command>, which reduce the information +provided by the following WebGL API calls: <command>getParameter()</command>, +<command>getSupportedExtensions()</command>, and +<command>getExtension()</command>. + + </para> + </listitem> + <listitem>Fonts + <para> + +According to the Panopticlick study, fonts provide the most linkability when +they are provided as an enumerable list in filesystem order, via either the +Flash or Java plugins. However, it is still possible to use CSS and/or +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. + + </para> + <para> + +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 <ulink +url="https://secure.wikimedia.org/wikipedia/en/wiki/Unicode_typeface#List_of_Unic... +subset</ulink> 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. + + </para> + <para><command>Implementation Status:</command> + +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 <ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... +a Firefox patch</ulink>. We create two prefs, +<command>browser.display.max_font_attempts</command> and +<command>browser.display.max_font_count</command> for this purpose. Once these +limits are reached, the browser behaves as if +<command>browser.display.use_document_fonts</command> was set. We are +still working to determine optimal values for these prefs. + + </para> + <para> + +To improve rendering, we exempt remote <ulink +url="https://developer.mozilla.org/en-US/docs/CSS/@font-face%22%3E@font-face +fonts</ulink> 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. + + </para> + </listitem> + <listitem>Desktop resolution, CSS Media Queries, and System Colors + <para> + +Both CSS and Javascript have access to a lot of information about the screen +resolution, usable desktop size, OS widget size, toolbar size, title bar size, +system theme colors, and other desktop features that are not at all relevant +to rendering and serve only to provide information for fingerprinting. + + </para> + <para><command>Design Goal:</command> + +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 +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. + + </para> + <para><command>Implementation Status:</command> + +We have implemented the above strategy using a window observer to <ulink +url="https://gitweb.torproject.org/torbutton.git/blob/HEAD:/src/chrome/content/to... +new windows based on desktop resolution</ulink>. Additionally, we patch +Firefox to use the client content window size <ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... +window.screen</ulink> and <ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... +CSS Media Queries</ulink>. Similarly, we <ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... +DOM events to return content window relative points</ulink>. We also patch +Firefox to <ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... +a fixed set of system colors to content window CSS</ulink>. + + </para> + <para> + +To further reduce resolution-based fingerprinting, we are <ulink +url="https://trac.torproject.org/projects/tor/ticket/7256%22%3Einvestigating +zoom/viewport-based mechanisms</ulink> 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. + + </para> + </listitem> + <listitem>User Agent and HTTP Headers + <para><command>Design Goal:</command> + +All Tor Browser users MUST provide websites with an identical user agent and +HTTP header set for a given request type. We omit the Firefox minor revision, +and report a popular Windows platform. If the software is kept up to date, +these headers should remain identical across the population even when updated. + + </para> + <para><command>Implementation Status:</command> + +Firefox provides several options for controlling the browser user agent string +which we leverage. We also set similar prefs for controlling the +Accept-Language and Accept-Charset headers, which we spoof to English by default. Additionally, we +<ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... +content script access</ulink> to Components.interfaces, which <ulink +url="http://pseudo-flaw.net/tor/torbutton/fingerprint-firefox.html%22%3Ecan be +used</ulink> to fingerprint OS, platform, and Firefox minor version. </para> + + </listitem> + <listitem>Timezone and clock offset + <para><command>Design Goal:</command> + +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 +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. + + </para> + <para><command>Implementation Status:</command> + +We set the timezone using the TZ environment variable, which is supported on +all platforms. Additionally, we plan to <ulink +url="https://trac.torproject.org/projects/tor/ticket/3652%22%3Eobtain a clock +offset from Tor</ulink>, but this won't be available until Tor 0.2.3.x is in +use. + + </para> + </listitem> + <listitem>Javascript performance fingerprinting + <para> + +<ulink url="http://w2spconf.com/2011/papers/jspriv.pdf">Javascript performance +fingerprinting</ulink> is the act of profiling the performance +of various Javascript functions for the purpose of fingerprinting the +Javascript engine and the CPU. + + </para> + <para><command>Design Goal:</command> + +We have <ulink +url="https://trac.torproject.org/projects/tor/ticket/3059%22%3Eseveral potential +mitigation approaches</ulink> to reduce the accuracy of performance +fingerprinting without risking too much damage to functionality. Our current +favorite is to reduce the resolution of the Event.timeStamp and the Javascript +Date() object, while also introducing jitter. Our goal is to increase the +amount of time it takes to mount a successful attack. <ulink +url="http://w2spconf.com/2011/papers/jspriv.pdf%22%3EMowery et al</ulink> found that +even with the default precision in most browsers, they required up to 120 +seconds of amortization and repeated trials to get stable results from their +feature set. We intend to work with the research community to establish the +optimum trade-off between quantization+jitter and amortization time. + + + </para> + <para><command>Implementation Status:</command> + +Currently, the only mitigation against performance fingerprinting is to +disable <ulink url="http://www.w3.org/TR/navigation-timing/">Navigation +Timing</ulink> through the Firefox preference +<command>dom.enable_performance</command>. + + </para> + </listitem> + <listitem>Non-Uniform HTML5 API Implementations + <para> + +At least two HTML5 features have different implementation status across the +major OS vendors: the <ulink +url="https://developer.mozilla.org/en-US/docs/DOM/window.navigator.battery%22%3EB... +API</ulink> and the <ulink +url="https://developer.mozilla.org/en-US/docs/DOM/window.navigator.connection%22%... +Connection API</ulink>. We disable these APIs +through the Firefox preferences <command>dom.battery.enabled</command> and +<command>dom.network.enabled</command>. + + </para> + </listitem> + <listitem>Keystroke fingerprinting + <para> + +Keystroke fingerprinting is the act of measuring key strike time and key +flight time. It is seeing increasing use as a biometric. + + </para> + <para><command>Design Goal:</command> + +We intend to rely on the same mechanisms for defeating Javascript performance +fingerprinting: timestamp quantization and jitter. + + </para> + <para><command>Implementation Status:</command> +We have no implementation as of yet. + </para> + </listitem> + </orderedlist> + </sect3> + <para> +For more details on identifier linkability bugs and enhancements, see the <ulink +url="https://trac.torproject.org/projects/tor/query?keywords=~tbb-fingerprinting&... tag in our bugtracker</ulink> + </para> + </sect2> + <sect2 id="new-identity"> + <title>Long-Term Unlinkability via "New Identity" button</title> + <para> + +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. + + </para> + + <sect3> + <title>Design Goal:</title> + <blockquote> + +All linkable identifiers and browser state MUST be cleared by this feature. + + </blockquote> + </sect3> + + <sect3> + <title>Implementation Status:</title> + <blockquote> + <para> + +First, Torbutton disables Javascript in all open tabs and windows by using +both the <ulink +url="https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIDocShe...</ulink> +attribute as well as <ulink +url="https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIDOMWin...)</ulink>. +We then stop all page activity for each tab using <ulink +url="https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIWebNav...)</ulink>. +We then clear the site-specific Zoom by temporarily disabling the preference +<command>browser.zoom.siteSpecific</command>, and clear the GeoIP wifi token URL +<command>geo.wifi.access_token</command> and the last opened URL prefs (if +they exist). Each tab is then closed. + + </para> + <para> + +After closing all tabs, we then emit "<ulink +url="https://developer.mozilla.org/en-US/docs/Supporting_private_browsing_mode#Pr...</ulink>" +(which instructs addons and various Firefox components to clear their session +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). + + </para> + <para> + +After the state is cleared, we then close all remaining HTTP keep-alive +connections and then send the NEWNYM signal to the Tor control port to cause a +new circuit to be created. + </para> + <para> +Finally, a fresh browser window is opened, and the current browser window is +closed (this does not spawn a new Firefox process, only a new window). + </para> + </blockquote> + <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> + </sect3> + </sect2> +<!-- + <sect2 id="click-to-play"> + <title>Click-to-play for plugins and invasive content</title> + <para> +Some content types are too invasive and/or too opaque for us to properly +eliminate their linkability properties. For these content types, we use +NoScript to provide click-to-play placeholders that do not activate the +content until the user clicks on it. This will eliminate the ability for an +adversary to use such content types to link users in a dragnet fashion across +arbitrary sites. + </para> + <para> +Currently, the content types isolated in this way include Flash, WebGL, and +audio and video objects. + </para> + </sect2> +--> + <sect2 id="other-security"> + <title>Other Security Measures</title> + <para> + +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 +privacy and security issues. + + </para> + <orderedlist> + <listitem id="traffic-fingerprinting-defenses"><command>Website Traffic Fingerprinting Defenses</command> + <para> + +<link linkend="website-traffic-fingerprinting">Website Traffic +Fingerprinting</link> is a statistical attack to attempt to recognize specific +encrypted website activity. + + </para> + <sect3> + <title>Design Goal:</title> + <blockquote> + <para> + +We want to deploy a mechanism that reduces the accuracy of <ulink +url="https://en.wikipedia.org/wiki/Feature_selection%22%3Euseful features</ulink> available +for classification. This mechanism would either impact the true and false +positive accuracy rates, <emphasis>or</emphasis> reduce the number of webpages +that could be classified at a given accuracy rate. + + </para> + <para> + +Ideally, this mechanism would be as light-weight as possible, and would be +tunable in terms of overhead. We suspect that it may even be possible to +deploy a mechanism that reduces feature extraction resolution without any +network overhead. In the no-overhead category, we have <ulink +url="http://freehaven.net/anonbib/cache/LZCLCP_NDSS11.pdf%22%3EHTTPOS</ulink> and +<ulink +url="https://blog.torproject.org/blog/experimental-defense-website-traffic-finger... +use of HTTP pipelining and/or SPDY</ulink>. +In the tunable/low-overhead +category, we have <ulink +url="http://freehaven.net/anonbib/cache/ShWa-Timing06.pdf%22%3EAdaptive +Padding</ulink> and <ulink url="http://www.cs.sunysb.edu/~xcai/fp.pdf"> +Congestion-Sensitive BUFLO</ulink>. It may be also possible to <ulink +url="https://trac.torproject.org/projects/tor/ticket/7028%22%3Etune such +defenses</ulink> such that they only use existing spare Guard bandwidth capacity in the Tor +network, making them also effectively no-overhead. + + </para> + </blockquote> + </sect3> + <sect3> + <title>Implementation Status:</title> + <blockquote> + <para> +Currently, we patch Firefox to <ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... +pipeline order and depth</ulink>. Unfortunately, pipelining is very fragile. +Many sites do not support it, and even sites that advertise support for +pipelining may simply return error codes for successive requests, effectively +forcing the browser into non-pipelined behavior. Firefox also has code to back +off and reduce or eliminate the pipeline if this happens. These +shortcomings and fallback behaviors are the primary reason that Google +developed SPDY as opposed simply extending HTTP to improve pipelining. It +turns out that we could actually deploy exit-side proxies that allow us to +<ulink +url="https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/ideas/xxx-usi... +SPDY from the client to the exit node</ulink>. This would make our defense not +only free, but one that actually <emphasis>improves</emphasis> performance. + + </para> + <para> + +Knowing this, we created this defense as an <ulink +url="https://blog.torproject.org/blog/experimental-defense-website-traffic-finger... +research prototype</ulink> to help evaluate what could be done in the best +case with full server support. Unfortunately, the bias in favor of compelling +attack papers has caused academia to ignore this request thus far, instead +publishing only cursory (yet "devastating") evaluations that fail to provide +even simple statistics such as the rates of actual pipeline utilization during +their evaluations, in addition to the other shortcomings and shortcuts <link +linkend="website-traffic-fingerprinting">mentioned earlier</link>. We can +accept that our defense might fail to work as well as others (in fact we +expect it), but unfortunately the very same shortcuts that provide excellent +attack results also allow the conclusion that all defenses are broken forever. +So sadly, we are still left in the dark on this point. + + </para> + </blockquote> + </sect3> + </listitem> + <listitem><command>Privacy-preserving update notification</command> + <para> + +In order to inform the user when their Tor Browser is out of date, we perform a +privacy-preserving update check asynchronously in the background. The +check uses Tor to download the file <ulink +url="https://check.torproject.org/RecommendedTBBVersions%22%3Ehttps://check.torpr...</ulink> +and searches that version list for the current value for the local preference +<command>torbrowser.version</command>. If the value from our preference is +present in the recommended version list, the check is considered to have +succeeded and the user is up to date. If not, it is considered to have failed +and an update is needed. The check is triggered upon browser launch, new +window, and new tab, but is rate limited so as to happen no more frequently +than once every 1.5 hours. + + </para> + <para> + +If the check fails, we cache this fact, and update the Torbutton graphic to +display a flashing warning icon and insert a menu option that provides a link +to our download page. Additionally, we reset the value for the browser +homepage to point to a <ulink +url="https://check.torproject.org/?lang=en-US&small=1&uptodate=0%22%3Epag... that +informs the user</ulink> that their browser is out of +date. + + </para> + </listitem> + + </orderedlist> + </sect2> + <sect2 id="firefox-patches"> + <title>Description of Firefox Patches</title> + <para> + +The set of patches we have against Firefox can be found in the <ulink +url="https://gitweb.torproject.org/torbrowser.git/tree/maint-2.4:/src/current-pat... directory of the torbrowser git repository</ulink>. They are: + + </para> + <orderedlist> + <listitem><ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... +Components.interfaces</ulink> + <para> + +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. + + </para> + </listitem> + <listitem><ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... +Permissions Manager memory only</ulink> + <para> + +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 <ulink +url="https://secure.wikimedia.org/wikipedia/en/wiki/HTTP_Strict_Transport_Securit...</ulink> +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. + + </para> + </listitem> + <listitem><ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... +Intermediate Cert Store memory-only</ulink> + <para> + +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. + + </para> + <!-- FIXME: Should this be a <note> tag too? --> + <para><command>Design Goal:</command> + +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. + + </para> + </listitem> + <listitem><ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... +a string-based cacheKey property for domain isolation</ulink> + <para> + +To <ulink +url="https://trac.torproject.org/projects/tor/ticket/3666%22%3Eincrease the +security of cache isolation</ulink> and to <ulink +url="https://trac.torproject.org/projects/tor/ticket/3754%22%3Esolve strange and +unknown conflicts with OCSP</ulink>, we had to patch +Firefox to provide a cacheDomain cache attribute. We use the url bar +FQDN as input to this field. + + </para> + </listitem> + <listitem><ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... +all plugins except flash</ulink> + <para> +We cannot use the <ulink +url="http://www.oxymoronical.com/experiments/xpcomref/applications/Firefox/3.5/co... +@mozilla.org/extensions/blocklist;1</ulink> 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. + </para> + </listitem> + <listitem><ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... content-prefs service memory only</ulink> + <para> +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?). + </para> + </listitem> + <listitem><ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... Tor Browser exit when not launched from Vidalia</ulink> + <para> + +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. + + </para> + </listitem> + <listitem><ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... SSL Session ID tracking</ulink> + <para> + +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. + + </para> + </listitem> + <listitem><ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... an observer event to close persistent connections</ulink> + <para> + +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 <link linkend="new-identity">New Identity</link> button. + + </para> + </listitem> + <listitem><ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... Device and System Specific Media Queries</ulink> + <para> + +<ulink url="https://developer.mozilla.org/en-US/docs/CSS/Media_queries">CSS +Media Queries</ulink> 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. + + </para> + </listitem> + <listitem><ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... the number of fonts per document</ulink> + <para> + +Font availability can be <ulink url="http://flippingtypical.com/">queried by +CSS and Javascript</ulink> 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. + + </para> + </listitem> + <listitem><ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... Firefox to Tor Browser</ulink> + <para> + +This patch updates our branding in compliance with Mozilla's trademark policy. + + </para> + </listitem> + <listitem><ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... Download Manager Memory Only</ulink> + <para> + +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. + + </para> + </listitem> + <listitem><ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... DDG and StartPage to Omnibox</ulink> + <para> + +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. + + </para> + </listitem> + <listitem><ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... nsICacheService.EvictEntries() Synchronous</ulink> + <para> + +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. + + </para> + </listitem> + <listitem><ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... WebSockets DNS Leak</ulink> + <para> + +This patch prevents a DNS leak when using WebSockets. It also prevents other +similar types of DNS leaks. + + </para> + </listitem> + <listitem><ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... HTTP pipeline order and depth</ulink> + <para> +As an +<ulink +url="https://blog.torproject.org/blog/experimental-defense-website-traffic-finger... +defense against Website Traffic Fingerprinting</ulink>, we patch the standard +HTTP pipelining code to randomize the number of requests in a +pipeline, as well as their order. + </para> + </listitem> + <listitem><ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... +an observer event to filter the Drag and Drop URL list</ulink> + <para> + +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. + + </para> + </listitem> + <listitem><ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... mozIThirdPartyUtil.getFirstPartyURI() API</ulink> + <para> + +This patch provides an API that allows us to more easily isolate identifiers +to the URL bar domain. + + </para> + </listitem> + <listitem><ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... canvas image extraction prompt</ulink> + <para> + +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. + + </para> + </listitem> + <listitem><ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... client window coordinates for mouse events</ulink> + <para> + +This patch causes mouse events to return coordinates relative to the content +window instead of the desktop. + + </para> + </listitem> + <listitem><ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... not expose physical screen info to window.screen</ulink> + <para> + +This patch causes window.screen to return the display resolution size of the +content window instead of the desktop resolution size. + + </para> + </listitem> + <listitem><ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... not expose system colors to CSS or canvas</ulink> + <para> + +This patch prevents CSS and Javascript from discovering your desktop color +scheme and/or theme. + + </para> + </listitem> + <listitem><ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... the Image Cache per url bar domain</ulink> + <para> + +This patch prevents cached images from being used to store third party tracking +identifiers. + + </para> + </listitem> + <listitem><ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat...) API</ulink> + <para> + +This patch provides HTTPS-Everywhere with an API to perform redirections more +securely and without addon conflicts. + + </para> + </listitem> + <listitem><ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... DOM Storage to first party URI</ulink> + <para> + +This patch prevents DOM Storage from being used to store third party tracking +identifiers. + + </para> + </listitem> + + <listitem><ulink +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... +"This plugin is disabled" barrier</ulink> + + <para> + +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. + + </para> + </listitem> + + </orderedlist> + </sect2> + +</sect1> + +<!-- +- Packaging + - Build Process Security + - External Addons + - Included + - HTTPS-E + - NoScript + - Torbutton + - Deliberately excluded + - Request Policy, AdblockPlus, etc + - Desired + - Perspectives/Convergence/etc + - Pref Changes + - Caused by Torbutton + - Set manually in profile + - Update security + - Thandy + +<sect1 id="Packaging"> + <title>Packaging</title> + <para> </para> + <sect2 id="build-security"> + <title>Build Process Security</title> + <para> </para> + </sect2> + <sect2 id="addons"> + <title>External Addons</title> + <para> </para> + <sect3> + <title>Included Addons</title> + </sect3> + <sect3> + <title>Excluded Addons</title> + </sect3> + <sect3> + <title>Dangerous Addons</title> + </sect3> + </sect2> + <sect2 id="prefs"> + <title>Pref Changes</title> + <para> </para> + </sect2> + <sect2 id="update-mechanism"> + <title>Update Security</title> + <para> </para> + </sect2> +</sect1> +--> + +<!-- +<sect1 id="Testing"> + <title>Testing</title> + <para> + +The purpose of this section is to cover all the known ways that Tor browser +security can be subverted from a penetration testing perspective. The hope +is that it will be useful both for creating a &quot;Tor Safety Check&quot; +page, and for developing novel tests and actively attacking Torbutton with the +goal of finding vulnerabilities in either it or the Mozilla components, +interfaces and settings upon which it relies. + + </para> + <sect2 id="SingleStateTesting"> + <title>Single state testing</title> + <para> + +Torbutton is a complicated piece of software. During development, changes to +one component can affect a whole slough of unrelated features. A number of +aggregated test suites exist that can be used to test for regressions in +Torbutton and to help aid in the development of Torbutton-like addons and +other privacy modifications of other browsers. Some of these test suites exist +as a single automated page, while others are a series of pages you must visit +individually. They are provided here for reference and future regression +testing, and also in the hope that some brave soul will one day decide to +combine them into a comprehensive automated test suite. + + <orderedlist> + <listitem><ulink url="http://decloak.net/">Decloak.net</ulink> + <para> + +Decloak.net is the canonical source of plugin and external-application based +proxy-bypass exploits. It is a fully automated test suite maintained by <ulink +url="http://digitaloffense.net/">HD Moore</ulink> as a service for people to +use to test their anonymity systems. + + </para> + </listitem> + <listitem><ulink url="http://deanonymizer.com/">Deanonymizer.com</ulink> + <para> + +Deanonymizer.com is another automated test suite that tests for proxy bypass +and other information disclosure vulnerabilities. It is maintained by Kyle +Williams, the author of <ulink url="http://www.janusvm.com/">JanusVM</ulink> +and <ulink url="http://www.januspa.com/">JanusPA</ulink>. + + </para> + </listitem> + <listitem><ulink url="https://ip-check.info">JonDos +AnonTest</ulink> + <para> + +The <ulink url="https://anonymous-proxy-servers.net/">JonDos people</ulink> also provide an +anonymity tester. It is more focused on HTTP headers and behaviors than plugin bypass, and +points out a couple of headers Torbutton could do a better job with +obfuscating. + + </para> + </listitem> + <listitem><ulink url="http://browserspy.dk">Browserspy.dk</ulink> + <para> + +Browserspy.dk provides a tremendous collection of browser fingerprinting and +general privacy tests. Unfortunately they are only available one page at a +time, and there is not really solid feedback on good vs bad behavior in +the test results. + + </para> + </listitem> + <listitem><ulink url="http://analyze.privacy.net/">Privacy +Analyzer</ulink> + <para> + +The Privacy Analyzer provides a dump of all sorts of browser attributes and +settings that it detects, including some information on your original IP +address. Its page layout and lack of good vs bad test result feedback makes it +not as useful as a user-facing testing tool, but it does provide some +interesting checks in a single page. + + </para> + </listitem> + <listitem><ulink url="http://ha.ckers.org/mr-t/">Mr. T</ulink> + <para> + +Mr. T is a collection of browser fingerprinting and deanonymization exploits +discovered by the <ulink url="http://ha.ckers.org">ha.ckers.org</ulink> crew +and others. It is also not as user friendly as some of the above tests, but it +is a useful collection. + + </para> + </listitem> + <listitem>Gregory Fleischer's <ulink +url="http://pseudo-flaw.net/content/tor/torbutton/">Torbutton</ulink> and +<ulink +url="http://pseudo-flaw.net/content/defcon/dc-17-demos/d.html">Defcon +17</ulink> Test Cases + <para> + +Gregory Fleischer has been hacking and testing Firefox and Torbutton privacy +issues for the past 2 years. He has an excellent collection of all his test +cases that can be used for regression testing. In his Defcon work, he +demonstrates ways to infer Firefox version based on arcane browser properties. +We are still trying to determine the best way to address some of those test +cases. + + </para> + </listitem> + <listitem><ulink url="https://torcheck.xenobite.eu/index.php">Xenobite's +TorCheck Page</ulink> + <para> + +This page checks to ensure you are using a valid Tor exit node and checks for +some basic browser properties related to privacy. It is not very fine-grained +or complete, but it is automated and could be turned into something useful +with a bit of work. + + </para> + </listitem> + </orderedlist> + </para> + </sect2> +--> +<!-- + <sect2> + <title>Multi-state testing</title> + <para> + +The tests in this section are geared towards a page that would instruct the +user to toggle their Tor state after the fetch and perform some operations: +mouseovers, stray clicks, and potentially reloads. + + </para> + <sect3> + <title>Cookies and Cache Correlation</title> + <para> +The most obvious test is to set a cookie, ask the user to toggle tor, and then +have them reload the page. The cookie should no longer be set if they are +using the default Torbutton settings. In addition, it is possible to leverage +the cache to <ulink +url="http://crypto.stanford.edu/sameorigin/safecachetest.html">store unique +identifiers</ulink>. The default settings of Torbutton should also protect +against these from persisting across Tor Toggle. + + </para> + </sect3> + <sect3> + <title>Javascript timers and event handlers</title> + <para> + +Javascript can set timers and register event handlers in the hopes of fetching +URLs after the user has toggled Torbutton. + </para> + </sect3> + <sect3> + <title>CSS Popups and non-script Dynamic Content</title> + <para> + +Even if Javascript is disabled, CSS is still able to +<ulink url="http://www.tjkdesign.com/articles/css%20pop%20ups/">create popup-like +windows</ulink> +via the 'onmouseover' CSS attribute, which can cause arbitrary browser +activity as soon as the mouse enters into the content window. It is also +possible for meta-refresh tags to set timers long enough to make it likely +that the user has toggled Tor before fetching content. + + </para> + </sect3> + </sect2> + <sect2 id="HackTorbutton"> + <title>Active testing (aka How to Hack Torbutton)</title> + <para> + +The idea behind active testing is to discover vulnerabilities in Torbutton to +bypass proxy settings, run script in an opposite Tor state, store unique +identifiers, leak location information, or otherwise violate <link +linkend="requirements">its requirements</link>. Torbutton has ventured out +into a strange and new security landscape. It depends on Firefox mechanisms +that haven't necessarily been audited for security, certainly not for the +threat model that Torbutton seeks to address. As such, it and the interfaces +it depends upon still need a 'trial by fire' typical of new technologies. This +section of the document was written with the intention of making that period +as fast as possible. Please help us get through this period by considering +these attacks, playing with them, and reporting what you find (and potentially +submitting the test cases back to be run in the standard batch of Torbutton +tests. + + </para> + <sect3> + <title>Some suggested vectors to investigate</title> + <para> + <itemizedlist> + <listitem>Strange ways to register Javascript <ulink +url="http://en.wikipedia.org/wiki/DOM_Events">events</ulink> and <ulink +url="http://www.devshed.com/c/a/JavaScript/Using-Timers-in-JavaScript/">timeouts</ulink> should +be verified to actually be ineffective after Tor has been toggled.</listitem> + <listitem>Other ways to cause Javascript to be executed after +<command>javascript.enabled</command> has been toggled off.</listitem> + <listitem>Odd ways to attempt to load plugins. Kyle Williams has had +some success with direct loads/meta-refreshes of plugin-handled URLs.</listitem> + <listitem>The Date and Timezone hooks should be verified to work with +crazy combinations of iframes, nested iframes, iframes in frames, frames in +iframes, and popups being loaded and +reloaded in rapid succession, and/or from one another. Think race conditions and deep, +parallel nesting, involving iframes from both <ulink +url="http://en.wikipedia.org/wiki/Same_origin_policy">same-origin and +non-same-origin</ulink> domains.</listitem> + <listitem>In addition, there may be alternate ways and other +methods to query the timezone, or otherwise use some of the Date object's +methods in combination to deduce the timezone offset. Of course, the author +tried his best to cover all the methods he could foresee, but it's always good +to have another set of eyes try it out.</listitem> + <listitem>Similarly, is there any way to confuse the <link +linkend="contentpolicy">content policy</link> +mentioned above to cause it to allow certain types of page fetches? For +example, it was recently discovered that favicons are not fetched by the +content, but the chrome itself, hence the content policy did not look up the +correct window to determine the current Tor tag for the favicon fetch. Are +there other things that can do this? Popups? Bookmarklets? Active bookmarks? </listitem> + <listitem>Alternate ways to store and fetch unique identifiers. For example, <ulink +url="http://developer.mozilla.org/en/docs/DOM:Storage">DOM Storage</ulink> +caught us off guard. +It was +also discovered by <ulink url="http://pseudo-flaw.net">Gregory +Fleischer</ulink> that <ulink +url="http://pseudo-flaw.net/content/tor/torbutton/">content window access to +chrome</ulink> can be used to build <link linkend="fingerprinting">unique +identifiers</link>. +Are there any other +arcane or experimental ways that Firefox provides to create and store unique +identifiers? Or perhaps unique identifiers can be queried or derived from +properties of the machine/browser that Javascript has access to? How unique +can these identifiers be? + </listitem> + <listitem>Is it possible to get the browser to write some history to disk +(aside from swap) that can be retrieved later? By default, Torbutton should +write no history, cookie, or other browsing activity information to the +harddisk.</listitem> + <listitem>Do popup windows make it easier to break any of the above +behavior? Are javascript events still canceled in popups? What about recursive +popups from Javascript, data, and other funky URL types? What about CSS +popups? Are they still blocked after Tor is toggled?</listitem> + <listitem>Chrome-escalation attacks. The interaction between the +Torbutton chrome Javascript and the client content window javascript is pretty +well-defined and carefully constructed, but perhaps there is a way to smuggle +javascript back in a return value, or otherwise inject network-loaded +javascript into the chrome (and thus gain complete control of the browser). +</listitem> +</itemizedlist> + + </para> + </sect3> + </sect2> +</sect1> +--> +<appendix id="Transparency"> +<title>Towards Transparency in Navigation Tracking</title> +<para> + +The <link linkend="privacy">privacy properties</link> of Tor Browser are based +upon the assumption that link-click navigation indicates user consent to +tracking between the linking site and the destination site. While this +definition is sufficient to allow us to eliminate cross-site third party +tracking with only minimal site breakage, it is our long-term goal to further +reduce cross-origin click navigation tracking to mechanisms that are +detectable by attentive users, so they can alert the general public if +cross-origin click navigation tracking is happening where it should not be. + +</para> +<para> + +In an ideal world, the mechanisms of tracking that can be employed during a +link click would be limited to the contents of URL parameters and other +properties that are fully visible to the user before they click. However, the +entrenched nature of certain archaic web features make it impossible for us to +achieve this transparency goal by ourselves without substantial site breakage. +So, instead we maintain a <link linkend="deprecate">Deprecation +Wishlist</link> of archaic web technologies that are currently being (ab)used +to facilitate federated login and other legitimate click-driven cross-domain +activity but that can one day be replaced with more privacy friendly, +auditable alternatives. + +</para> +<para> + +Because the total elimination of side channels during cross-origin navigation +will undoubtedly break federated login as well as destroy ad revenue, we +also describe auditable alternatives and promising web draft standards that would +preserve this functionality while still providing transparency when tracking is +occurring. + +</para> + +<sect1 id="deprecate"> + <title>Deprecation Wishlist</title> + <orderedlist> + <listitem>The Referer Header + <para> + +We haven't disabled or restricted the Referer ourselves because of the +non-trivial number of sites that rely on the Referer header to "authenticate" +image requests and deep-link navigation on their sites. Furthermore, there +seems to be no real privacy benefit to taking this action by itself in a +vacuum, because many sites have begun encoding Referer URL information into +GET parameters when they need it to cross http to https scheme transitions. +Google's +1 buttons are the best example of this activity. + + </para> + <para> + +Because of the availability of these other explicit vectors, we believe the +main risk of the Referer header is through inadvertent and/or covert data +leakage. In fact, <ulink +url="http://www2.research.att.com/~bala/papers/wosn09.pdf%22%3Ea great deal of +personal data</ulink> is inadvertently leaked to third parties through the +source URL parameters. + + </para> + <para> + +We believe the Referer header should be made explicit. If a site wishes to +transmit its URL to third party content elements during load or during +link-click, it should have to specify this as a property of the associated HTML +tag. With an explicit property, it would then be possible for the user agent to +inform the user if they are about to click on a link that will transmit Referer +information (perhaps through something as subtle as a different color in the +lower toolbar for the destination URL). This same UI notification can also be +used for links with the <ulink +url="https://developer.mozilla.org/en-US/docs/HTML/Element/a#Attributes%22%3E%22p..."</ulink> +attribute. + + </para> + </listitem> + <listitem>window.name + <para> +<ulink +url="https://developer.mozilla.org/En/DOM/Window.name%22%3Ewindow.name</ulink> is +a DOM property that for some reason is allowed to retain a persistent value +for the lifespan of a browser tab. It is possible to utilize this property for +<ulink url="http://www.thomasfrank.se/sessionvars.html">identifier +storage</ulink> during click navigation. This is sometimes used for additional +XSRF protection and federated login. + </para> + <para> + +It's our opinion that the contents of window.name should not be preserved for +cross-origin navigation, but doing so may break federated login for some sites. + + </para> + </listitem> + <listitem>Javascript link rewriting + <para> + +In general, it should not be possible for onclick handlers to alter the +navigation destination of 'a' tags, silently transform them into POST +requests, or otherwise create situations where a user believes they are +clicking on a link leading to one URL that ends up on another. This +functionality is deceptive and is frequently a vector for malware and phishing +attacks. Unfortunately, many legitimate sites also employ such transparent +link rewriting, and blanket disabling this functionality ourselves will simply +cause Tor Browser to fail to navigate properly on these sites. + + </para> + <para> + +Automated cross-origin redirects are one form of this behavior that is +possible for us to <ulink +url="https://trac.torproject.org/projects/tor/ticket/3600%22%3Eaddress +ourselves</ulink>, as they are comparatively rare and can be handled with site +permissions. + + </para> + </listitem> + </orderedlist> +</sect1> +<sect1> + <title>Promising Standards</title> + <orderedlist> + <listitem><ulink url="http://web-send.org">Web-Send Introducer</ulink> + <para> + +Web-Send is a browser-based link sharing and federated login widget that is +designed to operate without relying on third-party tracking or abusing other +cross-origin link-click side channels. It has a compelling list of <ulink +url="http://web-send.org/features.html%22%3Eprivacy and security features</ulink>, +especially if used as a "Like button" replacement. + + </para> + </listitem> + <listitem><ulink url="https://developer.mozilla.org/en-US/docs/Persona">Mozilla Persona</ulink> + <para> + +Mozilla's Persona is designed to provide decentralized, cryptographically +authenticated federated login in a way that does not expose the user to third +party tracking or require browser redirects or side channels. While it does +not directly provide the link sharing capabilities that Web-Send does, it is a +better solution to the privacy issues associated with federated login than +Web-Send is. + + </para> + </listitem> + </orderedlist> +</sect1> +</appendix> +</article> diff --git a/design-doc/outline.txt b/design-doc/outline.txt new file mode 100644 index 0000000..f7aa5ec --- /dev/null +++ b/design-doc/outline.txt @@ -0,0 +1,52 @@ +- Threat model: [Mostly Torbutton] + - [Remove the security requirements section] + +- Design overview and philosophy + - Security requirements [Torbutton] + + local leaks? + - state issues + - Privacy Requirements [Mostly blog post] + - Make local privacy optional + - Avoid Cross-Domain Linkability + - Indentifiers + - Fingerprinting + - 100% self-contained + - Does not share state with other modes/browsers + - Easy to remove + wipe with external tools + - No filters + +- Implementation + - Section Template + - Sub Section + - "Design Goal": + - "Implementation Status" + - Local Privacy Optional + - Linkability + - Stored State + - Cookies + - Cache + - DOM Storage + - HTTP Auth + - SSL state + - Plugins + - Fingerprinting + - Patches + +- Packaging + - Build Process Security + - External Addons + - Included + - HTTPS-E + - NoScript + - Torbutton + - Deliberately excluded + - Request Policy, AdblockPlus, etc + - Desired + - Perspectives/Convergence/etc + - Pref Changes + - Caused by Torbutton + - Set manually in profile + - Update security + - Thandy + + diff --git a/docs/audits/FF17_FEATURE_AUDIT b/docs/audits/FF17_FEATURE_AUDIT deleted file mode 100644 index b135c0a..0000000 --- a/docs/audits/FF17_FEATURE_AUDIT +++ /dev/null @@ -1,19 +0,0 @@ -- Can calc() accept device-width/height? - - No. Numbers only. - - Can viewport/meta viewport accept them? - - nsContentUtils::GetViewportInfo() might be the only place.. - - nsContentUtils::ProcessViewportInfo() - - Viewport seems unused on all but mobile - - Maybe worth testing.. - -- currentColor: OK -- scrollMax: OK -- IdleAPI: FirefoxOS only, but still present w/ pref?? - - Throws "The operation is insecure" exception - - Disabled for content. WebApp only. - -- Web Activities - - Seems unfinished and unexported to content - -- RegisterContent/ProtocolHandler -> Third party supercookie?? - - asks for confirmation diff --git a/docs/audits/FF17_NETWORK_AUDIT b/docs/audits/FF17_NETWORK_AUDIT deleted file mode 100644 index 8ec25ba..0000000 --- a/docs/audits/FF17_NETWORK_AUDIT +++ /dev/null @@ -1,84 +0,0 @@ - -Lowest level resolver calls: - - PR_GetHostByName - + ./profile/dirserviceprovider/src/nsProfileLock.cpp - + nsProfileLock::LockWithSymlink - + ./security/nss/lib/libpkix/pkix_pl_nss/module/pkix_pl_socket.c - - pkix_pl_Socket_CreateByHostAndPort() - - pkix_pl_Socket_CreateByName() - - ./security/nss/lib/certhigh/ocsp.c - - ocsp_ConnectToHost() - + ./security/nss/cmd/libpkix/pkix_pl/module/test_socket.c - + ./security/nss/cmd/vfyserv/vfyserv.c - - ./media/webrtc/trunk/src/modules/udp_transport/source/udp_transport_impl.cc (!!!) - --disable-webrtc!!! - + PR_GetAddrInfoByName - + ./security/nss/cmd/ssltap/ssltap.c - + ./security/nss/cmd/tstclnt/tstclnt.c - + ./security/nss/cmd/strsclnt/strsclnt.c - -Direct paths to DNS resolution: - + nsDNSService::Resolve - + nsDNSService::AsyncResolve - + nsHostResolver::ResolveHost - -Misc UDP (SOCK_DGRAM, PR_DESC_SOCKET_UDP): - + ./nsprpub/pr/src/io/prsocket.c - + PR_NewUDPSocket - + PR_OpenUDPSocket - + PR_Socket - + ./nsprpub/pr/src/pthreads/ptio.c - + ./netwerk/socket/nsUDPSocketProvider.cpp - -Misc TCP (SOCK_STREAM, PR_DESC_SOCKET_TCP): - + ./nsprpub/pr/src/pthreads/ptio.c - - ./nsprpub/pr/src/io/prsocket.c - - PR_NewTCPSocket - - PR_Socket - - PR_OpenTCPSocket - + ./nsprpub/pr/src/misc/prnetdb.c - + TCPSocket: - + ./security/manager/ssl/src/nsNSSIOLayer.cpp - + nsSSLIOLayerNewSocket() - + ./security/nss/lib/certhigh/ocsp.c - + ocsp_SendEncodedRequest - + ./security/nss/lib/libpkix/pkix_pl_nss/module/pkix_pl_socket.c - + pkix_pl_Socket_CreateClient - + pkix_pl_Socket_CreateServer - -Misc PR_Socket: - + ./nsprpub/pr/src/cplus/rcnetio.cpp - + RCNetStreamIO::RCNetStreamIO - -Misc XPCOM: - - *SocketProvider - + newSocket - + ./netwerk/base/src/nsSocketTransport2.cpp: - + addToSocket - + @mozilla.org/network/socket: - + createTransport() - + ./netwerk/protocol/http/nsHttpConnectionMgr.cpp - + ./netwerk/protocol/ftp/nsFtpConnectionThread.cpp: - + ./netwerk/protocol/ftp/nsFtpControlConnection.cpp: - + ./dom/network/src/TCPSocket.js - + open() - -Android may have DNS leaks.. - - ./mobile/android/base/httpclientandroidlib/impl/conn/DefaultClientConnectionOperator.java - -nsDNSService/nsPIDNSService/nsIDNSService - + calls nsHostResolver::ResolveHost - + used by: - + DNS prefetch (disabled) - + ./netwerk/base/src/nsIOService.cpp (offline mode only) - + ./netwerk/build/nsNetModule.cpp - + ./netwerk/protocol/websocket/WebSocketChannel.cpp - + ./netwerk/build/nsNetCID.h - + ./netwerk/socket/nsSOCKSIOLayer.cpp (proxy lookup only) - -netwerk/base/src/nsSocketTransport2.cpp - + nsSocketTransport::ResolveHost() has proper remote dns checks - + Resolution is done by using hostname as sockaddr - + PROXY_RESOLVES_HOST - - diff --git a/docs/audits/FF3.5_AUDIT b/docs/audits/FF3.5_AUDIT deleted file mode 100644 index 35a9fbf..0000000 --- a/docs/audits/FF3.5_AUDIT +++ /dev/null @@ -1,195 +0,0 @@ -First pass: Quick Review of Firefox Features -- Video Tag - - Docs: - - https://developer.mozilla.org/En/HTML/Element/Audio - - https://developer.mozilla.org/En/HTML/Element/Video - - https://developer.mozilla.org/En/HTML/Element/Source - - https://developer.mozilla.org/En/Manipulating_video_using_canvas - - https://developer.mozilla.org/En/nsIDOMHTMLMediaElement - - https://developer.mozilla.org/En/Media_formats_supported_by_the_audio_and_vi... - - http://en.flossmanuals.net/TheoraCookbook - - nsIContentPolicy is checked on load - - Uses NSIChannels for initial load - - Wrapped in nsHTMLMediaElement::mDecoder - - is nsOggDecoder() or nsWaveDecoder() - - liboggplay - - Governed by media.* prefs - - Preliminary audit shows they do not use the liboggplay tcp functions -- Geolocation - - Wifi: - - https://developer.mozilla.org/En/Monitoring_WiFi_access_points - - Requires security policy to allow. Then still prompted - - navigator.geolocation - - Governed by geo.enabled - - "2 week access token" is set - - geo.wifi.access_token.. Clearing is prob a good idea - - http://mxr.mozilla.org/mozilla1.9.1/source/dom/src/geolocation/NetworkGeoloc... - - https://developer.mozilla.org/En/Using_geolocation -- DNS prefetching after toggle - - prefetch pref? Always disable for now? - - network.dns.disablePrefetch - - Also disabled in netwerk/dns/src/nsDNSService2.cpp when manual proxies - are set.. - - This should prevent prefetching of non-tor urls in tor mode.. - - But the reverse is unclear. - - DocShell attribute!!1 YAY - - http://www.oxymoronical.com/experiments/apidocs/interface/nsIDocShell - - "Takes effect for the NEXT document loaded...." - - Do we win this race? hrmm.. If we do, the tor->nontor direction - should also be safe. - - Content policy called? - - No. See content/html/content/src/nsHTMLDNSPrefetch.cpp -- Storage - - https://developer.mozilla.org/en/Storage - - "It is available to trusted callers, meaning extensions and Firefox - components only." -- New content policy - - Content Security Policy. Addon-only -- "Offline resources" - - https://developer.mozilla.org/en/Offline_resources_in_Firefox - - https://developer.mozilla.org/en/nsIApplicationCache - - browser.cache.offline.enable toggles - - browser.cache.disk.enable does not apply. Seperate "device". - - Does our normal cache clearing mechanism apply? - - We call nsICacheService.evictEntries() - - May need: nsOfflineCacheDevice::EvictEntries(NULL) - - Code is smart enough to behave cleanly if we simply set - browser.cache.offline.enable or enable private browsing. -- Mouse gesture and other new DOM events -- Fonts - - Remote fonts obey content policy. Good. - - XXX: Are they cached independent of regular cache? Prob not. - - Hrmm can probe for installed fonts: - http://remysharp.com/2008/07/08/how-to-detect-if-a-font-is-installed-only-us... - http://www.lalit.org/lab/javascript-css-font-detect - http://www.ajaxupdates.com/cssjavascript-font-detector/ - http://code.google.com/p/jquery-fontavailable/ -- Drag and drop - - https://developer.mozilla.org/En/DragDrop/Drag_and_Drop - - https://developer.mozilla.org/En/DragDrop/Drag_Operations - - https://developer.mozilla.org/En/DragDrop/Dragging_and_Dropping_Multiple_Ite... - - https://developer.mozilla.org/En/DragDrop/Recommended_Drag_Types - - https://developer.mozilla.org/En/DragDrop/DataTransfer - - Should be no different than normal url handling.. -- Local Storage - - https://developer.mozilla.org/en/DOM/Storage#localStorage - - Disabled by dom storage pref.. - - Private browsing mode has its own DB - - Memory only? - - Disk Avoidance of gStorage and local storage: - - mSessionOnly set via nsDOMStorage::CanUseStorage() - - Seems to be set to true if cookies are session-only or private - browsing mode - - Our cookies are NOT session-only with dual cookie jars - - but this is ok if we clear the session storage.. - - XXX: Technically clearing session storage may break - sites if cookies remain though - - nsDOMStoragePersistentDB not used if mSessionOnly - - Can clear with nsDOMStorage::ClearAll() or nsIDOMStorage2::clear()? - - These only work for a particular storage. There's both global now - and per-origin storage instances - - Each docshell has tons of storages for each origin contained in it - - Toggling dom.storage.enabled does not clear existing storage - - Oh HOT! cookie-changed to clear cookies clears all storages! - - happens for both ff3.0 and 3.5 in dom/src/storage/nsDOMStorage.cpp - - Conclusion: - - can safely enable dom storage - - May have minor buggy usability issues unless we preserve it - when user is preserving cookies.. - -Second Pass: Verification of all Torbutton Assumptions -- "Better privacy controls" - - Basically UI stuff for prefs we set already - - address bar search disable option is interesting, but not - torbutton's job to toggle. Users will hate us. -- Private browsing - - https://developer.mozilla.org/En/Supporting_private_browsing_mode - - We should consider an option (off by default) to enable PBM during - toggle - - It is a good idea because it will let our users use DOM storage - safely and also may cause their plugins and other addons to be - safe - - Doing it always will cause the user to lose fine-grained control - of many settings - - Also we'll need to prevent them from leaving without toggling tor - - Stuff the emit does (grep for NS_PRIVATE_BROWSING_SWITCH_TOPIC and - "private-browsing") - - XXX: clear mozilla.org/security/sdr;1. We should too! Wtf is it?? - - Neg. Best to let them handle this. Users will be annoyed - at having to re-enter their passwords.. - - They also clear the console service.. - - Recommend watching private-browsing-cancel-vote and blocking if - we are performing a db operation - - Maybe we want to block transitions during our toggle for safety - - XXX: They also clear general.open_location.last_url - - XXX: mozilla.org/permissionmanager - - XXX: mozilla.org/content-pref/service - - XXX: Sets browser.zoom.siteSpecific to false - - Interesting.. They clear their titles.. I wonder if some - window managers log titles.. But that level of surveillance is - unbeatable.. - - XXX: Unless there is some way for flash or script to read titles? - - They empty the clipboard.. - - Can js access the clipboard?? ... - - Yes, but needs special pref+confirmation box - - http://www.dynamic-tools.net/toolbox/copyToClipboard/ - - They clear cache.. - - Cookies: - - Use in-memory table that is different than their default - - This could fuck up our cookie storage options - - We could maybe prevent them from getting this - event by wrapping nsCookieService::Observe(). Lullz.. - - NavHistory: - - XXX: nsNavHistory::AutoCompleteFeedback() doesn't track - awesomebar choices for feedback.. Is this done on disk? - - Don't add history entries - - We should block this observe event too if we can.. - - The session store stops storing tabs - - We could block this observe - - XXX: They expunge private temporary files on exit from PMB - - This is not done normally until browser exit or - "on-profile-change" - - emits browser:purge-domain-data.. Mostly just for session - editing it appears - - Direct component query for pbs.privateBrowsingEnabled - - This is where we have no ability to provide certain option - control - - browser.js seems to prevent user from allowing blocked - popups? - - Some items in some places context menu get blocked: - - Can't delete items from history? placesContext_deleteHost - - nsCookiePermission::InPrivateBrowsing() calls direct - - but is irellevant - - Form history cannot be saved while in PBM.. :( - - User won't be prompted for adding login passwords.. - - Can't remember prefs on content types - - Many components read this value upon init: - - This fucks up our observer game if tor starts enabled - - NavHistory and cookie and dl manager - - We could just wrap the bool on startup and lie - and emit later... :/ - - Or! emit an exit and an enter always at startup if tor is - enabled. - - Read iSec report - - Compare to Chrome - - API use cases -- SessionStore - - Has been reworked with observers and write methods. Should use those. -- security.enable_ssl2 to clear session id - - Still cleared -- browser.sessionstore.max_tabs_undo - - Yep. -- SafeBrowsing Update Key removed on cookie clear still? - - Yep. -- Livemark updates have kill events now -- Test if nsICertStore is still buggy... - -Third Pass: Exploit Auditing -- Remote fonts -- SVG with HTML -- Javascript threads+locking -- Ogg theora and vorbis codecs -- SQLite - - -- https://developer.mozilla.org/en/Firefox_3_for_developers diff --git a/docs/audits/FF4_AUDIT b/docs/audits/FF4_AUDIT deleted file mode 100644 index 7830eb3..0000000 --- a/docs/audits/FF4_AUDIT +++ /dev/null @@ -1,50 +0,0 @@ -- Review of https://developer.mozilla.org/en/Firefox_4_for_developers - - Potential proxy issues - - DocShell and plugins inside createHTMLDocument? - - https://developer.mozilla.org/en/DOM/DOMImplementation.createHTMLDocument - - WebSockets? - - Media attributes? - - "buffered" - - "preload" - - new codecs? - - What the hell is a blob url? - - https://developer.mozilla.org/en/DOM/window.createBlobURL - - https://developer.mozilla.org/en/DOM/window.revokeBlobURL - - Seems only relevent to FS injection.. - - WebThreads are OK: - - https://developer.mozilla.org/En/Using_web_workers - - Network activity blocked by content policy - - Fingerprinting issues: - - New screen attributes - - https://developer.mozilla.org/en/DOM/window.mozInnerScreenX, Y - - High Res Animation Timers: - - https://developer.mozilla.org/en/DOM/window.mozAnimationStartTime - - https://developer.mozilla.org/en/DOM/Animations_using_MozBeforePaint - - 50-60hz max.. Can we leverage this? - - timeStamps on keystroke events - - https://developer.mozilla.org/en/DOM/event.timeStamp - - Bounding rectangles -> window sizes? - - Maybe not display sizes, but seems possible to fingerprint rendered - content size.. ugh. - - https://developer.mozilla.org/en/DOM/element.getBoundingClientRect - - https://developer.mozilla.org/en/dom:range - - CSS resize, media queries, etc.. - - WebGL may also expose screen properties and video card properties: - - https://developer.mozilla.org/en/WebGL - - https://www.khronos.org/registry/webgl/specs/1.0/#5.2 - - https://www.khronos.org/registry/webgl/specs/1.0/#5.11 - - SVG needs auditing. It may also expose absolute coords, but appears OK - - https://developer.mozilla.org/en/SVG/SVG_animation_with_SMIL - - Mouse events reveal desktop coordinates - - https://bugzilla.mozilla.org/show_bug.cgi?id=503943 - - https://developer.mozilla.org/en/DOM/Event/UIEvent/MouseEvent - - Actual screen dimensions not exposed - - Identifier Storage - - Content Secuity Properties may need clearing: - - https://developer.mozilla.org/en/Security/CSP - - STS cache needs clearing - - New window.history functions may allow state smuggling - - https://developer.mozilla.org/en/DOM/Manipulating_the_browser_history - -- New Javascript hooking options may help improve Date() hooks: - - https://developer.mozilla.org/en/JavaScript/New_in_JavaScript/1.8.5 diff --git a/docs/design/CookieManagers.png b/docs/design/CookieManagers.png deleted file mode 100644 index 0fc3e64..0000000 Binary files a/docs/design/CookieManagers.png and /dev/null differ diff --git a/docs/design/Firefox17-TODO b/docs/design/Firefox17-TODO deleted file mode 100644 index 41ef38e..0000000 --- a/docs/design/Firefox17-TODO +++ /dev/null @@ -1,82 +0,0 @@ -+ Cleanups - + We specify browser.cache.memory.enable under disk avoidance. That's - wrong. We don't even set it at all. Torbutton relic? - + Disk leak documentation - + Firefox 17 will mess up all patch links - -- Heavy Writing by section - + Intro: - + We target Firefox ESR - + Component description - + Deprecation List/Future Philosophy: - + Linkability Transparency from - https://trac.torproject.org/projects/tor/ticket/5273#comment:12 - + Adversary Goals - + Describe how each adversary attack violates design goals - + "Correlate activity across multiple site visits" as one of the adversary - goals. This is the primary goal of the ad networks, though. We need to - explicitly mention it in the Adversary Goals section for completeness. - + Misc implementation - + Link to prefs.js and describe omni.ja and extension-overrides hacks - + document the environment variables and settings used to provide a non-grey "New Identity" button. - + Mockup privacy UI - + Identifier Linkability - + Image cache jail - + DOM storage jail - + 3.5.8 is not clear that what we're trying to limit is non-click - driven/non-interactive linkability rather than linkability in all cases. - Other sections may have this problem, too. - + This is a subtlety that arises from both the impossibility of satisfying - unlinkability due to covert channels in GET/POST, as well as the desire - to avoid breaking thinks like consensual federated login. - - Fingerprinting - + @font-face exemption and preference - + Canvas prompt - + describe our resolution defenses - + Limit CSS media queries - + System colors + fonts - + Explain why panopticlick is weirdsauce - + We report our useragent as 17.0 - + Click-to-play WebGL - + We should perhaps be more vocal about the fingerprinting issues with - some or all of http://www.w3.org/TR/navigation-timing/. I think I agree. - - provide an entropy count estimate for fingerprinting defenses - + Disk avoidance - + Private browsing + pref changes - + He reminded me about documenting disabling IndexedDB, but that is just one - of the many prefs.js changes we need to document. - - Testing - - Explain why panopticlick is weirdsauce - - Sync with QA pages - - Many are out of date - - http://www.stayinvisible.com/ - - Evercookie test page, and perhaps also - http://jeremiahgrossman.blogspot.de/2007/04/tracking-users-without-cookies.h... - -- Misc changes: - + Plugin handling - + All-but-flash patch - + Plugin manager manipulation - + We use Firefox's click-to-play - + Addons - + PDF.js inclusion - + List links to design violations/enhancements: - + https://trac.torproject.org/projects/tor/query?keywords=~tbb-linkability - + https://trac.torproject.org/projects/tor/query?keywords=~tbb-fingerprinting - - Update notification/version checking? - - Create a deprecation list and link to it: - - Referer Header - - Window.name - - We should only preserve window.name if the url bar domain remains the - same. I could be convinced of this, but it's going to be trickier to - implement and I think it's not really possible to remove linkability for user - clicks in general. - - Torbutton Security Settings - -- Packaging - - Pref changes - - Socks ports - - Torbutton does not update - - - diff --git a/docs/design/NewCookieManager.png b/docs/design/NewCookieManager.png deleted file mode 100644 index 97a0b40..0000000 Binary files a/docs/design/NewCookieManager.png and /dev/null differ diff --git a/docs/design/build.sh b/docs/design/build.sh deleted file mode 100755 index 5ffb650..0000000 --- a/docs/design/build.sh +++ /dev/null @@ -1 +0,0 @@ -xsltproc --output index.html.en -stringparam chunker.output.encoding UTF-8 --stringparam section.autolabel.max.depth 2 -stringparam section.label.includes.component.label 1 --stringparam section.autolabel 1 /usr/share/xml/docbook/stylesheet/docbook-xsl/xhtml/docbook.xsl design.xml diff --git a/docs/design/design.xml b/docs/design/design.xml deleted file mode 100644 index d1cdf0f..0000000 --- a/docs/design/design.xml +++ /dev/null @@ -1,2733 +0,0 @@ -<?xml version="1.0" encoding="ISO-8859-1"?> -<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN" - "file:///usr/share/sgml/docbook/xml-dtd-4.4-1.0-30.1/docbookx.dtd"> - -<article id="design"> - <articleinfo> - <title>The Design and Implementation of the Tor Browser [DRAFT]</title> - <author> - <firstname>Mike</firstname><surname>Perry</surname> - <affiliation> - <address><email>mikeperry#torproject org</email></address> - </affiliation> - </author> - <author> - <firstname>Erinn</firstname><surname>Clark</surname> - <affiliation> - <address><email>erinn#torproject org</email></address> - </affiliation> - </author> - <author> - <firstname>Steven</firstname><surname>Murdoch</surname> - <affiliation> - <address><email>sjmurdoch#torproject org</email></address> - </affiliation> - </author> - <pubdate>March 15, 2013</pubdate> - </articleinfo> - -<!-- -- Introduction and Threat model: [Mostly Torbutton] - - [Remove the security requirements section] ---> - -<sect1> - <title>Introduction</title> - <para> - -This document describes the <link linkend="adversary">adversary model</link>, -<link linkend="DesignRequirements">design requirements</link>, and <link -linkend="Implementation">implementation</link> <!-- <link -linkend="Packaging">packaging</link> and <link linkend="Testing">testing -procedures</link> --> of the Tor Browser. It is current as of Tor Browser -2.3.25-5 and Torbutton 1.5.1. - - </para> - <para> - -This document is also meant to serve as a set of design requirements and to -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. - - </para> - <sect2 id="components"> - <title>Browser Component Overview</title> - <para> - -The Tor Browser is based on <ulink -url="https://www.mozilla.org/en-US/firefox/organizations/%22%3EMozilla%27s Extended -Support Release (ESR) Firefox branch</ulink>. We have a <link -linkend="firefox-patches">series of patches</link> against this browser to -enhance privacy and security. Browser behavior is additionally augmented -through the <ulink -url="https://gitweb.torproject.org/torbutton.git/tree/master%22%3ETorbutton -extension</ulink>, though we are in the process of moving this -functionality into direct Firefox patches. We also <ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/HEAD:/build-scripts/config... -a number of Firefox preferences</ulink> from their defaults. - - </para> - <para> - -To help protect against potential Tor Exit Node eavesdroppers, we include -<ulink url="https://www.eff.org/https-everywhere">HTTPS-Everywhere</ulink>. To -provide users with optional defense-in-depth against Javascript and other -potential exploit vectors, we also include <ulink -url="http://noscript.net/%22%3ENoScript</ulink>. To protect against -PDF-based Tor proxy bypass and to improve usability, we include the <ulink -url="https://addons.mozilla.org/en-us/firefox/addon/pdfjs/%22%3EPDF.JS</ulink> -extension. We also modify <ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/HEAD:/build-scripts/config... -extension preferences</ulink> from their defaults. - - </para> - </sect2> -</sect1> - -<!-- -- Design overview and philosophy - - Security requirements [Torbutton] - + local leaks? - - state issues - - Privacy Requirements [Mostly blog post] - - Avoid Cross-Domain Linkability - - Indentifiers - - Fingerprinting - - 100% self-contained - - Does not share state with other modes/browsers - - Easy to remove + wipe with external tools - - click-to-play for "troublesome" features - - Philosophy - - No filters ---> - - -<sect1 id="DesignRequirements"> - <title>Design Requirements and Philosophy</title> - <para> - -The Tor Browser Design Requirements are meant to describe the properties of a -Private Browsing Mode that defends against both network and local forensic -adversaries. - - </para> - <para> - -There are two main categories of requirements: <link -linkend="security">Security Requirements</link>, and <link -linkend="privacy">Privacy Requirements</link>. Security Requirements are the -minimum properties in order for a browser to be able to support Tor and -similar privacy proxies safely. Privacy requirements are the set of properties -that cause us to prefer one browser over another. - - </para> - <para> - -While we will endorse the use of browsers that meet the security requirements, -it is primarily the privacy requirements that cause us to maintain our own -browser distribution. - - </para> - <para> - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL - NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and - "OPTIONAL" in this document are to be interpreted as described in - <ulink url="https://www.ietf.org/rfc/rfc2119.txt">RFC 2119</ulink>. - - </para> - - <sect2 id="security"> - <title>Security Requirements</title> - <para> - -The security requirements are primarily concerned with ensuring the safe use -of Tor. Violations in these properties typically result in serious risk for -the user in terms of immediate deanonymization and/or observability. With -respect to browser support, security requirements are the minimum properties -in order for Tor to support the use of a particular browser. - - </para> - -<orderedlist> - <listitem><link linkend="proxy-obedience"><command>Proxy -Obedience</command></link> - <para>The browser -MUST NOT bypass Tor proxy settings for any content.</para></listitem> - - <listitem><link linkend="state-separation"><command>State -Separation</command></link> - - <para> - -The browser MUST NOT provide the content window with any state from any other -browsers or any non-Tor browsing modes. This includes shared state from -independent plugins, and shared state from Operating System implementations of -TLS and other support libraries. - -</para></listitem> - - <listitem><link linkend="disk-avoidance"><command>Disk -Avoidance</command></link> - -<para> - -The browser MUST NOT write any information that is derived from or that -reveals browsing activity to the disk, or store it in memory beyond the -duration of one browsing session, unless the user has explicitly opted to -store their browsing history information to disk. - -</para></listitem> - <listitem><link linkend="app-data-isolation"><command>Application Data -Isolation</command></link> - -<para> - -The components involved in providing private browsing MUST be self-contained, -or MUST provide a mechanism for rapid, complete removal of all evidence of the -use of the mode. In other words, the browser MUST NOT write or cause the -operating system to write <emphasis>any information</emphasis> about the use -of private browsing to disk outside of the application's control. The user -must be able to ensure that secure deletion of the software is sufficient to -remove evidence of the use of the software. All exceptions and shortcomings -due to operating system behavior MUST be wiped by an uninstaller. However, due -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. - -</para></listitem> - -<!-- - <listitem><link linkend="update-safety"><command>Update -Safety</command></link> - -<para>The browser SHOULD NOT perform unsafe updates or upgrades.</para></listitem> ---> -</orderedlist> - - </sect2> - - <sect2 id="privacy"> - <title>Privacy Requirements</title> - <para> - -The privacy requirements are primarily concerned with reducing linkability: -the ability for a user's activity on one site to be linked with their activity -on another site without their knowledge or explicit consent. With respect to -browser support, privacy requirements are the set of properties that cause us -to prefer one browser over another. - - </para> - - <para> - -For the purposes of the unlinkability requirements of this section as well as -the descriptions in the <link linkend="Implementation">implementation -section</link>, a <command>url bar origin</command> means at least the -second-level DNS name. For example, for mail.google.com, the origin would be -google.com. Implementations MAY, at their option, restrict the url bar origin -to be the entire fully qualified domain name. - - </para> - -<orderedlist> - <listitem><link linkend="identifier-linkability"><command>Cross-Origin -Identifier Unlinkability</command></link> - <para> - -User activity on one url bar origin MUST NOT be linkable to their activity in -any other url bar origin by any third party automatically or without user -interaction or approval. This requirement specifically applies to linkability -from stored browser identifiers, authentication tokens, and shared state. The -requirement does not apply to linkable information the user manually submits -to sites, or due to information submitted during manual link traversal. This -functionality SHOULD NOT interfere with interactive, click-driven federated -login in a substantial way. - - </para> - </listitem> - <listitem><link linkend="fingerprinting-linkability"><command>Cross-Origin -Fingerprinting Unlinkability</command></link> - <para> - -User activity on one url bar origin MUST NOT be linkable to their activity in -any other url bar origin by any third party. This property specifically applies to -linkability from fingerprinting browser behavior. - - </para> - </listitem> - <listitem><link linkend="new-identity"><command>Long-Term -Unlinkability</command></link> - <para> - -The browser MUST provide an obvious, easy way for the user to remove all of -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. - - </para> - </listitem> -</orderedlist> - - </sect2> - <sect2 id="philosophy"> - <title>Philosophy</title> - <para> - -In addition to the above design requirements, the technology decisions about -Tor Browser are also guided by some philosophical positions about technology. - - </para> - <orderedlist> - <listitem><command>Preserve existing user model</command> - <para> - -The existing way that the user expects to use a browser must be preserved. If -the user has to maintain a different mental model of how the sites they are -using behave depending on tab, browser state, or anything else that would not -normally be what they experience in their default browser, the user will -inevitably be confused. They will make mistakes and reduce their privacy as a -result. Worse, they may just stop using the browser, assuming it is broken. - - </para> - <para> - -User model breakage was one of the <ulink -url="https://blog.torproject.org/blog/toggle-or-not-toggle-end-torbutton%22%3Efai... -of Torbutton</ulink>: Even if users managed to install everything properly, -the toggle model was too hard for the average user to understand, especially -in the face of accumulating tabs from multiple states crossed with the current -Tor-state of the browser. - - </para> - </listitem> - <listitem><command>Favor the implementation mechanism least likely to -break sites</command> - <para> - -In general, we try to find solutions to privacy issues that will not induce -site breakage, though this is not always possible. - - </para> - </listitem> - <listitem><command>Plugins must be restricted</command> - <para> - -Even if plugins always properly used the browser proxy settings (which none of -them do) and could not be induced to bypass them (which all of them can), the -activities of closed-source plugins are very difficult to audit and control. -They can obtain and transmit all manner of system information to websites, -often have their own identifier storage for tracking users, and also -contribute to fingerprinting. - - </para> - <para> - -Therefore, if plugins are to be enabled in private browsing modes, they must -be restricted from running automatically on every page (via click-to-play -placeholders), and/or be sandboxed to restrict the types of system calls they -can execute. If the user agent allows the user to craft an exemption to allow -a plugin to be used automatically, it must only apply to the top level url bar -domain, and not to all sites, to reduce cross-origin fingerprinting -linkability. - - </para> - </listitem> - <listitem><command>Minimize Global Privacy Options</command> - <para> - -<ulink url="https://trac.torproject.org/projects/tor/ticket/3100">Another -failure of Torbutton</ulink> was the options panel. Each option -that detectably alters browser behavior can be used as a fingerprinting tool. -Similarly, all extensions <ulink -url="http://blog.chromium.org/2010/06/extensions-in-incognito.html%22%3Eshould be -disabled in the mode</ulink> except as an opt-in basis. We should not load -system-wide and/or Operating System provided addons or plugins. - - </para> - <para> -Instead of global browser privacy options, privacy decisions should be made -<ulink -url="https://wiki.mozilla.org/Privacy/Features/Site-based_data_management_UI%22%3... -url bar origin</ulink> 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 -privacy permissions. - </para> - <para> -If the user has indicated they wish to record local history storage, these -permissions can be written to disk. Otherwise, they should remain memory-only. - </para> - </listitem> - <listitem><command>No filters</command> - <para> - -Site-specific or filter-based addons such as <ulink -url="https://addons.mozilla.org/en-US/firefox/addon/adblock-plus/%22%3EAdBlock -Plus</ulink>, <ulink url="http://requestpolicy.com/">Request Policy</ulink>, -<ulink url="http://www.ghostery.com/about">Ghostery</ulink>, <ulink -url="http://priv3.icsi.berkeley.edu/%22%3EPriv3</ulink>, and <ulink -url="http://sharemenot.cs.washington.edu/%22%3ESharemenot</ulink> are to be -avoided. We believe that these addons do not add any real privacy to a proper -<link linkend="Implementation">implementation</link> of the above <link -linkend="privacy">privacy requirements</link>, and that development efforts -should be focused on general solutions that prevent tracking by all -third parties, rather than a list of specific URLs or hosts. - </para> - <para> -Filter-based addons can also introduce strange breakage and cause usability -nightmares, and will also fail to do their job if an adversary simply -registers a new domain or creates a new url path. Worse still, the unique -filter sets that each user creates or installs will provide a wealth of -fingerprinting targets. - </para> - <para> - -As a general matter, we are also generally opposed to shipping an always-on Ad -blocker with Tor Browser. We feel that this would damage our credibility in -terms of demonstrating that we are providing privacy through a sound design -alone, as well as damage the acceptance of Tor users by sites that support -themselves through advertising revenue. - - </para> - <para> -Users are free to install these addons if they wish, but doing -so is not recommended, as it will alter the browser request fingerprint. - </para> - </listitem> - <listitem><command>Stay Current</command> - <para> -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. - </para> - </listitem> -<!-- - <listitem><command>Transparency in Navigation Tracking</command> - <para> - -While we believe it is possible to restrict third party tracking with only -minimal site breakage, it is our long-term goal to further reduce cross-origin -click navigation tracking to mechanisms that are detectable by experts and -attentive users, so they can alert the general public if cross-origin -click navigation tracking is happening where it should not be. - - </para> - <para> - -However, the entrenched nature of certain archaic web features make it -impossible for us to achieve this wider goal by ourselves without substantial -site breakage. So, instead we maintain a <link linkend="deprecate">Deprecation -Wishlist</link> of archaic web technologies that are currently being (ab)used -to facilitate federated login and other legitimate click-driven cross-domain -activity but that can one day be replaced with more privacy friendly, -auditable alternatives. - - </para> - </listitem> ---> - </orderedlist> - </sect2> -</sect1> - -<!-- -- Implementation - - Section Template - - Sub Section - - "Design Goal": - - "Implementation Status" - - Local Privacy - - Linkability - - Stored State - - Cookies - - Cache - - DOM Storage - - HTTP Auth - - SSL state - - Plugins - - Fingerprinting - - Location + timezone is part of this - - Patches? ---> - <sect1 id="adversary"> - <title>Adversary Model</title> - <para> - -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. - - </para> - <sect2 id="adversary-goals"> - <title>Adversary Goals</title> - <orderedlist> -<!-- These aren't really commands.. But it's the closest I could find in an -acceptable style.. Don't really want to make my own stylesheet --> - <listitem><command>Bypassing proxy settings</command> - <para>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.</para> - </listitem> - <listitem><command>Correlation of Tor vs Non-Tor Activity</command> - <para>If direct proxy bypass is not possible, the adversary will likely -happily settle for the ability to correlate something a user did via Tor with -their non-Tor activity. This can be done with cookies, cache identifiers, -javascript events, and even CSS. Sometimes the fact that a user uses Tor may -be enough for some authorities.</para> - </listitem> - <listitem><command>History disclosure</command> - <para> -The adversary may also be interested in history disclosure: the ability to -query a user's history to see if they have issued certain censored search -queries, or visited censored sites. - </para> - </listitem> - <listitem><command>Correlate activity across multiple sites</command> - <para> - -The primary goal of the advertising networks is to know that the user who -visited siteX.com is the same user that visited siteY.com to serve them -targeted ads. The advertising networks become our adversary insofar as they -attempt to perform this correlation without the user's explicit consent. - - </para> - </listitem> - <listitem><command>Fingerprinting/anonymity set reduction</command> - <para> - -Fingerprinting (more generally: "anonymity set reduction") is used to attempt -to gather identifying information on a particular individual without the use -of tracking identifiers. If the dissident or whistleblower's timezone is -available, and they are using a rare build of Firefox for an obscure operating -system, and they have a specific display resolution only used on one type of -laptop, this can be very useful information for tracking them down, or at -least <link linkend="fingerprinting">tracking their activities</link>. - - </para> - </listitem> - <listitem><command>History records and other on-disk -information</command> - <para> -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. - </para> - </listitem> - </orderedlist> - </sect2> - - <sect2 id="adversary-positioning"> - <title>Adversary Capabilities - Positioning</title> - <para> -The adversary can position themselves at a number of different locations in -order to execute their attacks. - </para> - <orderedlist> - <listitem><command>Exit Node or Upstream Router</command> - <para> -The adversary can run exit nodes, or alternatively, they may control routers -upstream of exit nodes. Both of these scenarios have been observed in the -wild. - </para> - </listitem> - <listitem><command>Ad servers and/or Malicious Websites</command> - <para> -The adversary can also run websites, or more likely, they can contract out -ad space from a number of different ad servers and inject content that way. For -some users, the adversary may be the ad servers themselves. It is not -inconceivable that ad servers may try to subvert or reduce a user's anonymity -through Tor for marketing purposes. - </para> - </listitem> - <listitem><command>Local Network/ISP/Upstream Router</command> - <para> -The adversary can also inject malicious content at the user's upstream router -when they have Tor disabled, in an attempt to correlate their Tor and Non-Tor -activity. - </para> - <para> - -Additionally, at this position the adversary can block Tor, or attempt to -recognize the traffic patterns of specific web pages at the entrance to the Tor -network. - - </para> - </listitem> - <listitem><command>Physical Access</command> - <para> -Some users face adversaries with intermittent or constant physical access. -Users in Internet cafes, for example, face such a threat. In addition, in -countries where simply using tools like Tor is illegal, users may face -confiscation of their computer equipment for excessive Tor usage or just -general suspicion. - </para> - </listitem> - </orderedlist> - </sect2> - - <sect2 id="attacks"> - <title>Adversary Capabilities - Attacks</title> - <para> - -The adversary can perform the following attacks from a number of different -positions to accomplish various aspects of their goals. It should be noted -that many of these attacks (especially those involving IP address leakage) are -often performed by accident by websites that simply have Javascript, dynamic -CSS elements, and plugins. Others are performed by ad servers seeking to -correlate users' activity across different IP addresses, and still others are -performed by malicious agents on the Tor network and at national firewalls. - - </para> - <orderedlist> - <listitem><command>Read and insert identifiers</command> - <para> - -The browser contains multiple facilities for storing identifiers that the -adversary creates for the purposes of tracking users. These identifiers are -most obviously cookies, but also include HTTP auth, DOM storage, cached -scripts and other elements with embedded identifiers, client certificates, and -even TLS Session IDs. - - </para> - <para> - -An adversary in a position to perform MITM content alteration can inject -document content elements to both read and inject cookies for arbitrary -domains. In fact, even many "SSL secured" websites are vulnerable to this sort of -<ulink url="http://seclists.org/bugtraq/2007/Aug/0070.html">active -sidejacking</ulink>. In addition, the ad networks of course perform tracking -with cookies as well. - - </para> - <para> - -These types of attacks are attempts at subverting our <link -linkend="identifier-linkability">Cross-Origin Identifier Unlinkability</link> and <link -linkend="new-identity">Long-Term Unlikability</link> design requirements. - - </para> - </listitem> - <listitem id="fingerprinting"><command>Fingerprint users based on browser -attributes</command> -<para> - -There is an absurd amount of information available to websites via attributes -of the browser. This information can be used to reduce anonymity set, or even -uniquely fingerprint individual users. Attacks of this nature are typically -aimed at tracking users across sites without their consent, in an attempt to -subvert our <link linkend="fingerprinting-linkability">Cross-Origin -Fingerprinting Unlinkability</link> and <link -linkend="new-identity">Long-Term Unlikability</link> design requirements. - -</para> - -<para> - -Fingerprinting is an intimidating -problem to attempt to tackle, especially without a metric to determine or at -least intuitively understand and estimate which features will most contribute -to linkability between visits. - -</para> - -<para> - -The <ulink url="https://panopticlick.eff.org/about.php">Panopticlick study -done</ulink> by the EFF uses the <ulink -url="https://en.wikipedia.org/wiki/Entropy_%28information_theory%29%22%3EShannon -entropy</ulink> - the number of identifying bits of information encoded in -browser properties - as this metric. Their <ulink -url="https://wiki.mozilla.org/Fingerprinting#Data%22%3Eresult data</ulink> is -definitely useful, and the metric is probably the appropriate one for -determining how identifying a particular browser property is. However, some -quirks of their study means that they do not extract as much information as -they could from display information: they only use desktop resolution and do -not attempt to infer the size of toolbars. In the other direction, they may be -over-counting in some areas, as they did not compute joint entropy over -multiple attributes that may exhibit a high degree of correlation. Also, new -browser features are added regularly, so the data should not be taken as -final. - - </para> - <para> - -Despite the uncertainty, all fingerprinting attacks leverage the following -attack vectors: - - </para> - <orderedlist> - <listitem><command>Observing Request Behavior</command> - <para> - -Properties of the user's request behavior comprise the bulk of low-hanging -fingerprinting targets. These include: User agent, Accept-* headers, pipeline -usage, and request ordering. Additionally, the use of custom filters such as -AdBlock and other privacy filters can be used to fingerprint request patterns -(as an extreme example). - - </para> - </listitem> - - <listitem><command>Inserting Javascript</command> - <para> - -Javascript can reveal a lot of fingerprinting information. It provides DOM -objects such as window.screen and window.navigator to extract information -about the useragent. - -Also, Javascript can be used to query the user's timezone via the -<function>Date()</function> object, <ulink -url="https://www.khronos.org/registry/webgl/specs/1.0/#5.13%22%3EWebGL</ulink> can -reveal information about the video card in use, and high precision timing -information can be used to <ulink -url="http://w2spconf.com/2011/papers/jspriv.pdf%22%3Efingerprint the CPU and -interpreter speed</ulink>. In the future, new JavaScript features such as -<ulink url="http://w3c-test.org/webperf/specs/ResourceTiming/">Resource -Timing</ulink> may leak an unknown amount of network timing related -information. - -<!-- FIXME: resource-timing stuff? --> - - </para> - </listitem> - - <listitem><command>Inserting Plugins</command> - <para> - -The Panopticlick project found that the mere list of installed plugins (in -navigator.plugins) was sufficient to provide a large degree of -fingerprintability. Additionally, plugins are capable of extracting font lists, -interface addresses, and other machine information that is beyond what the -browser would normally provide to content. In addition, plugins can be used to -store unique identifiers that are more difficult to clear than standard -cookies. <ulink url="http://epic.org/privacy/cookies/flash.html">Flash-based -cookies</ulink> fall into this category, but there are likely numerous other -examples. Beyond fingerprinting, plugins are also abysmal at obeying the proxy -settings of the browser. - - - </para> - </listitem> - <listitem><command>Inserting CSS</command> - <para> - -<ulink url="https://developer.mozilla.org/En/CSS/Media_queries">CSS media -queries</ulink> can be inserted to gather information about the desktop size, -widget size, display type, DPI, user agent type, and other information that -was formerly available only to Javascript. - - </para> - </listitem> - </orderedlist> - </listitem> - <listitem id="website-traffic-fingerprinting"><command>Website traffic fingerprinting</command> - <para> - -Website traffic fingerprinting is an attempt by the adversary to recognize the -encrypted traffic patterns of specific websites. In the case of Tor, this -attack would take place between the user and the Guard node, or at the Guard -node itself. - </para> - - <para> The most comprehensive study of the statistical properties of this -attack against Tor was done by <ulink -url="http://lorre.uni.lu/~andriy/papers/acmccs-wpes11-fingerprinting.pdf%22%3EPan... -et al</ulink>. Unfortunately, the publication bias in academia has encouraged -the production of a number of follow-on attack papers claiming "improved" -success rates, in some cases even claiming to completely invalidate any -attempt at defense. These "improvements" are actually enabled primarily by -taking a number of shortcuts (such as classifying only very small numbers of -web pages, neglecting to publish ROC curves or at least false positive rates, -and/or omitting the effects of dataset size on their results). Despite these -subsequent "improvements", we are skeptical of the efficacy of this attack in -a real world scenario, <emphasis>especially</emphasis> in the face of any -defenses. - - </para> - <para> - -In general, with machine learning, as you increase the <ulink -url="https://en.wikipedia.org/wiki/VC_dimension%22%3Enumber and/or complexity of -categories to classify</ulink> while maintaining a limit on reliable feature -information you can extract, you eventually run out of descriptive feature -information, and either true positive accuracy goes down or the false positive -rate goes up. This error is called the <ulink -url="http://www.cs.washington.edu/education/courses/csep573/98sp/lectures/lecture... -in your hypothesis space</ulink>. In fact, even for unbiased hypothesis -spaces, the number of training examples required to achieve a reasonable error -bound is <ulink -url="https://en.wikipedia.org/wiki/Probably_approximately_correct_learning#Equiva... -function of the complexity of the categories</ulink> you need to classify. - - </para> - <para> - - -In the case of this attack, the key factors that increase the classification -complexity (and thus hinder a real world adversary who attempts this attack) -are large numbers of dynamically generated pages, partially cached content, -and also the non-web activity of entire Tor network. This yields an effective -number of "web pages" many orders of magnitude larger than even <ulink -url="http://lorre.uni.lu/~andriy/papers/acmccs-wpes11-fingerprinting.pdf%22%3EPan... -"Open World" scenario</ulink>, which suffered continous 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 -to manipulate at low cost. - - </para> - <para> - -To make matters worse for a real-world adversary, the ocean of Tor Internet -activity (at least, when compared to a lab setting) makes it a certainty that -an adversary attempting examine large amounts of Tor traffic will ultimately -be overwhelmed by false positives (even after making heavy tradeoffs on the -ROC curve to minimize false positives to below 0.01%). This problem is known -in the IDS literature as the <ulink -url="http://www.raid-symposium.org/raid99/PAPERS/Axelsson.pdf%22%3EBase Rate -Fallacy</ulink>, and it is the primary reason that anomaly and activity -classification-based IDS and antivirus systems have failed to materialize in -the marketplace (despite early success in academic literature). - - </para> - <para> - -Still, we do not believe that these issues are enough to dismiss the attack -outright. But we do believe these factors make it both worthwhile and -effective to <link linkend="traffic-fingerprinting-defenses">deploy -light-weight defenses</link> that reduce the accuracy of this attack by -further contributing noise to hinder successful feature extraction. - - </para> - </listitem> - <listitem><command>Remotely or locally exploit browser and/or -OS</command> - <para> - -Last, but definitely not least, the adversary can exploit either general -browser vulnerabilities, plugin vulnerabilities, or OS vulnerabilities to -install malware and surveillance software. An adversary with physical access -can perform similar actions. - - </para> - <para> - -For the purposes of the browser itself, we limit the scope of this adversary -to one that has passive forensic access to the disk after browsing activity -has taken place. This adversary motivates our -<link linkend="disk-avoidance">Disk Avoidance</link> defenses. - - </para> - <para> - -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. <ulink -url="http://tails.boum.org/contribute/design/%22%3EThe Tails system</ulink> 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. - - </para> - </listitem> - </orderedlist> - </sect2> - -</sect1> - -<sect1 id="Implementation"> - <title>Implementation</title> - <para> - -The Implementation section is divided into subsections, each of which -corresponds to a <link linkend="DesignRequirements">Design Requirement</link>. -Each subsection is divided into specific web technologies or properties. The -implementation is then described for that property. - - </para> - <para> - -In some cases, the implementation meets the design requirements in a non-ideal -way (for example, by disabling features). In rare cases, there may be no -implementation at all. Both of these cases are denoted by differentiating -between the <command>Design Goal</command> and the <command>Implementation -Status</command> for each property. Corresponding bugs in the <ulink -url="https://trac.torproject.org/projects/tor/report%22%3ETor bug tracker</ulink> -are typically linked for these cases. - - </para> - <sect2 id="proxy-obedience"> - <title>Proxy Obedience</title> - <para> - -Proxy obedience is assured through the following: - </para> -<orderedlist> - <listitem>Firefox proxy settings, patches, and build flags - <para> -Our <ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/HEAD:/build-scripts/config... -preferences file</ulink> sets the Firefox proxy settings to use Tor directly as a -SOCKS proxy. It sets <command>network.proxy.socks_remote_dns</command>, -<command>network.proxy.socks_version</command>, -<command>network.proxy.socks_port</command>, and -<command>network.dns.disablePrefetch</command>. - </para> - <para> - -We also patch Firefox in order to <ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... -a DNS leak due to a WebSocket rate-limiting check</ulink>. As stated in the -patch, we believe the direct DNS resolution performed by this check is in -violation of the W3C standard, but <ulink -url="https://bugzilla.mozilla.org/show_bug.cgi?id=751465%22%3Ethis DNS proxy leak -remains present in stock Firefox releases</ulink>. - - </para> - <para> - -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 -<command>--disable-webrtc</command>. - - </para> - <para> - -We have verified that these settings and patches properly proxy HTTPS, OCSP, -HTTP, FTP, gopher (now defunct), DNS, SafeBrowsing Queries, all javascript -activity, including HTML5 audio and video objects, addon updates, wifi -geolocation queries, searchbox queries, XPCOM addon HTTPS/HTTP activity, -WebSockets, and live bookmark updates. We have also verified that IPv6 -connections are not attempted, through the proxy or otherwise (Tor does not -yet support IPv6). We have also verified that external protocol helpers, such -as smb urls and other custom protocol handlers are all blocked. - - </para> - <para> - -Numerous other third parties have also reviewed and tested the proxy settings -and have provided test cases based on their work. See in particular <ulink -url="http://decloak.net/%22%3Edecloak.net</ulink>. - - </para> -</listitem> - - <listitem>Disabling plugins - - <para>Plugins have the ability to make arbitrary OS system calls and <ulink -url="http://decloak.net/%22%3Ebypass proxy settings</ulink>. This includes -the ability to make UDP sockets and send arbitrary data independent of the -browser proxy settings. - </para> - <para> -Torbutton disables plugins by using the -<command>@mozilla.org/plugin/host;1</command> service to mark the plugin tags -as disabled. This block can be undone through both the Torbutton Security UI, -and the Firefox Plugin Preferences. - </para> - <para> -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 -<command>plugins.click_to_play</command>. - </para> - <para> -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 <ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... the load of any plugins except -for Flash and Gnash</ulink>. - - </para> - </listitem> - <listitem>External App Blocking and Drag Event Filtering - <para> - -External apps can be induced to load files that perform network activity. -Unfortunately, there are cases where such apps can be launched automatically -with little to no user input. In order to prevent this, Torbutton installs a -component to <ulink -url="https://gitweb.torproject.org/torbutton.git/blob_plain/HEAD:/src/components/... -provide the user with a popup</ulink> whenever the browser attempts to launch -a helper app. - - </para> - <para> - -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 <ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... -an observer event during dragging</ulink> to allow us to filter the drag -events from Torbutton before the OS downloads the URLs the events contained. - - </para> - </listitem> - <listitem>Disabling system extensions and clearing the addon whitelist - <para> - -Firefox addons can perform arbitrary activity on your computer, including -bypassing Tor. It is for this reason we disable the addon whitelist -(<command>xpinstall.whitelist.add</command>), so that users are prompted -before installing addons regardless of the source. We also exclude -system-level addons from the browser through the use of -<command>extensions.enabledScopes</command> and -<command>extensions.autoDisableScopes</command>. - - </para> - </listitem> - </orderedlist> - </sect2> - <sect2 id="state-separation"> - <title>State Separation</title> - <para> - -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 -<command>extensions.enabledScopes</command> and -<command>extensions.autoDisableScopes</command>. Furthermore, plugins are -disabled, which prevents Flash cookies from leaking from a pre-existing Flash -directory. - - </para> - </sect2> - <sect2 id="disk-avoidance"> - <title>Disk Avoidance</title> - <sect3> - <title>Design Goal:</title> - <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> - </sect3> - <sect3> - <title>Implementation Status:</title> - <blockquote> - -We achieve this goal through several mechanisms. First, we set the Firefox -Private Browsing preference -<command>browser.privatebrowsing.autostart</command>. In addition, four Firefox patches are needed to prevent disk writes, even if -Private Browsing Mode is enabled. We need to - -<ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... -the permissions manager from recording HTTPS STS state</ulink>, -<ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... -intermediate SSL certificates from being recorded</ulink>, -<ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... -download history from being recorded</ulink>, and -<ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... -the content preferences service from recording site zoom</ulink>. - -For more details on these patches, <link linkend="firefox-patches">see the -Firefox Patches section</link>. - - </blockquote> - <blockquote> - -As an additional defense-in-depth measure, we set the following preferences: -<command></command>, -<command>browser.cache.disk.enable</command>, -<command>browser.cache.offline.enable</command>, -<command>dom.indexedDB.enabled</command>, -<command>network.cookie.lifetimePolicy</command>, -<command>signon.rememberSignons</command>, -<command>browser.formfill.enable</command>, -<command>browser.download.manager.retention</command>, -<command>browser.sessionstore.privacy_level</command>, -and <command>network.cookie.lifetimePolicy</command>. Many of these -preferences are likely redundant with -<command>browser.privatebrowsing.autostart</command>, but we have not done the -auditing work to ensure that yet. - - </blockquote> - <blockquote> - -Torbutton also <ulink -url="https://gitweb.torproject.org/torbutton.git/blob/HEAD:/src/components/tbSess... -code</ulink> to prevent the Firefox session store from writing to disk. - </blockquote> - <blockquote> - -For more details on disk leak bugs and enhancements, see the <ulink -url="https://trac.torproject.org/projects/tor/query?keywords=~tbb-disk-leak&s... tag in our bugtracker</ulink> - </blockquote> - </sect3> - </sect2> - <sect2 id="app-data-isolation"> - <title>Application Data Isolation</title> - <para> - -Tor Browser Bundle MUST NOT cause any information to be written outside of the -bundle directory. This is to ensure that the user is able to completely and -safely remove the bundle without leaving other traces of Tor usage on their -computer. - - </para> - <para> - -To ensure TBB directory isolation, we set -<command>browser.download.useDownloadDir</command>, -<command>browser.shell.checkDefaultBrowser</command>, and -<command>browser.download.manager.addToRecentDocs</command>. We also set the -$HOME environment variable to be the TBB extraction directory. - </para> - - </sect2> -<!-- FIXME: Write me... - <sect2 id="update-safety"> - <title>Update Safety</title> - <para>FIXME: Write me.. - </para> - </sect2> ---> - <sect2 id="identifier-linkability"> - <title>Cross-Origin Identifier Unlinkability</title> - <!-- FIXME: Mention web-send?? --> - <para> - -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 -existing web technology, that technology or functionality is disabled. Our -<link linkend="privacy">design goal</link> is to ultimately eliminate the need to disable arbitrary -technologies, and instead simply alter them in ways that allows them to -function in a backwards-compatible way while avoiding linkability. Users -should be able to use federated login of various kinds to explicitly inform -sites who they are, but that information should not transparently allow a -third party to record their activity from site to site without their prior -consent. - - </para> - <para> - -The benefit of this approach comes not only in the form of reduced -linkability, but also in terms of simplified privacy UI. If all stored browser -state and permissions become associated with the url bar origin, the six or -seven different pieces of privacy UI governing these identifiers and -permissions can become just one piece of UI. For instance, a window that lists -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. - - </para> - <figure><title>Improving the Privacy UI</title> - <mediaobject> - <imageobject> - <imagedata align="center" fileref="NewCookieManager.png"/> - </imageobject> - </mediaobject> - <caption> <para/> - -This example UI is a mock-up of how isolating identifiers to the URL bar -origin can simplify the privacy UI for all data - not just cookies. Once -browser identifiers and site permissions operate on a url bar basis, the same -privacy window can represent browsing history, DOM Storage, HTTP Auth, search -form history, login values, and so on within a context menu for each site. - -</caption> - </figure> - <orderedlist> - <listitem>Cookies - <para><command>Design Goal:</command> - -All cookies MUST be double-keyed to the url bar origin and third-party -origin. There exists a <ulink -url="https://bugzilla.mozilla.org/show_bug.cgi?id=565965%22%3EMozilla bug</ulink> -that contains a prototype patch, but it lacks UI, and does not apply to modern -Firefoxes. - - </para> - <para><command>Implementation Status:</command> - -As a stopgap to satisfy our design requirement of unlinkability, we currently -entirely disable 3rd party cookies by setting -<command>network.cookie.cookieBehavior</command> to 1. We would prefer that -third party content continue to function, but we believe the requirement for -unlinkability trumps that desire. - - </para> - </listitem> - <listitem>Cache - <para> - -Cache is isolated to the url bar origin by using a technique pioneered by -Colin Jackson et al, via their work on <ulink -url="http://www.safecache.com/%22%3ESafeCache</ulink>. The technique re-uses the -<ulink -url="https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsICachingChannel...</ulink> -attribute that Firefox uses internally to prevent improper caching and reuse -of HTTP POST data. - - </para> - <para> - -However, to <ulink -url="https://trac.torproject.org/projects/tor/ticket/3666%22%3Eincrease the -security of the isolation</ulink> and to <ulink -url="https://trac.torproject.org/projects/tor/ticket/3754%22%3Esolve conflicts -with OCSP relying the cacheKey property for reuse of POST requests</ulink>, we -had to <ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... -Firefox to provide a cacheDomain cache attribute</ulink>. We use the fully -qualified url bar domain as input to this field, to avoid the complexities -of heuristically determining the second-level DNS name. - - </para> - <para> - -<!-- FIXME: This could use a few more specifics.. Maybe. The Chrome folks -won't care, but the Mozilla folks might. --> Furthermore, we chose a different -isolation scheme than the Stanford implementation. First, we decoupled the -cache isolation from the third party cookie attribute. Second, we use several -mechanisms to attempt to determine the actual location attribute of the -top-level window (to obtain the url bar FQDN) used to load the page, as -opposed to relying solely on the Referer property. - - </para> - <para> - -Therefore, <ulink -url="http://crypto.stanford.edu/sameorigin/safecachetest.html%22%3Ethe original -Stanford test cases</ulink> are expected to fail. Functionality can still be -verified by navigating to <ulink url="about:cache">about:cache</ulink> and -viewing the key used for each cache entry. Each third party element should -have an additional "domain=string" property prepended, which will list the -FQDN that was used to source the third party element. - - </para> - <para> - -Additionally, because the image cache is a separate entity from the content -cache, we had to patch Firefox to also <ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... -this cache per url bar domain</ulink>. - - </para> - </listitem> - <listitem>HTTP Auth - <para> - -HTTP authentication tokens are removed for third party elements using the -<ulink -url="https://developer.mozilla.org/en/Setting_HTTP_request_headers#Observers%22%3... -observer</ulink> to remove the Authorization headers to prevent <ulink -url="http://jeremiahgrossman.blogspot.com/2007/04/tracking-users-without-cookies.... -linkability between domains</ulink>. - </para> - </listitem> - <listitem>DOM Storage - <para> - -DOM storage for third party domains MUST be isolated to the url bar origin, -to prevent linkability between sites. This functionality is provided through a -<ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... -to Firefox</ulink>. - - </para> - </listitem> - <listitem>Flash cookies - <para><command>Design Goal:</command> - -Users should be able to click-to-play flash objects from trusted sites. To -make this behavior unlinkable, we wish to include a settings file for all platforms that disables flash -cookies using the <ulink -url="http://www.macromedia.com/support/documentation/en/flashplayer/help/settings... -settings manager</ulink>. - - </para> - <para><command>Implementation Status:</command> - -We are currently <ulink -url="https://trac.torproject.org/projects/tor/ticket/3974%22%3Ehaving -difficulties</ulink> causing Flash player to use this settings -file on Windows, so Flash remains difficult to enable. - - </para> - </listitem> - <listitem>SSL+TLS session resumption, HTTP Keep-Alive and SPDY - <para><command>Design Goal:</command> - -TLS session resumption tickets and SSL Session IDs MUST be limited to the url -bar origin. HTTP Keep-Alive connections from a third party in one url bar -origin MUST NOT be reused for that same third party in another url bar origin. - - </para> - <para><command>Implementation Status:</command> - -We currently clear SSL Session IDs upon <link linkend="new-identity">New -Identity</link>, we disable TLS Session Tickets via the Firefox Pref -<command>security.enable_tls_session_tickets</command>. We disable SSL Session -IDs via a <ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... -to Firefox</ulink>. To compensate for the increased round trip latency from disabling -these performance optimizations, we also enable -<ulink url="https://tools.ietf.org/html/draft-bmoeller-tls-falsestart-00">TLS -False Start</ulink> via the Firefox Pref -<command>security.ssl.enable_false_start</command>. - </para> - <para> - -Because of the extreme performance benefits of HTTP Keep-Alive for interactive -web apps, and because of the difficulties of conveying urlbar origin -information down into the Firefox HTTP layer, as a compromise we currently -merely reduce the HTTP Keep-Alive timeout to 20 seconds (which is measured -from the last packet read on the connection) using the Firefox preference -<command>network.http.keep-alive.timeout</command>. - - </para> - <para> -However, because SPDY can store identifiers and has extremely long keepalive -duration, it is disabled through the Firefox preference -<command>network.http.spdy.enabled</command>. - </para> - </listitem> - <listitem>Automated cross-origin redirects MUST NOT store identifiers - <para><command>Design Goal:</command> - -To prevent attacks aimed at subverting the Cross-Origin Identifier -Unlinkability <link linkend="privacy">privacy requirement</link>, the browser -MUST NOT store any identifiers (cookies, cache, DOM storage, HTTP auth, etc) -for cross-origin redirect intermediaries that do not prompt for user input. -For example, if a user clicks on a bit.ly url that redirects to a -doubleclick.net url that finally redirects to a cnn.com url, only cookies from -cnn.com should be retained after the redirect chain completes. - - </para> - <para> - -Non-automated redirect chains that require user input at some step (such as -federated login systems) SHOULD still allow identifiers to persist. - - </para> - <para><command>Implementation status:</command> - -There are numerous ways for the user to be redirected, and the Firefox API -support to detect each of them is poor. We have a <ulink -url="https://trac.torproject.org/projects/tor/ticket/3600%22%3Etrac bug -open</ulink> to implement what we can. - - </para> - </listitem> - <listitem>window.name - <para> - -<ulink -url="https://developer.mozilla.org/En/DOM/Window.name%22%3Ewindow.name</ulink> is -a magical DOM property that for some reason is allowed to retain a persistent value -for the lifespan of a browser tab. It is possible to utilize this property for -<ulink url="http://www.thomasfrank.se/sessionvars.html">identifier -storage</ulink>. - - </para> - <para> - -In order to eliminate non-consensual linkability but still allow for sites -that utilize this property to function, we reset the window.name property of -tabs in Torbutton every time we encounter a blank Referer. This behavior -allows window.name to persist for the duration of a click-driven navigation -session, but as soon as the user enters a new URL or navigates between -https/http schemes, the property is cleared. - - </para> - </listitem> - <listitem>Auto form-fill - <para> - -We disable the password saving functionality in the browser as part of our -<link linkend="disk-avoidance">Disk Avoidance</link> requirement. However, -since users may decide to re-enable disk history records and password saving, -we also set the <ulink -url="http://kb.mozillazine.org/Signon.autofillForms%22%3Esignon.autofillForms</ulink> -preference to false to prevent saved values from immediately populating -fields upon page load. Since Javascript can read these values as soon as they -appear, setting this preference prevents automatic linkability from stored passwords. - - </para> - </listitem> - <listitem>HSTS supercookies - <para> - -An extreme (but not impossible) attack to mount is the creation of <ulink -url="http://www.leviathansecurity.com/blog/archives/12-The-Double-Edged-Sword-of-... -supercookies</ulink>. Since HSTS effectively stores one bit of information per domain -name, an adversary in possession of numerous domains can use them to construct -cookies based on stored HSTS state. - - </para> - <para><command>Design Goal:</command> - -There appears to be three options for us: 1. Disable HSTS entirely, and rely -instead on HTTPS-Everywhere to crawl and ship rules for HSTS sites. 2. -Restrict the number of HSTS-enabled third parties allowed per url bar origin. -3. Prevent third parties from storing HSTS rules. We have not yet decided upon -the best approach. - - </para> - <para><command>Implementation Status:</command> Currently, HSTS state is -cleared by <link linkend="new-identity">New Identity</link>, but we don't -defend against the creation of these cookies between <command>New -Identity</command> invocations. - </para> - </listitem> - <listitem>Exit node usage - <para><command>Design Goal:</command> - -Every distinct navigation session (as defined by a non-blank Referer header) -MUST exit through a fresh Tor circuit in Tor Browser to prevent exit node -observers from linking concurrent browsing activity. - - </para> - <para><command>Implementation Status:</command> - -The Tor feature that supports this ability only exists in the 0.2.3.x-alpha -series. <ulink -url="https://trac.torproject.org/projects/tor/ticket/3455%22%3ETicket -#3455</ulink> is the Torbutton ticket to make use of the new Tor -functionality. - - </para> - </listitem> - </orderedlist> - <para> -For more details on identifier linkability bugs and enhancements, see the <ulink -url="https://trac.torproject.org/projects/tor/query?keywords=~tbb-linkability&... tag in our bugtracker</ulink> - </para> - </sect2> - <sect2 id="fingerprinting-linkability"> - <title>Cross-Origin Fingerprinting Unlinkability</title> - <para> - -In order to properly address the fingerprinting adversary on a technical -level, we need a metric to measure linkability of the various browser -properties beyond any stored origin-related state. <ulink -url="https://panopticlick.eff.org/about.php%22%3EThe Panopticlick Project</ulink> -by the EFF provides us with a prototype of such a metric. The researchers -conducted a survey of volunteers who were asked to visit an experiment page -that harvested many of the above components. They then computed the Shannon -Entropy of the resulting distribution of each of several key attributes to -determine how many bits of identifying information each attribute provided. - - </para> - <para> - -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 <emphasis>among</emphasis> Tor Browser users. We -do not believe it is possible to solve cross-browser fingerprinting issues. - - </para> - <para> - -Unfortunately, the unsolvable nature of the cross-browser fingerprinting -problem means that the Panopticlick test website itself is not useful for -evaluating the actual effectiveness of our defenses, or the fingerprinting -defenses of any other web browser. Because the Panopticlick dataset is based -on browser data spanning a number of widely deployed browsers over a number of -years, any fingerprinting defenses attempted by browsers today are very likely -to cause Panopticlick to report an <emphasis>increase</emphasis> in -fingerprintability and entropy, because those defenses will stand out in sharp -contrast to historical data. We have been <ulink -url="https://trac.torproject.org/projects/tor/ticket/6119%22%3Eworking to convince -the EFF</ulink> that it is worthwhile to release the source code to -Panopticlick to allow us to run our own version for this reason. - - </para> - <sect3 id="fingerprinting-defenses"> - <title>Fingerprinting defenses in the Tor Browser</title> - - <orderedlist> - <listitem>Plugins - <para> - -Plugins add to fingerprinting risk via two main vectors: their mere presence in -window.navigator.plugins, as well as their internal functionality. - - </para> - <para><command>Design Goal:</command> - -All plugins that have not been specifically audited or sandboxed MUST be -disabled. To reduce linkability potential, even sandboxed plugins should not -be allowed to load objects until the user has clicked through a click-to-play -barrier. Additionally, version information should be reduced or obfuscated -until the plugin object is loaded. For flash, we wish to <ulink -url="https://trac.torproject.org/projects/tor/ticket/3974%22%3Eprovide a -settings.sol file</ulink> to disable Flash cookies, and to restrict P2P -features that are likely to bypass proxy settings. - - </para> - <para><command>Implementation Status:</command> - -Currently, we entirely disable all plugins in Tor Browser. However, as a -compromise due to the popularity of Flash, we allow users to re-enable Flash, -and flash objects are blocked behind a click-to-play barrier that is available -only after the user has specifically enabled plugins. Flash is the only plugin -available, the rest are <ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... -blocked from loading by a Firefox patch</ulink>. We also set the Firefox -preference <command>plugin.expose_full_path</command> to false, to avoid -leaking plugin installation information. - - </para> - </listitem> - <listitem>HTML5 Canvas Image Extraction - <para> - -The <ulink url="https://developer.mozilla.org/en-US/docs/HTML/Canvas">HTML5 -Canvas</ulink> is a feature that has been added to major browsers after the -EFF developed their Panopticlick study. After plugins and plugin-provided -information, we believe that the HTML5 Canvas is the single largest -fingerprinting threat browsers face today. <ulink -url="http://www.w2spconf.com/2012/papers/w2sp12-final4.pdf%22%3EInitial -studies</ulink> show that the Canvas can provide an easy-access fingerprinting -target: The adversary simply renders WebGL, font, and named color data to a -Canvas element, extracts the image buffer, and computes a hash of that image -data. Subtle differences in the video card, font packs, and even font and -graphics library versions allow the adversary to produce a stable, simple, -high-entropy fingerprint of a computer. In fact, the hash of the rendered -image can be used almost identically to a tracking cookie by the web server. - - </para> - <para> - -To reduce the threat from this vector, we have patched Firefox to <ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... -before returning valid image data</ulink> 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. - - </para> - </listitem> - <listitem>WebGL - <para> - -WebGL is fingerprintable both through information that is exposed about the -underlying driver and optimizations, as well as through performance -fingerprinting. - - </para> - <para> - -Because of the large amount of potential fingerprinting vectors and the <ulink -url="http://www.contextis.com/resources/blog/webgl/%22%3Epreviously unexposed -vulnerability surface</ulink>, we deploy a similar strategy against WebGL as -for plugins. First, WebGL Canvases have click-to-play placeholders (provided -by NoScript), and do not run until authorized by the user. Second, we -obfuscate driver information by setting the Firefox preferences -<command>webgl.disable-extensions</command> and -<command>webgl.min_capability_mode</command>, which reduce the information -provided by the following WebGL API calls: <command>getParameter()</command>, -<command>getSupportedExtensions()</command>, and -<command>getExtension()</command>. - - </para> - </listitem> - <listitem>Fonts - <para> - -According to the Panopticlick study, fonts provide the most linkability when -they are provided as an enumerable list in filesystem order, via either the -Flash or Java plugins. However, it is still possible to use CSS and/or -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. - - </para> - <para> - -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 <ulink -url="https://secure.wikimedia.org/wikipedia/en/wiki/Unicode_typeface#List_of_Unic... -subset</ulink> 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. - - </para> - <para><command>Implementation Status:</command> - -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 <ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... -a Firefox patch</ulink>. We create two prefs, -<command>browser.display.max_font_attempts</command> and -<command>browser.display.max_font_count</command> for this purpose. Once these -limits are reached, the browser behaves as if -<command>browser.display.use_document_fonts</command> was set. We are -still working to determine optimal values for these prefs. - - </para> - <para> - -To improve rendering, we exempt remote <ulink -url="https://developer.mozilla.org/en-US/docs/CSS/@font-face%22%3E@font-face -fonts</ulink> 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. - - </para> - </listitem> - <listitem>Desktop resolution, CSS Media Queries, and System Colors - <para> - -Both CSS and Javascript have access to a lot of information about the screen -resolution, usable desktop size, OS widget size, toolbar size, title bar size, -system theme colors, and other desktop features that are not at all relevant -to rendering and serve only to provide information for fingerprinting. - - </para> - <para><command>Design Goal:</command> - -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 -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. - - </para> - <para><command>Implementation Status:</command> - -We have implemented the above strategy using a window observer to <ulink -url="https://gitweb.torproject.org/torbutton.git/blob/HEAD:/src/chrome/content/to... -new windows based on desktop resolution</ulink>. Additionally, we patch -Firefox to use the client content window size <ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... -window.screen</ulink> and <ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... -CSS Media Queries</ulink>. Similarly, we <ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... -DOM events to return content window relative points</ulink>. We also patch -Firefox to <ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... -a fixed set of system colors to content window CSS</ulink>. - - </para> - <para> - -To further reduce resolution-based fingerprinting, we are <ulink -url="https://trac.torproject.org/projects/tor/ticket/7256%22%3Einvestigating -zoom/viewport-based mechanisms</ulink> 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. - - </para> - </listitem> - <listitem>User Agent and HTTP Headers - <para><command>Design Goal:</command> - -All Tor Browser users MUST provide websites with an identical user agent and -HTTP header set for a given request type. We omit the Firefox minor revision, -and report a popular Windows platform. If the software is kept up to date, -these headers should remain identical across the population even when updated. - - </para> - <para><command>Implementation Status:</command> - -Firefox provides several options for controlling the browser user agent string -which we leverage. We also set similar prefs for controlling the -Accept-Language and Accept-Charset headers, which we spoof to English by default. Additionally, we -<ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... -content script access</ulink> to Components.interfaces, which <ulink -url="http://pseudo-flaw.net/tor/torbutton/fingerprint-firefox.html%22%3Ecan be -used</ulink> to fingerprint OS, platform, and Firefox minor version. </para> - - </listitem> - <listitem>Timezone and clock offset - <para><command>Design Goal:</command> - -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 -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. - - </para> - <para><command>Implementation Status:</command> - -We set the timezone using the TZ environment variable, which is supported on -all platforms. Additionally, we plan to <ulink -url="https://trac.torproject.org/projects/tor/ticket/3652%22%3Eobtain a clock -offset from Tor</ulink>, but this won't be available until Tor 0.2.3.x is in -use. - - </para> - </listitem> - <listitem>Javascript performance fingerprinting - <para> - -<ulink url="http://w2spconf.com/2011/papers/jspriv.pdf">Javascript performance -fingerprinting</ulink> is the act of profiling the performance -of various Javascript functions for the purpose of fingerprinting the -Javascript engine and the CPU. - - </para> - <para><command>Design Goal:</command> - -We have <ulink -url="https://trac.torproject.org/projects/tor/ticket/3059%22%3Eseveral potential -mitigation approaches</ulink> to reduce the accuracy of performance -fingerprinting without risking too much damage to functionality. Our current -favorite is to reduce the resolution of the Event.timeStamp and the Javascript -Date() object, while also introducing jitter. Our goal is to increase the -amount of time it takes to mount a successful attack. <ulink -url="http://w2spconf.com/2011/papers/jspriv.pdf%22%3EMowery et al</ulink> found that -even with the default precision in most browsers, they required up to 120 -seconds of amortization and repeated trials to get stable results from their -feature set. We intend to work with the research community to establish the -optimum trade-off between quantization+jitter and amortization time. - - - </para> - <para><command>Implementation Status:</command> - -Currently, the only mitigation against performance fingerprinting is to -disable <ulink url="http://www.w3.org/TR/navigation-timing/">Navigation -Timing</ulink> through the Firefox preference -<command>dom.enable_performance</command>. - - </para> - </listitem> - <listitem>Non-Uniform HTML5 API Implementations - <para> - -At least two HTML5 features have different implementation status across the -major OS vendors: the <ulink -url="https://developer.mozilla.org/en-US/docs/DOM/window.navigator.battery%22%3EB... -API</ulink> and the <ulink -url="https://developer.mozilla.org/en-US/docs/DOM/window.navigator.connection%22%... -Connection API</ulink>. We disable these APIs -through the Firefox preferences <command>dom.battery.enabled</command> and -<command>dom.network.enabled</command>. - - </para> - </listitem> - <listitem>Keystroke fingerprinting - <para> - -Keystroke fingerprinting is the act of measuring key strike time and key -flight time. It is seeing increasing use as a biometric. - - </para> - <para><command>Design Goal:</command> - -We intend to rely on the same mechanisms for defeating Javascript performance -fingerprinting: timestamp quantization and jitter. - - </para> - <para><command>Implementation Status:</command> -We have no implementation as of yet. - </para> - </listitem> - </orderedlist> - </sect3> - <para> -For more details on identifier linkability bugs and enhancements, see the <ulink -url="https://trac.torproject.org/projects/tor/query?keywords=~tbb-fingerprinting&... tag in our bugtracker</ulink> - </para> - </sect2> - <sect2 id="new-identity"> - <title>Long-Term Unlinkability via "New Identity" button</title> - <para> - -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. - - </para> - - <sect3> - <title>Design Goal:</title> - <blockquote> - -All linkable identifiers and browser state MUST be cleared by this feature. - - </blockquote> - </sect3> - - <sect3> - <title>Implementation Status:</title> - <blockquote> - <para> - -First, Torbutton disables Javascript in all open tabs and windows by using -both the <ulink -url="https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIDocShe...</ulink> -attribute as well as <ulink -url="https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIDOMWin...)</ulink>. -We then stop all page activity for each tab using <ulink -url="https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIWebNav...)</ulink>. -We then clear the site-specific Zoom by temporarily disabling the preference -<command>browser.zoom.siteSpecific</command>, and clear the GeoIP wifi token URL -<command>geo.wifi.access_token</command> and the last opened URL prefs (if -they exist). Each tab is then closed. - - </para> - <para> - -After closing all tabs, we then emit "<ulink -url="https://developer.mozilla.org/en-US/docs/Supporting_private_browsing_mode#Pr...</ulink>" -(which instructs addons and various Firefox components to clear their session -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). - - </para> - <para> - -After the state is cleared, we then close all remaining HTTP keep-alive -connections and then send the NEWNYM signal to the Tor control port to cause a -new circuit to be created. - </para> - <para> -Finally, a fresh browser window is opened, and the current browser window is -closed (this does not spawn a new Firefox process, only a new window). - </para> - </blockquote> - <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> - </sect3> - </sect2> -<!-- - <sect2 id="click-to-play"> - <title>Click-to-play for plugins and invasive content</title> - <para> -Some content types are too invasive and/or too opaque for us to properly -eliminate their linkability properties. For these content types, we use -NoScript to provide click-to-play placeholders that do not activate the -content until the user clicks on it. This will eliminate the ability for an -adversary to use such content types to link users in a dragnet fashion across -arbitrary sites. - </para> - <para> -Currently, the content types isolated in this way include Flash, WebGL, and -audio and video objects. - </para> - </sect2> ---> - <sect2 id="other-security"> - <title>Other Security Measures</title> - <para> - -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 -privacy and security issues. - - </para> - <orderedlist> - <listitem id="traffic-fingerprinting-defenses"><command>Website Traffic Fingerprinting Defenses</command> - <para> - -<link linkend="website-traffic-fingerprinting">Website Traffic -Fingerprinting</link> is a statistical attack to attempt to recognize specific -encrypted website activity. - - </para> - <sect3> - <title>Design Goal:</title> - <blockquote> - <para> - -We want to deploy a mechanism that reduces the accuracy of <ulink -url="https://en.wikipedia.org/wiki/Feature_selection%22%3Euseful features</ulink> available -for classification. This mechanism would either impact the true and false -positive accuracy rates, <emphasis>or</emphasis> reduce the number of webpages -that could be classified at a given accuracy rate. - - </para> - <para> - -Ideally, this mechanism would be as light-weight as possible, and would be -tunable in terms of overhead. We suspect that it may even be possible to -deploy a mechanism that reduces feature extraction resolution without any -network overhead. In the no-overhead category, we have <ulink -url="http://freehaven.net/anonbib/cache/LZCLCP_NDSS11.pdf%22%3EHTTPOS</ulink> and -<ulink -url="https://blog.torproject.org/blog/experimental-defense-website-traffic-finger... -use of HTTP pipelining and/or SPDY</ulink>. -In the tunable/low-overhead -category, we have <ulink -url="http://freehaven.net/anonbib/cache/ShWa-Timing06.pdf%22%3EAdaptive -Padding</ulink> and <ulink url="http://www.cs.sunysb.edu/~xcai/fp.pdf"> -Congestion-Sensitive BUFLO</ulink>. It may be also possible to <ulink -url="https://trac.torproject.org/projects/tor/ticket/7028%22%3Etune such -defenses</ulink> such that they only use existing spare Guard bandwidth capacity in the Tor -network, making them also effectively no-overhead. - - </para> - </blockquote> - </sect3> - <sect3> - <title>Implementation Status:</title> - <blockquote> - <para> -Currently, we patch Firefox to <ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... -pipeline order and depth</ulink>. Unfortunately, pipelining is very fragile. -Many sites do not support it, and even sites that advertise support for -pipelining may simply return error codes for successive requests, effectively -forcing the browser into non-pipelined behavior. Firefox also has code to back -off and reduce or eliminate the pipeline if this happens. These -shortcomings and fallback behaviors are the primary reason that Google -developed SPDY as opposed simply extending HTTP to improve pipelining. It -turns out that we could actually deploy exit-side proxies that allow us to -<ulink -url="https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/ideas/xxx-usi... -SPDY from the client to the exit node</ulink>. This would make our defense not -only free, but one that actually <emphasis>improves</emphasis> performance. - - </para> - <para> - -Knowing this, we created this defense as an <ulink -url="https://blog.torproject.org/blog/experimental-defense-website-traffic-finger... -research prototype</ulink> to help evaluate what could be done in the best -case with full server support. Unfortunately, the bias in favor of compelling -attack papers has caused academia to ignore this request thus far, instead -publishing only cursory (yet "devastating") evaluations that fail to provide -even simple statistics such as the rates of actual pipeline utilization during -their evaluations, in addition to the other shortcomings and shortcuts <link -linkend="website-traffic-fingerprinting">mentioned earlier</link>. We can -accept that our defense might fail to work as well as others (in fact we -expect it), but unfortunately the very same shortcuts that provide excellent -attack results also allow the conclusion that all defenses are broken forever. -So sadly, we are still left in the dark on this point. - - </para> - </blockquote> - </sect3> - </listitem> - <listitem><command>Privacy-preserving update notification</command> - <para> - -In order to inform the user when their Tor Browser is out of date, we perform a -privacy-preserving update check asynchronously in the background. The -check uses Tor to download the file <ulink -url="https://check.torproject.org/RecommendedTBBVersions%22%3Ehttps://check.torpr...</ulink> -and searches that version list for the current value for the local preference -<command>torbrowser.version</command>. If the value from our preference is -present in the recommended version list, the check is considered to have -succeeded and the user is up to date. If not, it is considered to have failed -and an update is needed. The check is triggered upon browser launch, new -window, and new tab, but is rate limited so as to happen no more frequently -than once every 1.5 hours. - - </para> - <para> - -If the check fails, we cache this fact, and update the Torbutton graphic to -display a flashing warning icon and insert a menu option that provides a link -to our download page. Additionally, we reset the value for the browser -homepage to point to a <ulink -url="https://check.torproject.org/?lang=en-US&small=1&uptodate=0%22%3Epag... that -informs the user</ulink> that their browser is out of -date. - - </para> - </listitem> - - </orderedlist> - </sect2> - <sect2 id="firefox-patches"> - <title>Description of Firefox Patches</title> - <para> - -The set of patches we have against Firefox can be found in the <ulink -url="https://gitweb.torproject.org/torbrowser.git/tree/maint-2.4:/src/current-pat... directory of the torbrowser git repository</ulink>. They are: - - </para> - <orderedlist> - <listitem><ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... -Components.interfaces</ulink> - <para> - -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. - - </para> - </listitem> - <listitem><ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... -Permissions Manager memory only</ulink> - <para> - -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 <ulink -url="https://secure.wikimedia.org/wikipedia/en/wiki/HTTP_Strict_Transport_Securit...</ulink> -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. - - </para> - </listitem> - <listitem><ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... -Intermediate Cert Store memory-only</ulink> - <para> - -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. - - </para> - <!-- FIXME: Should this be a <note> tag too? --> - <para><command>Design Goal:</command> - -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. - - </para> - </listitem> - <listitem><ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... -a string-based cacheKey property for domain isolation</ulink> - <para> - -To <ulink -url="https://trac.torproject.org/projects/tor/ticket/3666%22%3Eincrease the -security of cache isolation</ulink> and to <ulink -url="https://trac.torproject.org/projects/tor/ticket/3754%22%3Esolve strange and -unknown conflicts with OCSP</ulink>, we had to patch -Firefox to provide a cacheDomain cache attribute. We use the url bar -FQDN as input to this field. - - </para> - </listitem> - <listitem><ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... -all plugins except flash</ulink> - <para> -We cannot use the <ulink -url="http://www.oxymoronical.com/experiments/xpcomref/applications/Firefox/3.5/co... -@mozilla.org/extensions/blocklist;1</ulink> 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. - </para> - </listitem> - <listitem><ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... content-prefs service memory only</ulink> - <para> -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?). - </para> - </listitem> - <listitem><ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... Tor Browser exit when not launched from Vidalia</ulink> - <para> - -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. - - </para> - </listitem> - <listitem><ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... SSL Session ID tracking</ulink> - <para> - -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. - - </para> - </listitem> - <listitem><ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... an observer event to close persistent connections</ulink> - <para> - -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 <link linkend="new-identity">New Identity</link> button. - - </para> - </listitem> - <listitem><ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... Device and System Specific Media Queries</ulink> - <para> - -<ulink url="https://developer.mozilla.org/en-US/docs/CSS/Media_queries">CSS -Media Queries</ulink> 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. - - </para> - </listitem> - <listitem><ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... the number of fonts per document</ulink> - <para> - -Font availability can be <ulink url="http://flippingtypical.com/">queried by -CSS and Javascript</ulink> 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. - - </para> - </listitem> - <listitem><ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... Firefox to Tor Browser</ulink> - <para> - -This patch updates our branding in compliance with Mozilla's trademark policy. - - </para> - </listitem> - <listitem><ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... Download Manager Memory Only</ulink> - <para> - -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. - - </para> - </listitem> - <listitem><ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... DDG and StartPage to Omnibox</ulink> - <para> - -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. - - </para> - </listitem> - <listitem><ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... nsICacheService.EvictEntries() Synchronous</ulink> - <para> - -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. - - </para> - </listitem> - <listitem><ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... WebSockets DNS Leak</ulink> - <para> - -This patch prevents a DNS leak when using WebSockets. It also prevents other -similar types of DNS leaks. - - </para> - </listitem> - <listitem><ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... HTTP pipeline order and depth</ulink> - <para> -As an -<ulink -url="https://blog.torproject.org/blog/experimental-defense-website-traffic-finger... -defense against Website Traffic Fingerprinting</ulink>, we patch the standard -HTTP pipelining code to randomize the number of requests in a -pipeline, as well as their order. - </para> - </listitem> - <listitem><ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... -an observer event to filter the Drag and Drop URL list</ulink> - <para> - -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. - - </para> - </listitem> - <listitem><ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... mozIThirdPartyUtil.getFirstPartyURI() API</ulink> - <para> - -This patch provides an API that allows us to more easily isolate identifiers -to the URL bar domain. - - </para> - </listitem> - <listitem><ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... canvas image extraction prompt</ulink> - <para> - -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. - - </para> - </listitem> - <listitem><ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... client window coordinates for mouse events</ulink> - <para> - -This patch causes mouse events to return coordinates relative to the content -window instead of the desktop. - - </para> - </listitem> - <listitem><ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... not expose physical screen info to window.screen</ulink> - <para> - -This patch causes window.screen to return the display resolution size of the -content window instead of the desktop resolution size. - - </para> - </listitem> - <listitem><ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... not expose system colors to CSS or canvas</ulink> - <para> - -This patch prevents CSS and Javascript from discovering your desktop color -scheme and/or theme. - - </para> - </listitem> - <listitem><ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... the Image Cache per url bar domain</ulink> - <para> - -This patch prevents cached images from being used to store third party tracking -identifiers. - - </para> - </listitem> - <listitem><ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat...) API</ulink> - <para> - -This patch provides HTTPS-Everywhere with an API to perform redirections more -securely and without addon conflicts. - - </para> - </listitem> - <listitem><ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... DOM Storage to first party URI</ulink> - <para> - -This patch prevents DOM Storage from being used to store third party tracking -identifiers. - - </para> - </listitem> - - <listitem><ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pat... -"This plugin is disabled" barrier</ulink> - - <para> - -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. - - </para> - </listitem> - - </orderedlist> - </sect2> - -</sect1> - -<!-- -- Packaging - - Build Process Security - - External Addons - - Included - - HTTPS-E - - NoScript - - Torbutton - - Deliberately excluded - - Request Policy, AdblockPlus, etc - - Desired - - Perspectives/Convergence/etc - - Pref Changes - - Caused by Torbutton - - Set manually in profile - - Update security - - Thandy - -<sect1 id="Packaging"> - <title>Packaging</title> - <para> </para> - <sect2 id="build-security"> - <title>Build Process Security</title> - <para> </para> - </sect2> - <sect2 id="addons"> - <title>External Addons</title> - <para> </para> - <sect3> - <title>Included Addons</title> - </sect3> - <sect3> - <title>Excluded Addons</title> - </sect3> - <sect3> - <title>Dangerous Addons</title> - </sect3> - </sect2> - <sect2 id="prefs"> - <title>Pref Changes</title> - <para> </para> - </sect2> - <sect2 id="update-mechanism"> - <title>Update Security</title> - <para> </para> - </sect2> -</sect1> ---> - -<!-- -<sect1 id="Testing"> - <title>Testing</title> - <para> - -The purpose of this section is to cover all the known ways that Tor browser -security can be subverted from a penetration testing perspective. The hope -is that it will be useful both for creating a &quot;Tor Safety Check&quot; -page, and for developing novel tests and actively attacking Torbutton with the -goal of finding vulnerabilities in either it or the Mozilla components, -interfaces and settings upon which it relies. - - </para> - <sect2 id="SingleStateTesting"> - <title>Single state testing</title> - <para> - -Torbutton is a complicated piece of software. During development, changes to -one component can affect a whole slough of unrelated features. A number of -aggregated test suites exist that can be used to test for regressions in -Torbutton and to help aid in the development of Torbutton-like addons and -other privacy modifications of other browsers. Some of these test suites exist -as a single automated page, while others are a series of pages you must visit -individually. They are provided here for reference and future regression -testing, and also in the hope that some brave soul will one day decide to -combine them into a comprehensive automated test suite. - - <orderedlist> - <listitem><ulink url="http://decloak.net/">Decloak.net</ulink> - <para> - -Decloak.net is the canonical source of plugin and external-application based -proxy-bypass exploits. It is a fully automated test suite maintained by <ulink -url="http://digitaloffense.net/%22%3EHD Moore</ulink> as a service for people to -use to test their anonymity systems. - - </para> - </listitem> - <listitem><ulink url="http://deanonymizer.com/">Deanonymizer.com</ulink> - <para> - -Deanonymizer.com is another automated test suite that tests for proxy bypass -and other information disclosure vulnerabilities. It is maintained by Kyle -Williams, the author of <ulink url="http://www.janusvm.com/">JanusVM</ulink> -and <ulink url="http://www.januspa.com/">JanusPA</ulink>. - - </para> - </listitem> - <listitem><ulink url="https://ip-check.info">JonDos -AnonTest</ulink> - <para> - -The <ulink url="https://anonymous-proxy-servers.net/">JonDos people</ulink> also provide an -anonymity tester. It is more focused on HTTP headers and behaviors than plugin bypass, and -points out a couple of headers Torbutton could do a better job with -obfuscating. - - </para> - </listitem> - <listitem><ulink url="http://browserspy.dk">Browserspy.dk</ulink> - <para> - -Browserspy.dk provides a tremendous collection of browser fingerprinting and -general privacy tests. Unfortunately they are only available one page at a -time, and there is not really solid feedback on good vs bad behavior in -the test results. - - </para> - </listitem> - <listitem><ulink url="http://analyze.privacy.net/">Privacy -Analyzer</ulink> - <para> - -The Privacy Analyzer provides a dump of all sorts of browser attributes and -settings that it detects, including some information on your original IP -address. Its page layout and lack of good vs bad test result feedback makes it -not as useful as a user-facing testing tool, but it does provide some -interesting checks in a single page. - - </para> - </listitem> - <listitem><ulink url="http://ha.ckers.org/mr-t/">Mr. T</ulink> - <para> - -Mr. T is a collection of browser fingerprinting and deanonymization exploits -discovered by the <ulink url="http://ha.ckers.org">ha.ckers.org</ulink> crew -and others. It is also not as user friendly as some of the above tests, but it -is a useful collection. - - </para> - </listitem> - <listitem>Gregory Fleischer's <ulink -url="http://pseudo-flaw.net/content/tor/torbutton/%22%3ETorbutton</ulink> and -<ulink -url="http://pseudo-flaw.net/content/defcon/dc-17-demos/d.html%22%3EDefcon -17</ulink> Test Cases - <para> - -Gregory Fleischer has been hacking and testing Firefox and Torbutton privacy -issues for the past 2 years. He has an excellent collection of all his test -cases that can be used for regression testing. In his Defcon work, he -demonstrates ways to infer Firefox version based on arcane browser properties. -We are still trying to determine the best way to address some of those test -cases. - - </para> - </listitem> - <listitem><ulink url="https://torcheck.xenobite.eu/index.php">Xenobite's -TorCheck Page</ulink> - <para> - -This page checks to ensure you are using a valid Tor exit node and checks for -some basic browser properties related to privacy. It is not very fine-grained -or complete, but it is automated and could be turned into something useful -with a bit of work. - - </para> - </listitem> - </orderedlist> - </para> - </sect2> ---> -<!-- - <sect2> - <title>Multi-state testing</title> - <para> - -The tests in this section are geared towards a page that would instruct the -user to toggle their Tor state after the fetch and perform some operations: -mouseovers, stray clicks, and potentially reloads. - - </para> - <sect3> - <title>Cookies and Cache Correlation</title> - <para> -The most obvious test is to set a cookie, ask the user to toggle tor, and then -have them reload the page. The cookie should no longer be set if they are -using the default Torbutton settings. In addition, it is possible to leverage -the cache to <ulink -url="http://crypto.stanford.edu/sameorigin/safecachetest.html%22%3Estore unique -identifiers</ulink>. The default settings of Torbutton should also protect -against these from persisting across Tor Toggle. - - </para> - </sect3> - <sect3> - <title>Javascript timers and event handlers</title> - <para> - -Javascript can set timers and register event handlers in the hopes of fetching -URLs after the user has toggled Torbutton. - </para> - </sect3> - <sect3> - <title>CSS Popups and non-script Dynamic Content</title> - <para> - -Even if Javascript is disabled, CSS is still able to -<ulink url="http://www.tjkdesign.com/articles/css%20pop%20ups/">create popup-like -windows</ulink> -via the 'onmouseover' CSS attribute, which can cause arbitrary browser -activity as soon as the mouse enters into the content window. It is also -possible for meta-refresh tags to set timers long enough to make it likely -that the user has toggled Tor before fetching content. - - </para> - </sect3> - </sect2> - <sect2 id="HackTorbutton"> - <title>Active testing (aka How to Hack Torbutton)</title> - <para> - -The idea behind active testing is to discover vulnerabilities in Torbutton to -bypass proxy settings, run script in an opposite Tor state, store unique -identifiers, leak location information, or otherwise violate <link -linkend="requirements">its requirements</link>. Torbutton has ventured out -into a strange and new security landscape. It depends on Firefox mechanisms -that haven't necessarily been audited for security, certainly not for the -threat model that Torbutton seeks to address. As such, it and the interfaces -it depends upon still need a 'trial by fire' typical of new technologies. This -section of the document was written with the intention of making that period -as fast as possible. Please help us get through this period by considering -these attacks, playing with them, and reporting what you find (and potentially -submitting the test cases back to be run in the standard batch of Torbutton -tests. - - </para> - <sect3> - <title>Some suggested vectors to investigate</title> - <para> - <itemizedlist> - <listitem>Strange ways to register Javascript <ulink -url="http://en.wikipedia.org/wiki/DOM_Events%22%3Eevents</ulink> and <ulink -url="http://www.devshed.com/c/a/JavaScript/Using-Timers-in-JavaScript/%22%3Etimeo...</ulink> should -be verified to actually be ineffective after Tor has been toggled.</listitem> - <listitem>Other ways to cause Javascript to be executed after -<command>javascript.enabled</command> has been toggled off.</listitem> - <listitem>Odd ways to attempt to load plugins. Kyle Williams has had -some success with direct loads/meta-refreshes of plugin-handled URLs.</listitem> - <listitem>The Date and Timezone hooks should be verified to work with -crazy combinations of iframes, nested iframes, iframes in frames, frames in -iframes, and popups being loaded and -reloaded in rapid succession, and/or from one another. Think race conditions and deep, -parallel nesting, involving iframes from both <ulink -url="http://en.wikipedia.org/wiki/Same_origin_policy%22%3Esame-origin and -non-same-origin</ulink> domains.</listitem> - <listitem>In addition, there may be alternate ways and other -methods to query the timezone, or otherwise use some of the Date object's -methods in combination to deduce the timezone offset. Of course, the author -tried his best to cover all the methods he could foresee, but it's always good -to have another set of eyes try it out.</listitem> - <listitem>Similarly, is there any way to confuse the <link -linkend="contentpolicy">content policy</link> -mentioned above to cause it to allow certain types of page fetches? For -example, it was recently discovered that favicons are not fetched by the -content, but the chrome itself, hence the content policy did not look up the -correct window to determine the current Tor tag for the favicon fetch. Are -there other things that can do this? Popups? Bookmarklets? Active bookmarks? </listitem> - <listitem>Alternate ways to store and fetch unique identifiers. For example, <ulink -url="http://developer.mozilla.org/en/docs/DOM:Storage%22%3EDOM Storage</ulink> -caught us off guard. -It was -also discovered by <ulink url="http://pseudo-flaw.net">Gregory -Fleischer</ulink> that <ulink -url="http://pseudo-flaw.net/content/tor/torbutton/%22%3Econtent window access to -chrome</ulink> can be used to build <link linkend="fingerprinting">unique -identifiers</link>. -Are there any other -arcane or experimental ways that Firefox provides to create and store unique -identifiers? Or perhaps unique identifiers can be queried or derived from -properties of the machine/browser that Javascript has access to? How unique -can these identifiers be? - </listitem> - <listitem>Is it possible to get the browser to write some history to disk -(aside from swap) that can be retrieved later? By default, Torbutton should -write no history, cookie, or other browsing activity information to the -harddisk.</listitem> - <listitem>Do popup windows make it easier to break any of the above -behavior? Are javascript events still canceled in popups? What about recursive -popups from Javascript, data, and other funky URL types? What about CSS -popups? Are they still blocked after Tor is toggled?</listitem> - <listitem>Chrome-escalation attacks. The interaction between the -Torbutton chrome Javascript and the client content window javascript is pretty -well-defined and carefully constructed, but perhaps there is a way to smuggle -javascript back in a return value, or otherwise inject network-loaded -javascript into the chrome (and thus gain complete control of the browser). -</listitem> -</itemizedlist> - - </para> - </sect3> - </sect2> -</sect1> ---> -<appendix id="Transparency"> -<title>Towards Transparency in Navigation Tracking</title> -<para> - -The <link linkend="privacy">privacy properties</link> of Tor Browser are based -upon the assumption that link-click navigation indicates user consent to -tracking between the linking site and the destination site. While this -definition is sufficient to allow us to eliminate cross-site third party -tracking with only minimal site breakage, it is our long-term goal to further -reduce cross-origin click navigation tracking to mechanisms that are -detectable by attentive users, so they can alert the general public if -cross-origin click navigation tracking is happening where it should not be. - -</para> -<para> - -In an ideal world, the mechanisms of tracking that can be employed during a -link click would be limited to the contents of URL parameters and other -properties that are fully visible to the user before they click. However, the -entrenched nature of certain archaic web features make it impossible for us to -achieve this transparency goal by ourselves without substantial site breakage. -So, instead we maintain a <link linkend="deprecate">Deprecation -Wishlist</link> of archaic web technologies that are currently being (ab)used -to facilitate federated login and other legitimate click-driven cross-domain -activity but that can one day be replaced with more privacy friendly, -auditable alternatives. - -</para> -<para> - -Because the total elimination of side channels during cross-origin navigation -will undoubtedly break federated login as well as destroy ad revenue, we -also describe auditable alternatives and promising web draft standards that would -preserve this functionality while still providing transparency when tracking is -occurring. - -</para> - -<sect1 id="deprecate"> - <title>Deprecation Wishlist</title> - <orderedlist> - <listitem>The Referer Header - <para> - -We haven't disabled or restricted the Referer ourselves because of the -non-trivial number of sites that rely on the Referer header to "authenticate" -image requests and deep-link navigation on their sites. Furthermore, there -seems to be no real privacy benefit to taking this action by itself in a -vacuum, because many sites have begun encoding Referer URL information into -GET parameters when they need it to cross http to https scheme transitions. -Google's +1 buttons are the best example of this activity. - - </para> - <para> - -Because of the availability of these other explicit vectors, we believe the -main risk of the Referer header is through inadvertent and/or covert data -leakage. In fact, <ulink -url="http://www2.research.att.com/~bala/papers/wosn09.pdf%22%3Ea great deal of -personal data</ulink> is inadvertently leaked to third parties through the -source URL parameters. - - </para> - <para> - -We believe the Referer header should be made explicit. If a site wishes to -transmit its URL to third party content elements during load or during -link-click, it should have to specify this as a property of the associated HTML -tag. With an explicit property, it would then be possible for the user agent to -inform the user if they are about to click on a link that will transmit Referer -information (perhaps through something as subtle as a different color in the -lower toolbar for the destination URL). This same UI notification can also be -used for links with the <ulink -url="https://developer.mozilla.org/en-US/docs/HTML/Element/a#Attributes%22%3E%22p..."</ulink> -attribute. - - </para> - </listitem> - <listitem>window.name - <para> -<ulink -url="https://developer.mozilla.org/En/DOM/Window.name%22%3Ewindow.name</ulink> is -a DOM property that for some reason is allowed to retain a persistent value -for the lifespan of a browser tab. It is possible to utilize this property for -<ulink url="http://www.thomasfrank.se/sessionvars.html">identifier -storage</ulink> during click navigation. This is sometimes used for additional -XSRF protection and federated login. - </para> - <para> - -It's our opinion that the contents of window.name should not be preserved for -cross-origin navigation, but doing so may break federated login for some sites. - - </para> - </listitem> - <listitem>Javascript link rewriting - <para> - -In general, it should not be possible for onclick handlers to alter the -navigation destination of 'a' tags, silently transform them into POST -requests, or otherwise create situations where a user believes they are -clicking on a link leading to one URL that ends up on another. This -functionality is deceptive and is frequently a vector for malware and phishing -attacks. Unfortunately, many legitimate sites also employ such transparent -link rewriting, and blanket disabling this functionality ourselves will simply -cause Tor Browser to fail to navigate properly on these sites. - - </para> - <para> - -Automated cross-origin redirects are one form of this behavior that is -possible for us to <ulink -url="https://trac.torproject.org/projects/tor/ticket/3600%22%3Eaddress -ourselves</ulink>, as they are comparatively rare and can be handled with site -permissions. - - </para> - </listitem> - </orderedlist> -</sect1> -<sect1> - <title>Promising Standards</title> - <orderedlist> - <listitem><ulink url="http://web-send.org">Web-Send Introducer</ulink> - <para> - -Web-Send is a browser-based link sharing and federated login widget that is -designed to operate without relying on third-party tracking or abusing other -cross-origin link-click side channels. It has a compelling list of <ulink -url="http://web-send.org/features.html%22%3Eprivacy and security features</ulink>, -especially if used as a "Like button" replacement. - - </para> - </listitem> - <listitem><ulink url="https://developer.mozilla.org/en-US/docs/Persona">Mozilla Persona</ulink> - <para> - -Mozilla's Persona is designed to provide decentralized, cryptographically -authenticated federated login in a way that does not expose the user to third -party tracking or require browser redirects or side channels. While it does -not directly provide the link sharing capabilities that Web-Send does, it is a -better solution to the privacy issues associated with federated login than -Web-Send is. - - </para> - </listitem> - </orderedlist> -</sect1> -</appendix> -</article> diff --git a/docs/design/outline.txt b/docs/design/outline.txt deleted file mode 100644 index f7aa5ec..0000000 --- a/docs/design/outline.txt +++ /dev/null @@ -1,52 +0,0 @@ -- Threat model: [Mostly Torbutton] - - [Remove the security requirements section] - -- Design overview and philosophy - - Security requirements [Torbutton] - + local leaks? - - state issues - - Privacy Requirements [Mostly blog post] - - Make local privacy optional - - Avoid Cross-Domain Linkability - - Indentifiers - - Fingerprinting - - 100% self-contained - - Does not share state with other modes/browsers - - Easy to remove + wipe with external tools - - No filters - -- Implementation - - Section Template - - Sub Section - - "Design Goal": - - "Implementation Status" - - Local Privacy Optional - - Linkability - - Stored State - - Cookies - - Cache - - DOM Storage - - HTTP Auth - - SSL state - - Plugins - - Fingerprinting - - Patches - -- Packaging - - Build Process Security - - External Addons - - Included - - HTTPS-E - - NoScript - - Torbutton - - Deliberately excluded - - Request Policy, AdblockPlus, etc - - Desired - - Perspectives/Convergence/etc - - Pref Changes - - Caused by Torbutton - - Set manually in profile - - Update security - - Thandy - -