commit 2f46060e4832e714676a33c404cfe1505070b685 Author: Mike Perry <mikeperry-git@fscked.org> Date: Tue Sep 27 00:25:21 2011 -0700 Add intro + fill in fingerprinting section a bit. Also random cleanups. --- docs/design/design.xml | 225 +++++++++++++++++++++++++++++++++++++----------- 1 file changed, 173 insertions(+), 52 deletions(-) diff --git a/docs/design/design.xml b/docs/design/design.xml index 2fd3dc0..e3870e6 100644 --- a/docs/design/design.xml +++ b/docs/design/design.xml @@ -35,10 +35,19 @@ <title>Introduction</title> <para> -<!-- XXX: intro + version -This document describes the goals, operation, and testing procedures of the -Torbutton Firefox extension. It is current as of Tor Browser 2.2.32-4. ---> +This document describes the <link linkend="adversary">adversary model</link>, +<link linkend="DesignRequirements">design requirements</link>, +<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.2.32-4. + + </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 both local and network adversaries. </para> <sect2 id="adversary"> @@ -47,7 +56,7 @@ Torbutton Firefox extension. It is current as of Tor Browser 2.2.32-4. A Tor web browser adversary has a number of goals, capabilities, and attack types that can be used to guide us towards a set of requirements for the -Torbutton extension. Let's start with the goals. +Tor Browser. Let's start with the goals. </para> <sect3 id="adversarygoals"> @@ -296,12 +305,16 @@ size of toolbars. <listitem><command>Remotely or locally exploit browser and/or OS</command> <para> -Last, but definitely not least, the adversary can exploit either general + +Last, but definitely not least, the adversary can exploit either general browser vulnerabilities, plugin vulnerabilities, or OS vulnerabilities to install malware and surveillance software. An adversary with physical access can perform similar actions. Regrettably, this last attack capability is -outside of Torbutton's ability to defend against, but it is worth mentioning -for completeness. +outside of our ability to defend against, but it is worth mentioning for +completeness. <ulink url="http://tails.boum.org/contribute/design/">The Tails +system</ulink> however can provide some limited defenses against this +adversary. + </para> </listitem> </orderedlist> @@ -331,18 +344,19 @@ for completeness. <title>Design Requirements and Philosophy</title> <para> -The Tor Browser is meant to serve as a specification and a reference -implementation of a Private Browsing Mode that defends against both Network -and Local Adversaries. +The Tor Browser Design Requirements are meant to describe the properties of a +Private Browsing Mode that defends against both network and local adversaries. </para> <para> -There are two main categories of requirements: Security Requirements, and -Privacy Requirements. Security Requirements are the minimum properties in -order for a web client platform to be able to support Tor. Privacy -requirements are the set of properties that cause us to prefer one platform -over another. +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 web client platform to be able to support +Tor. Privacy requirements are the set of properties that cause us to prefer +one platform over another. + </para> <para> @@ -378,10 +392,10 @@ in memory beyond the duration of one Tor session, unless the user has explicitly opted to store their browsing history information to disk.</para></listitem> - <listitem><command>Application Data Isolation</command><para>The Tor -components of the browser MUST NOT write or cause the Operating System to + <listitem><command>Application Data Isolation</command><para>The browser +MUST NOT write or cause the operating system to write <emphasis>any information</emphasis> to disk outside of the application -directory. All exceptions and shortcomings due to Operating System behavior +directory. All exceptions and shortcomings due to operating system behavior MUST BE documented. </para></listitem> @@ -423,7 +437,7 @@ linkability from fingerprinting browser behavior. <listitem><command>Long-Term Unlinkability</command> <para> -Users SHOULD have an obvious, easy way to remove all of their authentication +The browser SHOULD provide an obvious, easy way to remove all of their authentication tokens and browser state and obtain a fresh identity. Additionally, this should happen by default automatically upon browser restart. @@ -463,7 +477,8 @@ tor-state of the browser. </para> </listitem> - <listitem><command>Minimal breakage to support requirements</command> + <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 @@ -473,19 +488,23 @@ site breakage, though this is not always possible. </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 can't be induced to bypass them (which all of them can), the +them do) and could not be induced to bypass them (which all of them can), the activies of closed-source plugins are very difficult to audit and control. -They can obtain and transmit all manner of system information to websites, and -often have their own identifier storage for tracking users. +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 decides to craft an exemption, it MUST ONLY apply to -the top level urlbar domain, and not to all sites, to reduce linkability. +can execute. If the user decides to craft an exemption to allow a plugin to be +used, it MUST ONLY apply to the top level urlbar domain, and not to all sites, +to reduce linkability. </para> </listitem> @@ -494,11 +513,11 @@ the top level urlbar domain, and not to all sites, to reduce linkability. <ulink url="https://trac.torproject.org/projects/tor/ticket/3100">Another failure of Torbutton</ulink> was (and still is) the options panel. Each option -that detectably alters browser behavior can be used as a fingerprinting tool -on the part of ad networks. Similarly, all extensions <ulink +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">should be disabled in the mode</ulink> except as an opt-in basis. We should not load -system addons or plugins. +system-wide addons or plugins. </para> <para> @@ -516,24 +535,41 @@ privacy permissions. If the user has indicated they do not care about local history storage, these permissions can be written to disk. Otherwise, they should remain memory-only. </para> - </para> - </listitem> - <para> - </para> </listitem> <listitem><command>No filters</command> <para> -<!-- XXX: Might want to briefly explain why --> -We don't need no stinking filters. +Filter-based addons such as <ulink +url="https://addons.mozilla.org/en-US/firefox/addon/adblock-plus/">AdBlock Plus</ulink>, <ulink +url="">Request Policy</ulink>, <ulink url="http://priv3.icsi.berkeley.edu/">Priv3</ulink>, and <ulink +url="http://sharemenot.cs.washington.edu/">Sharemenot</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>, as all third parties are prevented from +tracking users between sites by the implementation. Furthermore, filter-based +addons can 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. </para> + <para> +Furthermore, we are generally opposed to shipping an always-on Ad blocker with +Tor Browser. We feel that this would damage our credibility in terms of +demonstrating that we are providing privacy through a sound design alone, as +well as damage the acceptance of Tor users by sites who support themselves +through advertizing 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 realization. However, we will likely disable +their proper deployment or privacy realization. However, we will likely disable certain new features (where possible) pending analysis and audit. </para> </listitem> @@ -627,18 +663,18 @@ Flash cookies from leaking from a pre-existing Flash directory. <title>Disk Avoidance</title> <sect3> <title>Design Goal:</title> - <para> + <blockquote> Tor Browser should optionally prevent all disk records of browser activity. The user should be able to optionally enable URL history and other history features if they so desire. Once we <ulink url="https://trac.torproject.org/projects/tor/ticket/3100">simplify the preferences interface</ulink>, we will likely just enable Private Browsing mode by default to handle this goal. - </para> + </blockquote> </sect3> <sect3> <title>Implementation Status:</title> - <para> + <blockquote> For now, Tor Browser blocks write access to the disk through Torbutton using several Firefox preferences. @@ -655,9 +691,9 @@ The set of prefs is: <command>places.history.enabled</command>, <command>browser.formfill.enable</command>, <command>signon.rememberSignons</command>, -<command>browser.download.manager.retention <!-- XXX: needs patch --></command>, +<command>browser.download.manager.retention</command>, and <command>network.cookie.lifetimePolicy</command>. - </para> + </blockquote> </sect3> <para> In addition, three Firefox patches are needed to prevent disk writes, even if @@ -696,6 +732,7 @@ and/or what additional work or auditing needs to be done. <title>Update Safety</title> <para> <!-- XXX: Design goal vs implementation status --> +XXX: Write me.. </para> </sect2> <sect2 id="identifier-linkability"> @@ -706,7 +743,7 @@ and/or what additional work or auditing needs to be done. 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 -design goal is to ultimately eliminate the need to disable arbitrary +<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 @@ -813,6 +850,26 @@ domain, we entirely disable DOM storage as a stopgap to ensure unlinkability. </para> </listitem> + <listitem>TLS session resumption and HTTP Keep-Alive + <para> +TLS session resumption and HTTP Keep-Alive must not allow third party origins +to track users via either TLS session IDs, or the fact that different requests +arrive on the same TCP connection. + </para> + <para><command>Design Goal:</command> + +TLS session resumption IDs must be limited to the top-level url bar domain. +HTTP Keep-Alive connections from a third party in one top-level domain must +not be reused for that same third party in another top-level domain. + + </para> + <para><command>Implementation Status:</command> + +We <ulink url="https://trac.torproject.org/projects/tor/ticket/4099">plan to +disable</ulink> TLS session resumption, and limit HTTP Keep-alive duration. + + </para> + </listitem> <listitem>window.name <para> @@ -857,23 +914,84 @@ functionality. <sect2 id="fingerprinting-linkability"> <title>Cross-Domain Fingerprinting Unlinkability</title> <para> + +In order to properly address the network adversary on a technical level, we +need a metric to measure linkability of the various browser properties that +extend beyond any stored origin-related state. <ulink +url="https://panopticlick.eff.org/about.php">The Panopticlick Project</ulink> +by the EFF provides us with exactly this metric. The researchers conducted a +survey of volunteers who were asked to visit an experiment page that harvested +many of the above compo- nents. 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> + +The study is not exhaustive, though. In particular, the test does not take in +all aspects of resolution information. It did not calculate the size of +widgets, window decoration, or toolbar size. We believe this may add high +amounts of entropy to the screen field. It also did not measure clock offset +and other time-based fingerprints. Furthermore, as new browser features are +added, this experiment should be repeated to include them. + + </para> + <para> + +On the other hand, to avoid an infinite sinkhole, we reduce the efforts for +fingerprinting resistence by only concerning ourselves with reducing the +fingerprintable differences <emphasis>among</emphasis> Tor Browser users. We +do not believe it is productive to concern ourselves with cross-browser +fingerprinting issues, at least not at this stage. + </para> - <!-- XXX: Panopticlick set + others --> <orderedlist> - <listitem>Desktop resolution - <para> + <listitem>Plugins + <para><command>Design Goal:</command> + </para> + <para><command>Implementation Status:</command> + </para> + </listitem> + <listitem>Fonts + <para><command>Design Goal:</command> + </para> + <para><command>Implementation Status:</command> + </para> + </listitem> + <listitem>User Agent and HTTP Headers + <para><command>Design Goal:</command> + </para> + <para><command>Implementation Status:</command> + </para> + </listitem> + <listitem>Desktop resolution and CSS Media Queries + <para><command>Design Goal:</command> + </para> + <para><command>Implementation Status:</command> </para> </listitem> <listitem>Timezone and clock offset - <para> + <para><command>Design Goal:</command> + </para> + <para><command>Implementation Status:</command> </para> </listitem> - <listitem>WebGL - <para> + <listitem>Javascript performance fingerprinting + <para><command>Design Goal:</command> + </para> + <para><command>Implementation Status:</command> </para> </listitem> - <listitem>Fonts - <para> + <listitem>Keystroke fingerprinting + <para><command>Design Goal:</command> + </para> + <para><command>Implementation Status:</command> + </para> + </listitem> + <listitem>WebGL + <para><command>Design Goal:</command> + </para> + <para><command>Implementation Status:</command> </para> </listitem> </orderedlist> @@ -901,7 +1019,10 @@ a new circuit to be created. </para> <para> XXX: Cookie protections.. -XXX: Missing pieces: DOM Storage? +<!-- XXX: Missing pieces: + 1. DOM Storage? IIRC, it is cleared, but also disabled anyway. + 2. Do we kill keep-alive connections properly? + --> </para> </sect2> <sect2 id="click-to-play"> @@ -1082,7 +1203,7 @@ other site prefs?). </sect2> </sect1> -<sect1 id="TestPlan"> +<sect1 id="Testing"> <title>Testing</title> <para>