Author: mikeperry Date: 2011-10-05 05:48:34 +0000 (Wed, 05 Oct 2011) New Revision: 25149 Modified: website/trunk/projects/torbrowser/design/CookieManagers.png website/trunk/projects/torbrowser/design/index.html.en Log: Update TBB design doc with suggestions from Georg Koppen, pde, and Sid. Modified: website/trunk/projects/torbrowser/design/CookieManagers.png =================================================================== (Binary files differ) Modified: website/trunk/projects/torbrowser/design/index.html.en =================================================================== --- website/trunk/projects/torbrowser/design/index.html.en 2011-10-04 19:38:31 UTC (rev 25148) +++ website/trunk/projects/torbrowser/design/index.html.en 2011-10-05 05:48:34 UTC (rev 25149) @@ -1,18 +1,19 @@ <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> -<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>The Design and Implementation of the Tor Browser [DRAFT]</title><meta name="generator" content="DocBook XSL Stylesheets V1.75.2" /></head><body><div class="article" title="The Design and Implementation of the Tor Browser [DRAFT]"><div class="titlepage"><div><div><h2 class="title"><a id="design"></a>The Design and Implementation of the Tor Browser [DRAFT]</h2></div><div><div class="author"><h3 class="author"><span class="firstname">Mike</span> <span class="surname">Perry</span></h3><div class="affiliation"><div class="address"><p><code class="email"><<a class="email" href="mailto:mikeperry#torproject org">mikeperry#torproject org</a>></code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Erinn</span> <span class="surname">Clark</span></h3><div class="affiliation"><div class="address"><p><code class= "email"><<a class="email" href="mailto:erinn_torproject\org">erinn_torproject\org</a>></code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Steven</span> <span class="surname">Murdoch</span></h3><div class="affiliation"><div class="address"><p><code class="email"><<a class="email" href="mailto:sjmurdoch#torproject\org">sjmurdoch#torproject\org</a>></code></p></div></div></div></div><div><p class="pubdate">Sep 29 2011</p></div></div><hr /></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="#id2974058">1. Introduction</a></span></dt><dd><dl><dt><span class="sect2"><a href="#adversary">1.1. Adversary Model</a></span></dt></dl></dd><dt><span class="sect1"><a href="#DesignRequirements">2. Design Requirements and Philosophy</a></span></dt><dd><dl><dt><span class="sect2"><a href="#security">2.1. Security Requirements</a></span></dt><dt><span class="sect2"><a href="#privacy">2.2. Priv acy Requirements</a></span></dt><dt><span class="sect2"><a href="#philosophy">2.3. Philosophy</a></span></dt></dl></dd><dt><span class="sect1"><a href="#Implementation">3. Implementation</a></span></dt><dd><dl><dt><span class="sect2"><a href="#proxy-obedience">3.1. Proxy Obedience</a></span></dt><dt><span class="sect2"><a href="#state-separation">3.2. State Separation</a></span></dt><dt><span class="sect2"><a href="#disk-avoidance">3.3. Disk Avoidance</a></span></dt><dt><span class="sect2"><a href="#app-data-isolation">3.4. Application Data Isolation</a></span></dt><dt><span class="sect2"><a href="#identifier-linkability">3.5. Cross-Domain Identifier Unlinkability</a></span></dt><dt><span class="sect2"><a href="#fingerprinting-linkability">3.6. Cross-Domain Fingerprinting Unlinkability</a></span></dt><dt><span class="sect2"><a href="#new-identity">3.7. Long-Term Unlinkability via "New Identity" button</a></span></dt><dt><span class="sect2"><a href="#click-to-play">3.8. Click -to-play for plugins and invasive content</a></span></dt><dt><span class="sect2"><a href="#firefox-patches">3.9. Description of Firefox Patches</a></span></dt></dl></dd><dt><span class="sect1"><a href="#Packaging">4. Packaging</a></span></dt><dd><dl><dt><span class="sect2"><a href="#build-security">4.1. Build Process Security</a></span></dt><dt><span class="sect2"><a href="#addons">4.2. External Addons</a></span></dt><dt><span class="sect2"><a href="#prefs">4.3. Pref Changes</a></span></dt><dt><span class="sect2"><a href="#update-mechanism">4.4. Update Security</a></span></dt></dl></dd><dt><span class="sect1"><a href="#Testing">5. Testing</a></span></dt><dd><dl><dt><span class="sect2"><a href="#SingleStateTesting">5.1. Single state testing</a></span></dt></dl></dd></dl></div><div class="sect1" title="1. Introduction"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2974058"></a>1. Introduction</h2></div></div></div><p> +<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>The Design and Implementation of the Tor Browser [DRAFT]</title><meta name="generator" content="DocBook XSL Stylesheets V1.75.2" /></head><body><div class="article" title="The Design and Implementation of the Tor Browser [DRAFT]"><div class="titlepage"><div><div><h2 class="title"><a id="design"></a>The Design and Implementation of the Tor Browser [DRAFT]</h2></div><div><div class="author"><h3 class="author"><span class="firstname">Mike</span> <span class="surname">Perry</span></h3><div class="affiliation"><div class="address"><p><code class="email"><<a class="email" href="mailto:mikeperry#torproject org">mikeperry#torproject org</a>></code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Erinn</span> <span class="surname">Clark</span></h3><div class="affiliation"><div class="address"><p><code class= "email"><<a class="email" href="mailto:erinn#torproject org">erinn#torproject org</a>></code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Steven</span> <span class="surname">Murdoch</span></h3><div class="affiliation"><div class="address"><p><code class="email"><<a class="email" href="mailto:sjmurdoch#torproject org">sjmurdoch#torproject org</a>></code></p></div></div></div></div><div><p class="pubdate">Oct 4 2011</p></div></div><hr /></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="#id2748505">1. Introduction</a></span></dt><dd><dl><dt><span class="sect2"><a href="#adversary">1.1. Adversary Model</a></span></dt></dl></dd><dt><span class="sect1"><a href="#DesignRequirements">2. Design Requirements and Philosophy</a></span></dt><dd><dl><dt><span class="sect2"><a href="#security">2.1. Security Requirements</a></span></dt><dt><span class="sect2"><a href="#privacy">2.2. Pri vacy Requirements</a></span></dt><dt><span class="sect2"><a href="#philosophy">2.3. Philosophy</a></span></dt></dl></dd><dt><span class="sect1"><a href="#Implementation">3. Implementation</a></span></dt><dd><dl><dt><span class="sect2"><a href="#proxy-obedience">3.1. Proxy Obedience</a></span></dt><dt><span class="sect2"><a href="#state-separation">3.2. State Separation</a></span></dt><dt><span class="sect2"><a href="#disk-avoidance">3.3. Disk Avoidance</a></span></dt><dt><span class="sect2"><a href="#app-data-isolation">3.4. Application Data Isolation</a></span></dt><dt><span class="sect2"><a href="#identifier-linkability">3.5. Cross-Origin Identifier Unlinkability</a></span></dt><dt><span class="sect2"><a href="#fingerprinting-linkability">3.6. Cross-Origin Fingerprinting Unlinkability</a></span></dt><dt><span class="sect2"><a href="#new-identity">3.7. Long-Term Unlinkability via "New Identity" button</a></span></dt><dt><span class="sect2"><a href="#click-to-play">3.8. Clic k-to-play for plugins and invasive content</a></span></dt><dt><span class="sect2"><a href="#firefox-patches">3.9. Description of Firefox Patches</a></span></dt></dl></dd><dt><span class="sect1"><a href="#Packaging">4. Packaging</a></span></dt><dd><dl><dt><span class="sect2"><a href="#build-security">4.1. Build Process Security</a></span></dt><dt><span class="sect2"><a href="#addons">4.2. External Addons</a></span></dt><dt><span class="sect2"><a href="#prefs">4.3. Pref Changes</a></span></dt><dt><span class="sect2"><a href="#update-mechanism">4.4. Update Security</a></span></dt></dl></dd><dt><span class="sect1"><a href="#Testing">5. Testing</a></span></dt><dd><dl><dt><span class="sect2"><a href="#SingleStateTesting">5.1. Single state testing</a></span></dt></dl></dd></dl></div><div class="sect1" title="1. Introduction"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2748505"></a>1. Introduction</h2></div></div></div><p> This document describes the <a class="link" href="#adversary" title="1.1. Adversary Model">adversary model</a>, <a class="link" href="#DesignRequirements" title="2. Design Requirements and Philosophy">design requirements</a>, <a class="link" href="#Implementation" title="3. Implementation">implementation</a>, <a class="link" href="#Packaging" title="4. Packaging">packaging</a> and <a class="link" href="#Testing" title="5. Testing">testing procedures</a> of the Tor Browser. It is -current as of Tor Browser 2.2.32-4. +current as of Tor Browser 2.2.33-3. </p><p> 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. +against active network adversaries, in addition to the passive forensic local +adversary currently addressed by the major browsers. </p><div class="sect2" title="1.1. Adversary Model"><div class="titlepage"><div><div><h3 class="title"><a id="adversary"></a>1.1. Adversary Model</h3></div></div></div><p> @@ -83,82 +84,95 @@ correlate users' activity across different IP addresses, and still others are performed by malicious agents on the Tor network and at national firewalls. - </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><span class="command"><strong>Inserting Javascript</strong></span><p> -If not properly disabled, Javascript event handlers and timers -can cause the browser to perform network activity after Tor has been disabled, -thus allowing the adversary to correlate Tor and Non-Tor activity and reveal -a user's non-Tor IP address. Javascript -also allows the adversary to execute <a class="ulink" href="http://whattheinternetknowsaboutyou.com/" target="_top">history disclosure attacks</a>: -to query the history via the different attributes of 'visited' links to search -for particular Google queries, sites, or even to <a class="ulink" href="http://www.mikeonads.com/2008/07/13/using-your-browser-url-history-estimate-..." target="_top">profile -users based on gender and other classifications</a>. Finally, -Javascript can be used to query the user's timezone via the -<code class="function">Date()</code> object, and to reduce the anonymity set by querying -the <code class="function">navigator</code> object for operating system, CPU, locale, -and user agent information. - </p></li><li class="listitem"><span class="command"><strong>Inserting Plugins</strong></span><p> + </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><span class="command"><strong>Read and insert identifiers</strong></span><p> -Plugins are abysmal at obeying the proxy settings of the browser. Every plugin -capable of performing network activity that the author has -investigated is also capable of performing network activity independent of -browser proxy settings - and often independent of its own proxy settings. -Sites that have plugin content don't even have to be malicious to obtain a -user's -Non-Tor IP (it usually leaks by itself), though <a class="ulink" href="http://decloak.net" target="_top">plenty of active -exploits</a> are possible as well. In addition, plugins can be used to store unique identifiers that are more -difficult to clear than standard cookies. -<a class="ulink" href="http://epic.org/privacy/cookies/flash.html" target="_top">Flash-based -cookies</a> fall into this category, but there are likely numerous other -examples. +The browser contains multiple facilities for storing identifiers that the +adversary creates for the purposes of tracking users. These identifiers are +most obviously cookies, but also include HTTP auth, DOM storage, cached +scripts and other elements with embedded identifiers, client certificates, and +even TLS Session IDs. - </p></li><li class="listitem"><span class="command"><strong>Inserting CSS</strong></span><p> + </p><p> -CSS can also be used to correlate Tor and Non-Tor activity and reveal a user's -Non-Tor IP address, via the usage of -<a class="ulink" href="http://www.tjkdesign.com/articles/css%20pop%20ups/" target="_top">CSS -popups</a> - essentially CSS-based event handlers that fetch content via -CSS's onmouseover attribute. If these popups are allowed to perform network -activity in a different Tor state than they were loaded in, they can easily -correlate Tor and Non-Tor activity and reveal a user's IP address. In -addition, CSS can also be used without Javascript to perform <a class="ulink" href="http://ha.ckers.org/weird/CSS-history.cgi" target="_top">CSS-only history disclosure -attacks</a>. - </p></li><li class="listitem"><span class="command"><strong>Read and insert cookies</strong></span><p> - An adversary in a position to perform MITM content alteration can inject document content elements to both read and inject cookies for arbitrary -domains. In fact, many "SSL secured" websites are vulnerable to this sort of +domains. In fact, even many "SSL secured" websites are vulnerable to this sort of <a class="ulink" href="http://seclists.org/bugtraq/2007/Aug/0070.html" target="_top">active sidejacking</a>. In addition, the ad networks of course perform tracking with cookies as well. - </p></li><li class="listitem"><span class="command"><strong>Create arbitrary cached content</strong></span><p> - -Likewise, the browser cache can also be used to <a class="ulink" href="http://crypto.stanford.edu/sameorigin/safecachetest.html" target="_top">store unique -identifiers</a>. Since by default the cache has no same-origin policy, -these identifiers can be read by any domain, making them an ideal target for -ad network-class adversaries. - </p></li><li class="listitem"><a id="fingerprinting"></a><span class="command"><strong>Fingerprint users based on browser attributes</strong></span><p> There is an absurd amount of information available to websites via attributes of the browser. This information can be used to reduce anonymity set, or even -<a class="ulink" href="http://mandark.fr/0x000000/articles/Total_Recall_On_Firefox..html" target="_top">uniquely -fingerprint individual users</a>. </p><p> +uniquely fingerprint individual users. Fingerprinting is an intimidating +problem to attempt to tackle, especially without a metric to determine or at +least intuitively understand and estimate which features will most contribute +to linkability between visits. -The <a class="ulink" href="https://wiki.mozilla.org/Fingerprinting#Data" target="_top">Panopticlick study -done</a> by the EFF attempts to measure the actual entropy - the number of -identifying bits of information encoded in browser properties. Their result -data is definitely useful, and the metric is probably the appropriate one for +</p><p> + +The <a class="ulink" href="https://panopticlick.eff.org/about.php" target="_top">Panopticlick study +done</a> by the EFF uses the actual entropy - the number of identifying +bits of information encoded in browser properties - as this metric. Their +<a class="ulink" href="https://wiki.mozilla.org/Fingerprinting#Data" target="_top">result data</a> +is definitely useful, and the metric is probably the appropriate one for determining how identifying a particular browser property is. However, some quirks of their study means that they do not extract as much information as they could from display information: they only use desktop resolution (which Torbutton reports as the window resolution) and do not attempt to infer the -size of toolbars. +size of toolbars. In the other direction, they may be over-counting in some +areas, as they did not compute joint entropy over multiple attributes that may +exhibit a high degree of correlation. Also, new browser features are added +regularly, so the data should not be taken as final. + </p><p> +Despite the uncertainty, all fingerprinting attacks leverage the following +attack vectors: -</p></li><li class="listitem"><span class="command"><strong>Remotely or locally exploit browser and/or + </p><div class="orderedlist"><ol class="orderedlist" type="a"><li class="listitem"><span class="command"><strong>Observing Request Behavior</strong></span><p> + +Properties of the user's request behavior comprise the bulk of low-hanging +fingerprinting targets. These include: User agent, Accept-* headers, pipeline +usage, and request ordering. Additionally, the use of custom filters such as +AdBlock and other privacy filters can be used to fingerprint request patterns +(as an extreme example). + + </p></li><li class="listitem"><span class="command"><strong>Inserting Javascript</strong></span><p> + +Javascript can reveal a lot of fingerprinting information. It provides DOM +objects, just as window.screen and window.navigator to extract information +about the useragent. Also, Javascript can be used to query the user's timezone +via the <code class="function">Date()</code> object, and to use timing information to +<a class="ulink" href="http://w2spconf.com/2011/papers/jspriv.pdf" target="_top">fingerprint the CPU +and interpreter speed</a>. + + + + </p></li><li class="listitem"><span class="command"><strong>Inserting Plugins</strong></span><p> + +The Panopticlick project found that the mere list of installed plugins (in +navigator.plugins) was sufficient to provide a large degree of +fingerprintability. Additionally, plugins are capable of extracting font lists, +interface addresses, and other machine information that is beyond what the +browser would normally provide to content. In addition, plugins can be used to +store unique identifiers that are more difficult to clear than standard +cookies. <a class="ulink" href="http://epic.org/privacy/cookies/flash.html" target="_top">Flash-based +cookies</a> fall into this category, but there are likely numerous other +examples. Beyond fingerprinting, plugins are also abysmal at obeying the proxy +settings of the browser. + + + </p></li><li class="listitem"><span class="command"><strong>Inserting CSS</strong></span><p> + +<a class="ulink" href="https://developer.mozilla.org/En/CSS/Media_queries" target="_top">CSS media +queries</a> can be inserted to gather information about the desktop size, +widget size, display type, DPI, user agent type, and other information that +was formerly available only to Javascript. + + </p></li></ol></div></li><li class="listitem"><span class="command"><strong>Remotely or locally exploit browser and/or OS</strong></span><p> Last, but definitely not least, the adversary can exploit either general @@ -173,20 +187,28 @@ </p></li></ol></div></div></div></div><div class="sect1" title="2. Design Requirements and Philosophy"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="DesignRequirements"></a>2. Design Requirements and Philosophy</h2></div></div></div><p> The Tor Browser Design Requirements are meant to describe the properties of a -Private Browsing Mode that defends against both network and local adversaries. +Private Browsing Mode that defends against both network and forensic adversaries. </p><p> There are two main categories of requirements: <a class="link" href="#security" title="2.1. Security Requirements">Security Requirements</a>, and <a class="link" href="#privacy" title="2.2. Privacy Requirements">Privacy Requirements</a>. Security Requirements are the -minimum properties in order for a 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. +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 platform over another. </p><p> -We will maintain an alternate distribution of the web client in order to -maintain and/or restore privacy properties to our users. +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. + </p><p> + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL + NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + <a class="ulink" href="https://www.ietf.org/rfc/rfc2119.txt" target="_top">RFC 2119</a>. + </p><div class="sect2" title="2.1. Security Requirements"><div class="titlepage"><div><div><h3 class="title"><a id="security"></a>2.1. Security Requirements</h3></div></div></div><p> The security requirements are primarily concerned with ensuring the safe use @@ -199,16 +221,24 @@ MUST NOT bypass Tor proxy settings for any content.</p></li><li class="listitem"><span class="command"><strong>State Separation</strong></span><p>The browser MUST NOT provide any stored state to the content window from other browsers or other browsing modes, including shared state from plugins, machine identifiers, and TLS session state. -</p></li><li class="listitem"><span class="command"><strong>Disk Avoidance</strong></span><p>The -browser SHOULD NOT write any browsing history information to disk, or store it -in memory beyond the duration of one Tor session, unless the user has -explicitly opted to store their browsing history information to -disk.</p></li><li class="listitem"><span class="command"><strong>Application Data Isolation</strong></span><p>The browser -MUST NOT write or cause the operating system to -write <span class="emphasis"><em>any information</em></span> to disk outside of the application -directory. All exceptions and shortcomings due to operating system behavior -MUST BE documented. +</p></li><li class="listitem"><span class="command"><strong>Disk Avoidance</strong></span><p> +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. + +</p></li><li class="listitem"><span class="command"><strong>Application Data Isolation</strong></span><p> + +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 <span class="emphasis"><em>any information</em></span> about the use +of private browsing to disk outside of the application's control. The user +must be able to ensure that secure removal 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. + </p></li><li class="listitem"><span class="command"><strong>Update Safety</strong></span><p>The browser SHOULD NOT perform unsafe updates or upgrades.</p></li></ol></div></div><div class="sect2" title="2.2. Privacy Requirements"><div class="titlepage"><div><div><h3 class="title"><a id="privacy"></a>2.2. Privacy Requirements</h3></div></div></div><p> The privacy requirements are primarily concerned with reducing linkability: @@ -217,25 +247,35 @@ platform support, privacy requirements are the set of properties that cause us to prefer one platform over another. - </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><span class="command"><strong>Cross-Domain Identifier Unlinkability</strong></span><p> + </p><p> -User activity on one url bar domain MUST NOT be linkable to their activity in -any other domain by any third party. This property specifically applies to +For the purposes of the unlinkability requirements of this section as well as +the descriptions in the <a class="link" href="#Implementation" title="3. Implementation">implementation +section</a>, a <span class="command"><strong>url bar origin</strong></span> means at least the +second-level DNS name. For example, for mail.google.com, the origin would be +google.com. Implementations MAY, at their option, restrict the url bar origin +to be the entire fully qualified domain name + + </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><span class="command"><strong>Cross-Origin Identifier Unlinkability</strong></span><p> + +User activity on one url bar origin MUST NOT be linkable to their activity in +any other url bar origin by any third party. This property specifically applies to linkability from stored browser identifiers, authentication tokens, and shared state. This functionality SHOULD NOT interfere with federated login in a substantial way. - </p></li><li class="listitem"><span class="command"><strong>Cross-Domain Fingerprinting Unlinkability</strong></span><p> + </p></li><li class="listitem"><span class="command"><strong>Cross-Origin Fingerprinting Unlinkability</strong></span><p> -User activity on one url bar domain MUST NOT be linkable to their activity in -any other domain by any third party. This property specifically applies to +User activity on one url bar origin MUST NOT be linkable to their activity in +any other url bar origin by any third party. This property specifically applies to linkability from fingerprinting browser behavior. </p></li><li class="listitem"><span class="command"><strong>Long-Term Unlinkability</strong></span><p> -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. +The browser SHOULD provide an obvious, easy way to remove all of their +authentication tokens and browser state and obtain a fresh identity. +Additionally, the browser SHOULD clear linkable state by default automatically +upon browser restart, except at user option. </p></li></ol></div></div><div class="sect2" title="2.3. Philosophy"><div class="titlepage"><div><div><h3 class="title"><a id="philosophy"></a>2.3. Philosophy</h3></div></div></div><p> @@ -280,7 +320,7 @@ be restricted from running automatically on every page (via click-to-play placeholders), and/or be sandboxed to restrict the types of system calls they can execute. If the user decides to craft an exemption to allow a plugin to be -used, it MUST ONLY apply to the top level urlbar domain, and not to all sites, +used, it MUST ONLY apply to the top level url bar domain, and not to all sites, to reduce linkability. </p></li><li class="listitem"><span class="command"><strong>Minimize Global Privacy Options</strong></span><p> @@ -288,17 +328,17 @@ <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3100" target="_top">Another failure of Torbutton</a> was (and still is) the options panel. Each option that detectably alters browser behavior can be used as a fingerprinting tool. -Similarly, all extensions <a class="ulink" href="http://blog.chromium.org/2010/06/extensions-in-incognito.html" target="_top">should be +Similarly, all extensions <a class="ulink" href="http://blog.chromium.org/2010/06/extensions-in-incognito.html" target="_top">SHOULD be disabled in the mode</a> except as an opt-in basis. We should not load system-wide addons or plugins. </p><p> -Instead of global browser privacy options, privacy decisions should be made +Instead of global browser privacy options, privacy decisions SHOULD be made <a class="ulink" href="https://wiki.mozilla.org/Privacy/Features/Site-based_data_management_UI" target="_top">per -top-level url-bar domain</a> to eliminate the possibility of linkability +url bar origin</a> to eliminate the possibility of linkability between domains. For example, when a plugin object (or a Javascript access of window.plugins) is present in a page, the user should be given the choice of -allowing that plugin object for that top-level url-bar domain only. The same +allowing that plugin object for that url bar origin only. The same goes for exemptions to third party cookie policy, geo-location, and any other privacy permissions. </p><p> @@ -344,8 +384,8 @@ <span class="command"><strong>network.proxy.socks_version</strong></span>, and <span class="command"><strong>network.proxy.socks_port</strong></span>. </p></li><li class="listitem">Disabling plugins - <p> - Plugins have the ability to make arbitrary OS system calls. This includes + + <p>Plugins have the ability to make arbitrary OS system calls and <a class="ulink" href="http://decloak.net/" target="_top">bypass proxy settings</a>. This includes the ability to make UDP sockets and send arbitrary data independent of the browser proxy settings. </p><p> @@ -359,6 +399,12 @@ also patch the Firefox source code to <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/refs/heads/maint-2.2:/src/..." target="_top">prevent the load of any plugins except for Flash and Gnash</a>. + </p><p> + +Finally, even if the user alters their browser settings to re-enable the Flash +plugin, we have configured NoScript to provide click-to-play placeholders, so +that only desired objects will be loaded, and only after user confirmation. + </p></li><li class="listitem">External App Blocking <p> External apps, if launched automatically, can be induced to load files that @@ -371,13 +417,13 @@ Tor Browser State is separated from existing browser state through use of a custom Firefox profile. Furthermore, plugins are disabled, which prevents Flash cookies from leaking from a pre-existing Flash directory. - </p></div><div class="sect2" title="3.3. Disk Avoidance"><div class="titlepage"><div><div><h3 class="title"><a id="disk-avoidance"></a>3.3. Disk Avoidance</h3></div></div></div><div class="sect3" title="Design Goal:"><div class="titlepage"><div><div><h4 class="title"><a id="id2980587"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> -Tor Browser should optionally prevent all disk records of browser activity. + </p></div><div class="sect2" title="3.3. Disk Avoidance"><div class="titlepage"><div><div><h3 class="title"><a id="disk-avoidance"></a>3.3. Disk Avoidance</h3></div></div></div><div class="sect3" title="Design Goal:"><div class="titlepage"><div><div><h4 class="title"><a id="id2777452"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> +Tor Browser MUST (at user option) prevent all disk records of browser activity. The user should be able to optionally enable URL history and other history features if they so desire. Once we <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3100" target="_top">simplify the preferences interface</a>, we will likely just enable Private Browsing mode by default to handle this goal. - </blockquote></div></div><div class="sect3" title="Implementation Status:"><div class="titlepage"><div><div><h4 class="title"><a id="id3006806"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> + </blockquote></div></div><div class="sect3" title="Implementation Status:"><div class="titlepage"><div><div><h4 class="title"><a id="id2765334"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> For now, Tor Browser blocks write access to the disk through Torbutton using several Firefox preferences. @@ -416,9 +462,9 @@ safely remove the bundle without leaving other traces of Tor usage on their computer. - </p><p>XXX: sjmurdoch, Erinn: explain what magic we do to satisfy this, + </p><p>FIXME: sjmurdoch, Erinn: explain what magic we do to satisfy this, and/or what additional work or auditing needs to be done. - </p></div><div class="sect2" title="3.5. Cross-Domain Identifier Unlinkability"><div class="titlepage"><div><div><h3 class="title"><a id="identifier-linkability"></a>3.5. Cross-Domain Identifier Unlinkability</h3></div></div></div><p> + </p></div><div class="sect2" title="3.5. Cross-Origin Identifier Unlinkability"><div class="titlepage"><div><div><h3 class="title"><a id="identifier-linkability"></a>3.5. Cross-Origin Identifier Unlinkability</h3></div></div></div><p> 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 @@ -435,20 +481,19 @@ 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 top-level url-bar domain, the -six or seven different pieces of privacy UI governing these identifiers and +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 top-level url bar domains for which browser state exists with the ability -to clear and/or block them, possibly with a context-menu option to drill down -into specific types of state. An exmaple of this simplifcation can be seen in -Figure 1. +the url bar origin for which browser state exists, possibly with a +context-menu option to drill down into specific types of state or permissions. +An example of this simplification can be seen in Figure 1. - </p><div class="figure"><a id="id2962771"></a><p class="title"><b>Figure 1. Improving the Privacy UI</b></p><div class="figure-contents"><div class="mediaobject" align="center"><img src="CookieManagers.png" align="middle" alt="Improving the Privacy UI" /></div><div class="caption"><p></p> + </p><div class="figure"><a id="id2758612"></a><p class="title"><b>Figure 1. Improving the Privacy UI</b></p><div class="figure-contents"><div class="mediaobject" align="center"><img src="CookieManagers.png" align="middle" alt="Improving the Privacy UI" /></div><div class="caption"><p></p> On the left is the standard Firefox cookie manager. On the right is a mock-up -of how isolating identifiers to the URL bar domain might simplify the privacy +of how isolating identifiers to the URL bar origin might simplify the privacy UI for all data - not just cookies. Both windows represent the set of -Cookies accomulated after visiting just five sites, but the window on the +Cookies accumulated after visiting just five sites, but the window on the right has the option of also representing history, DOM Storage, HTTP Auth, search form history, login values, and so on within a context menu for each site. @@ -456,10 +501,10 @@ </div></div></div><br class="figure-break" /><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem">Cookies <p><span class="command"><strong>Design Goal:</strong></span> -All cookies should be double-keyed to the top-level domain. There exists a -<a class="ulink" href="https://bugzilla.mozilla.org/show_bug.cgi?id=565965" target="_top">Mozilla -bug</a> that contains a prototype patch, but it lacks UI, and does not -apply to modern Firefoxes. +All cookies MUST be double-keyed to the url bar origin and third-party +origin. There exists a <a class="ulink" href="https://bugzilla.mozilla.org/show_bug.cgi?id=565965" target="_top">Mozilla bug</a> +that contains a prototype patch, but it lacks UI, and does not apply to modern +Firefoxes. </p><p><span class="command"><strong>Implementation Status:</strong></span> @@ -471,32 +516,40 @@ </p></li><li class="listitem">Cache <p> -Cache is isolated to the top-level url bar domain by using a technique -pioneered by Colin Jackson et al, via their work on <a class="ulink" href="http://www.safecache.com/" target="_top">SafeCache</a>. The technique re-uses the + +Cache is isolated to the url bar origin by using a technique pioneered by +Colin Jackson et al, via their work on <a class="ulink" href="http://www.safecache.com/" target="_top">SafeCache</a>. The technique re-uses the <a class="ulink" href="https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsICachingChannel" target="_top">nsICachingChannel.cacheKey</a> -attribute that Firefox uses internally to prevent improper caching of HTTP POST data. +attribute that Firefox uses internally to prevent improper caching and reuse +of HTTP POST data. + </p><p> + However, to <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3666" target="_top">increase the -security of the isolation</a> and to <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3754" target="_top">solve strange and -unknown conflicts with OCSP</a>, we had to <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/refs/heads/maint-2.2:/src/..." target="_top">patch -Firefox to provide a cacheDomain cache attribute</a>. We use the full -url bar domain as input to this field. +security of the isolation</a> and to <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3754" target="_top">solve conflicts +with OCSP relying the cacheKey property for reuse of POST requests</a>, we +had to <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/refs/heads/maint-2.2:/src/..." target="_top">patch +Firefox to provide a cacheDomain cache attribute</a>. We use the fully +qualified url bar domain as input to this field. + </p><p> + 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. -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 (the url bar domain) -used to load the page, as opposed to relying solely on the referer property. </p><p> + Therefore, <a class="ulink" href="http://crypto.stanford.edu/sameorigin/safecachetest.html" target="_top">the original -Stanford test -cases</a> are expected to fail. Functionality can still be verified by -navigating to <a class="ulink" href="about:cache" target="_top">about:cache</a> and viewing the key -used for each cache entry. Each third party element should have an additional -"domain=string" property prepended, which will list the top-level urlbar -domain that was used to source the third party element. +Stanford test cases</a> are expected to fail. Functionality can still be +verified by navigating to <a class="ulink" href="about:cache" target="_top">about:cache</a> and +viewing the key used for each cache entry. Each third party element should +have an additional "domain=string" property prepended, which will list the +FQDN that was used to source the third party element. + </p></li><li class="listitem">HTTP Auth <p> @@ -510,31 +563,53 @@ </p></li><li class="listitem">DOM Storage <p><span class="command"><strong>Design Goal:</strong></span> -DOM storage for third party domains MUST BE isolated to the url bar domain, +DOM storage for third party domains MUST BE isolated to the url bar origin, to prevent linkability between sites. </p><p><span class="command"><strong>Implementation Status:</strong></span> Because it is isolated to third party domain as opposed to top level url bar -domain, we entirely disable DOM storage as a stopgap to ensure unlinkability. +origin, we entirely disable DOM storage as a stopgap to ensure unlinkability. </p></li><li class="listitem">TLS session resumption and HTTP Keep-Alive <p> -TLS session resumption and HTTP Keep-Alive must not allow third party origins +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. </p><p><span class="command"><strong>Design Goal:</strong></span> -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. +TLS session resumption 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. </p><p><span class="command"><strong>Implementation Status:</strong></span> We <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/4099" target="_top">plan to disable</a> TLS session resumption, and limit HTTP Keep-alive duration. - </p></li><li class="listitem">window.name + </p></li><li class="listitem">User confirmation for cross-origin redirects + <p><span class="command"><strong>Design Goal:</strong></span> + +To prevent attacks aimed at subverting the Cross-Origin Identifier +Unlinkability <a class="link" href="#privacy" title="2.2. Privacy Requirements">privacy requirement</a>, the browser +MUST prompt users before following redirects that would cause the user to +automatically navigate between two different url bar origins. + + </p><p><span class="command"><strong>Implementation status:</strong></span> + +There are numerous ways for the user to be redirected, and the Firefox API +support to detect each of them is poor. We have a <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3600" target="_top">trac bug +open</a> to implement what we can. + + </p><p> + +We are not concerned with linkability due to explicit user action (either by +accepting cross-origin redirects, or by clicking normal links) because it is +assumed that private browsing sessions will be relatively short-lived, +especially with frequent use of the <a class="link" href="#new-identity" title="3.7. Long-Term Unlinkability via "New Identity" button">New +Identity</a> button. + + </p></li><li class="listitem">window.name <p> <a class="ulink" href="https://developer.mozilla.org/En/DOM/Window.name" target="_top">window.name</a> is @@ -565,11 +640,11 @@ #3455</a> is the Torbutton ticket to make use of the new Tor functionality. - </p></li></ol></div></div><div class="sect2" title="3.6. Cross-Domain Fingerprinting Unlinkability"><div class="titlepage"><div><div><h3 class="title"><a id="fingerprinting-linkability"></a>3.6. Cross-Domain Fingerprinting Unlinkability</h3></div></div></div><p> + </p></li></ol></div></div><div class="sect2" title="3.6. Cross-Origin Fingerprinting Unlinkability"><div class="titlepage"><div><div><h3 class="title"><a id="fingerprinting-linkability"></a>3.6. Cross-Origin Fingerprinting Unlinkability</h3></div></div></div><p> In order to properly address the fingerprinting 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. <a class="ulink" href="https://panopticlick.eff.org/about.php" target="_top">The Panopticlick Project</a> +properties beyond any stored origin-related state. <a class="ulink" href="https://panopticlick.eff.org/about.php" target="_top">The Panopticlick Project</a> by the EFF provides us with exactly this metric. The researchers conducted a survey of volunteers who were asked to visit an experiment page that harvested many of the above components. They then computed the Shannon Entropy of the @@ -601,7 +676,7 @@ </p><p><span class="command"><strong>Design Goal:</strong></span> -All plugins that have not been specifically audited or sandboxed must be +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 @@ -641,7 +716,7 @@ </p></li><li class="listitem">User Agent and HTTP Headers <p><span class="command"><strong>Design Goal:</strong></span> -All Tor Browser users should provide websites with an identical user agent and +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. @@ -683,13 +758,13 @@ </p></li><li class="listitem">Timezone and clock offset <p><span class="command"><strong>Design Goal:</strong></span> -All Tor Browser users should 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. -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. +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. </p><p><span class="command"><strong>Implementation Status:</strong></span> @@ -764,11 +839,11 @@ </p></li></ol></div></div><div class="sect2" title="3.7. Long-Term Unlinkability via "New Identity" button"><div class="titlepage"><div><div><h3 class="title"><a id="new-identity"></a>3.7. Long-Term Unlinkability via "New Identity" button</h3></div></div></div><p> In order to avoid long-term linkability, we provide a "New Identity" context menu option in Torbutton. - </p><div class="sect3" title="Design Goal:"><div class="titlepage"><div><div><h4 class="title"><a id="id2991890"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> + </p><div class="sect3" title="Design Goal:"><div class="titlepage"><div><div><h4 class="title"><a id="id2751206"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> -All linkable identifiers and browser state should be cleared by this feature. +All linkable identifiers and browser state MUST be cleared by this feature. - </blockquote></div></div><div class="sect3" title="Implementation Status:"><div class="titlepage"><div><div><h4 class="title"><a id="id3007443"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> + </blockquote></div></div><div class="sect3" title="Implementation Status:"><div class="titlepage"><div><div><h4 class="title"><a id="id2756691"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> First, Torbutton disables all open tabs and windows via nsIContentPolicy blocking, and then closes each tab and window. The extra step for blocking tabs is done as a precaution to @@ -812,19 +887,14 @@ The pref does successfully clear the permissions manager memory if toggled. It does not need to be set in prefs.js, and can be handled by Torbutton. - </p><p><span class="command"><strong>Design Goal:</strong></span> - -As an additional design goal, we would like to later alter this patch to allow this -information to be cleared from memory. The implementation does not currently -allow this. - </p></li><li class="listitem">Make Intermediate Cert Store memory-only <p> -The intermediate certificate store holds information about SSL certificates -that may only be used by a limited number of domains. In some cases -effectively recording on disk the fact that a website owned by a certain -organization was viewed. +The intermediate certificate store records the intermediate SSL certificates +the browser has seen to date. Because these intermediate certificates are used +by a limited number of domains (and in some cases, only a single domain), +the intermediate certificate store can serve as a low-resolution record of +browsing history. </p><p><span class="command"><strong>Design Goal:</strong></span> @@ -846,8 +916,8 @@ To <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3666" target="_top">increase the security of cache isolation</a> and to <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3754" target="_top">solve strange and unknown conflicts with OCSP</a>, we had to <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/refs/heads/maint-2.2:/src/..." target="_top">patch -Firefox to provide a cacheDomain cache attribute</a>. We use the full -url bar domain as input to this field. +Firefox to provide a cacheDomain cache attribute</a>. We use the url bar +FQDN as input to this field. </p></li><li class="listitem">Randomize HTTP pipeline order and depth <p> @@ -869,7 +939,7 @@ This patch prevents random URLs from being inserted into content-prefs.sqllite in the profile directory as content prefs change (includes site-zoom and perhaps other site prefs?). - </p></li></ol></div></div></div><div class="sect1" title="4. Packaging"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Packaging"></a>4. Packaging</h2></div></div></div><p> </p><div class="sect2" title="4.1. Build Process Security"><div class="titlepage"><div><div><h3 class="title"><a id="build-security"></a>4.1. Build Process Security</h3></div></div></div><p> </p></div><div class="sect2" title="4.2. External Addons"><div class="titlepage"><div><div><h3 class="title"><a id="addons"></a>4.2. External Addons</h3></div></div></div><p> </p><div class="sect3" title="Included Addons"><div class="titlepage"><div><div><h4 class="title"><a id="id2974027"></a>Included Addons</h4></div></div></div></div><div class="sect3" title="Excluded Addons"><div class="titlepage"><div><div><h4 class="title"><a id="id2999979"></a>Excluded Addons</h4></div></div></div></div><div class="sect3" title="Dangerous Addons"><div class="titlepage"><div><div><h4 cla ss="title"><a id="id3006218"></a>Dangerous Addons</h4></div></div></div></div></div><div class="sect2" title="4.3. Pref Changes"><div class="titlepage"><div><div><h3 class="title"><a id="prefs"></a>4.3. Pref Changes</h3></div></div></div><p> </p></div><div class="sect2" title="4.4. Update Security"><div class="titlepage"><div><div><h3 class="title"><a id="update-mechanism"></a>4.4. Update Security</h3></div></div></div><p> </p></div></div><div class="sect1" title="5. Testing"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Testing"></a>5. Testing</h2></div></div></div><p> + </p></li></ol></div></div></div><div class="sect1" title="4. Packaging"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Packaging"></a>4. Packaging</h2></div></div></div><p> </p><div class="sect2" title="4.1. Build Process Security"><div class="titlepage"><div><div><h3 class="title"><a id="build-security"></a>4.1. Build Process Security</h3></div></div></div><p> </p></div><div class="sect2" title="4.2. External Addons"><div class="titlepage"><div><div><h3 class="title"><a id="addons"></a>4.2. External Addons</h3></div></div></div><p> </p><div class="sect3" title="Included Addons"><div class="titlepage"><div><div><h4 class="title"><a id="id2757442"></a>Included Addons</h4></div></div></div></div><div class="sect3" title="Excluded Addons"><div class="titlepage"><div><div><h4 class="title"><a id="id2782047"></a>Excluded Addons</h4></div></div></div></div><div class="sect3" title="Dangerous Addons"><div class="titlepage"><div><div><h4 cla ss="title"><a id="id2771088"></a>Dangerous Addons</h4></div></div></div></div></div><div class="sect2" title="4.3. Pref Changes"><div class="titlepage"><div><div><h3 class="title"><a id="prefs"></a>4.3. Pref Changes</h3></div></div></div><p> </p></div><div class="sect2" title="4.4. Update Security"><div class="titlepage"><div><div><h3 class="title"><a id="update-mechanism"></a>4.4. Update Security</h3></div></div></div><p> </p></div></div><div class="sect1" title="5. Testing"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Testing"></a>5. Testing</h2></div></div></div><p> 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 @@ -890,7 +960,6 @@ testing, and also in the hope that some brave soul will one day decide to combine them into a comprehensive automated test suite. - </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><a class="ulink" href="http://decloak.net/" target="_top">Decloak.net</a><p> Decloak.net is the canonical source of plugin and external-application based @@ -904,11 +973,11 @@ Williams, the author of <a class="ulink" href="http://www.janusvm.com/" target="_top">JanusVM</a> and <a class="ulink" href="http://www.januspa.com/" target="_top">JanusPA</a>. - </p></li><li class="listitem"><a class="ulink" href="https://www.jondos.de/en/anontest" target="_top">JonDos + </p></li><li class="listitem"><a class="ulink" href="https://ip-check.info" target="_top">JonDos AnonTest</a><p> -The <a class="ulink" href="https://www.jondos.de" target="_top">JonDos people</a> also provide an -anonymity tester. It is more focused on HTTP headers than plugin bypass, and +The <a class="ulink" href="https://anonymous-proxy-servers.net/" target="_top">JonDos people</a> also provide an +anonymity tester. It is more focused on HTTP headers and behaviors than plugin bypass, and points out a couple of headers Torbutton could do a better job with obfuscating. @@ -923,7 +992,7 @@ Analyzer</a><p> The Privacy Analyzer provides a dump of all sorts of browser attributes and -settings that it detects, including some information on your origin IP +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.