<?xml version="1.0" encoding="UTF-8"?>
 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "">
 <html xmlns=""><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Torbutton Design Documentation</title><meta name="generator" content="DocBook XSL Stylesheets V1.75.2" /></head><body><div class="article" title="Torbutton Design Documentation"><div class="titlepage"><div><div><h2 class="title"><a id="design"></a>Torbutton Design Documentation</h2></div><div><div class="author"><h3 class="author"><span class="firstname">Mike</span> <span class="surname">Perry</span></h3><div class="affiliation"><div class="address"><p><code class="email">&lt;<a class="email" href="mailto:mikeperry.fscked/org">mikeperry.fscked/org</a>&gt;</code></p></div></div></div></div><div><p class="pubdate">Apr 10 2011</p></div></div><hr /></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="#id2666923">1. Introduction</a></span></dt><dd><dl><dt><span class="sect2"><a href="#adversary">1.1. Adversary Model</a></span></dt><dt><span class="sect2"><a href="#requirements">1.2. Torbutton Requirements</a></span></dt><dt><span class="sect2"><a href="#layout">1.3. Extension Layout</a></span></dt></dl></dd><dt><span class="sect1"><a href="#components">2. Components</a></span></dt><dd><dl><dt><span class="sect2"><a href="#hookedxpcom">2.1. Hooked Components</a></span></dt><dt><span class="sect2"><a href="#id2690319">2.2. New Components</a></span></dt></dl></dd><dt><span class="sect1"><a href="#id2681735">3. Chrome</a></span></dt><dd><dl><dt><span class="sect2"><a href="#id2702019">3.1. XUL Windows and Overlays</a></span></dt><dt><span class="sect2"><a href="#id2694797">3.2. Major Chrome Observers</a></span></dt></dl></dd><dt><span class="sect1"><a href="#id2696524">4. Toggle Code Path</a></span></dt><dd><dl><dt><span class="sect2"><a href="#id2699452">4.1. Button Click</a></span></dt><dt><span class="sect2"><a href="#id2697978">4.2. Proxy Update</a></span></dt><dt><span class="sect2"><a href="#id2697015">4.3. Settings Update</a></span></dt><dt><span class="sect2"><a href="#preferences">4.4. Firefox preferences touched during Toggle</a></span></dt></dl></dd><dt><span class="sect1"><a href="#id2702702">5. Description of Options</a></span></dt><dd><dl><dt><span class="sect2"><a href="#id2704948">5.1. Proxy Settings</a></span></dt><dt><span class="sect2"><a href="#id2686645">5.2. Dynamic Content Settings</a></span></dt><dt><span class="sect2"><a href="#id2705261">5.3. History and Forms Settings</a></span></dt><dt><span class="sect2"><a href="#id2705577">5.4. Cache Settings</a></span></dt><dt><span class="sect2"><a href="#id2705686">5.5. Cookie and Auth Settings</a></span></dt><dt><span class="sect2"><a href="#id2705999">5.6. Startup Settings</a></span></dt><dt><span class="sect2"><a href="#id2706113">5.7. Shutdown Settings</a></span></dt><dt><span class="sect2"><a href="#id2706173">5.8. Header Settings</a></span></dt></dl></dd><dt><span class="sect1"><a href="#FirefoxBugs">6. Relevant Firefox Bugs</a></span></dt><dd><dl><dt><span class="sect2"><a href="#TorBrowserBugs">6.1. Tor Browser Bugs</a></span></dt><dt><span class="sect2"><a href="#ToggleModelBugs">6.2. Toggle Model Bugs</a></span></dt></dl></dd><dt><span class="sect1"><a href="#TestPlan">7. Testing</a></span></dt><dd><dl><dt><span class="sect2"><a href="#SingleStateTesting">7.1. Single state testing</a></span></dt><dt><span class="sect2"><a href="#id2707624">7.2. Multi-state testing</a></span></dt><dt><span class="sect2"><a href="#HackTorbutton">7.3. Active testing (aka How to Hack Torbutton)</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="id2666923"></a>1. Introduction</h2></div></div></div><p>
 This document describes the goals, operation, and testing procedures of the
 Torbutton Firefox extension. It is current as of Torbutton 1.3.2.
   </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>
 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.
    </p><div class="sect3" title="Adversary Goals"><div class="titlepage"><div><div><h4 class="title"><a id="adversarygoals"></a>Adversary Goals</h4></div></div></div><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><span class="command"><strong>Bypassing proxy settings</strong></span><p>The adversary's primary goal is direct compromise and bypass of 
 Tor, causing the user to directly connect to an IP of the adversary's
 choosing.</p></li><li class="listitem"><span class="command"><strong>Correlation of Tor vs Non-Tor Activity</strong></span><p>If direct proxy bypass is not possible, the adversary will likely
 happily settle for the ability to correlate something a user did via Tor with
 their non-Tor activity. This can be done with cookies, cache identifiers,
 javascript events, and even CSS. Sometimes the fact that a user uses Tor may
 be enough for some authorities.</p></li><li class="listitem"><span class="command"><strong>History disclosure</strong></span><p>
 The adversary may also be interested in history disclosure: the ability to
 query a user's history to see if they have issued certain censored search
 queries, or visited censored sites.
      </p></li><li class="listitem"><span class="command"><strong>Location information</strong></span><p>
 Location information such as timezone and locality can be useful for the
 adversary to determine if a user is in fact originating from one of the
 regions they are attempting to control, or to zero-in on the geographical
 location of a particular dissident or whistleblower.
      </p></li><li class="listitem"><span class="command"><strong>Miscellaneous anonymity set reduction</strong></span><p>
 Anonymity set reduction is also useful in attempting to zero in on a
 particular individual. If the dissident or whistleblower is using a rare build
 of Firefox for an obscure operating system, this can be very useful
 information for tracking them down, or at least <a class="link" href="#fingerprinting">tracking their activities</a>.
      </p></li><li class="listitem"><span class="command"><strong>History records and other on-disk
 In some cases, the adversary may opt for a heavy-handed approach, such as
 seizing the computers of all Tor users in an area (especially after narrowing
 the field by the above two pieces of information). History records and cache
 data are the primary goals here.
      </p></li></ol></div></div><div class="sect3" title="Adversary Capabilities - Positioning"><div class="titlepage"><div><div><h4 class="title"><a id="adversarypositioning"></a>Adversary Capabilities - Positioning</h4></div></div></div><p>
 The adversary can position themselves at a number of different locations in
 order to execute their attacks.
     </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><span class="command"><strong>Exit Node or Upstream Router</strong></span><p>
 The adversary can run exit nodes, or alternatively, they may control routers
 upstream of exit nodes. Both of these scenarios have been observed in the
      </p></li><li class="listitem"><span class="command"><strong>Adservers and/or Malicious Websites</strong></span><p>
 The adversary can also run websites, or more likely, they can contract out
 ad space from a number of different adservers and inject content that way. For
 some users, the adversary may be the adservers themselves. It is not
 inconceivable that adservers may try to subvert or reduce a user's anonymity 
 through Tor for marketing purposes.
      </p></li><li class="listitem"><span class="command"><strong>Local Network/ISP/Upstream Router</strong></span><p>
 The adversary can also inject malicious content at the user's upstream router
 when they have Tor disabled, in an attempt to correlate their Tor and Non-Tor
      </p></li><li class="listitem"><span class="command"><strong>Physical Access</strong></span><p>
 Some users face adversaries with intermittent or constant physical access.
 Users in Internet cafes, for example, face such a threat. In addition, in
 countries where simply using tools like Tor is illegal, users may face
 confiscation of their computer equipment for excessive Tor usage or just
 general suspicion.
      </p></li></ol></div></div><div class="sect3" title="Adversary Capabilities - Attacks"><div class="titlepage"><div><div><h4 class="title"><a id="attacks"></a>Adversary Capabilities - Attacks</h4></div></div></div><p>
 The adversary can perform the following attacks from a number of different 
 positions to accomplish various aspects of their goals. It should be noted
 that many of these attacks (especially those involving IP address leakage) are
 often performed by accident by websites that simply have Javascript, dynamic 
 CSS elements, and plugins. Others are performed by adservers seeking to
 correlate users' activity across different IP addresses, and still others are
 performed by malicious agents on the Tor network and at national firewalls.
     </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><span class="command"><strong>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="" 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="" 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>
 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
 Non-Tor IP (it usually leaks by itself), though <a class="ulink" href="" 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="" target="_top">Flash-based
 cookies</a> fall into this category, but there are likely numerous other
      </p></li><li class="listitem"><span class="command"><strong>Inserting CSS</strong></span><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="" 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="" target="_top">CSS-only history disclosure
      </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 <a class="ulink" href="" target="_top">active
      </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="" 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
 adserver-class adversaries.
      </p></li><li class="listitem"><a id="fingerprinting"></a><span class="command"><strong>Fingerprint users based on browser
 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="" target="_top">uniquely
 fingerprint individual users</a>. </p><p>
 For illustration, let's perform a
 back-of-the-envelope calculation on the number of anonymity sets for just the
 resolution information available in the <a class="ulink" href="" target="_top">window</a> and
 <a class="ulink" href="" target="_top">window.screen</a>
 Browser window resolution information provides something like
 (1280-640)*(1024-480)=348160 different anonymity sets. Desktop resolution
 information contributes about another factor of 5 (for about 5 resolutions in
 typical use). In addition, the dimensions and position of the desktop taskbar
 are available, which can reveal hints on OS information. This boosts the count
 by a factor of 5 (for each of the major desktop taskbars - Windows, OSX, KDE
 and Gnome, and None). Subtracting the browser content window
 size from the browser outer window size provide yet more information.
 Firefox toolbar presence gives about a factor of 8 (3 toolbars on/off give
 2<sup>3</sup>=8). Interface effects such as title bar font size
 and window manager settings gives a factor of about 9 (say 3 common font sizes
 for the title bar and 3 common sizes for browser GUI element fonts).
 Multiply this all out, and you have (1280-640)*(1024-480)*5*5*8*9 ~=
 2<sup>29</sup>, or a 29 bit identifier based on resolution
 information alone. </p><p>
 Of course, this space is non-uniform in user density and prone to incremental
 changes. The <a class="ulink" href="" 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
 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.
 </p></li><li class="listitem"><span class="command"><strong>Remotely or locally exploit browser and/or
 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.
      </p></li></ol></div></div></div><div class="sect2" title="1.2. Torbutton Requirements"><div class="titlepage"><div><div><h3 class="title"><a id="requirements"></a>1.2. Torbutton Requirements</h3></div></div></div><div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3>
 Since many settings satisfy multiple requirements, this design document is
 organized primarily by Torbutton components and settings. However, if you are
 the type that would rather read the document from the requirements
 perspective, it is in fact possible to search for each of the following
 requirement phrases in the text to find the relevant features that help meet
 that requirement.
 From the above Adversary Model, a number of requirements become clear. 
    </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><a id="proxy"></a><span class="command"><strong>Proxy Obedience</strong></span><p>The browser
 MUST NOT bypass Tor proxy settings for any content.</p></li><li class="listitem"><a id="state"></a><span class="command"><strong>State Separation</strong></span><p>Browser state (cookies, cache, history, 'DOM storage'), accumulated in
  one Tor state MUST NOT be accessible via the network in
  another Tor state.</p></li><li class="listitem"><a id="isolation"></a><span class="command"><strong>Network Isolation</strong></span><p>Pages MUST NOT perform any network activity in a Tor state different
  from the state they were originally loaded in.</p><p>Note that this requirement is
 being de-emphasized due to the coming shift to supporting only the Tor Browser
 Bundles, which do not support a Toggle operation.</p></li><li class="listitem"><a id="undiscoverability"></a><span class="command"><strong>Tor Undiscoverability</strong></span><p>With
 the advent of bridge support in Tor 0.2.0.x, there are now a class of Tor
 users whose network fingerprint does not obviously betray the fact that they
 are using Tor. This should extend to the browser as well - Torbutton MUST NOT 
 reveal its presence while Tor is disabled.
 </p><p>Note that this requirement is
 being de-emphasized due to the coming shift to supporting only the Tor Browser
 Bundles, which do not support a Toggle operation.</p></li><li class="listitem"><a id="disk"></a><span class="command"><strong>Disk Avoidance</strong></span><p>The browser SHOULD NOT write any Tor-related state to disk, or store it
  in memory beyond the duration of one Tor toggle.</p></li><li class="listitem"><a id="location"></a><span class="command"><strong>Location Neutrality</strong></span><p>The browser SHOULD NOT leak location-specific information, such as
  timezone or locale via Tor.</p></li><li class="listitem"><a id="setpreservation"></a><span class="command"><strong>Anonymity Set
 Preservation</strong></span><p>The browser SHOULD NOT leak any other anonymity
 set reducing or fingerprinting information
  (such as user agent, extension presence, and resolution information)
 automatically via Tor. The assessment of the attacks above should make it clear
 that anonymity set reduction is a very powerful method of tracking and
 eventually identifying anonymous users.
 </p></li><li class="listitem"><a id="updates"></a><span class="command"><strong>Update Safety</strong></span><p>The browser
 SHOULD NOT perform unauthenticated updates or upgrades via Tor.</p></li><li class="listitem"><a id="interoperate"></a><span class="command"><strong>Interoperability</strong></span><p>Torbutton SHOULD interoperate with third-party proxy switchers that
  enable the user to switch between a number of different proxies. It MUST
  provide full Tor protection in the event a third-party proxy switcher has
  enabled the Tor proxy settings.</p></li></ol></div></div><div class="sect2" title="1.3. Extension Layout"><div class="titlepage"><div><div><h3 class="title"><a id="layout"></a>1.3. Extension Layout</h3></div></div></div><p>Firefox extensions consist of two main categories of code: 'Components' and
 'Chrome'. Components are a fancy name for classes that implement a given
 interface or interfaces. In Firefox, components <a class="ulink" href="" target="_top">can be
 written</a> in C++,
 Javascript, or a mixture of both. Components have two identifiers: their
 '<a class="ulink" href="" target="_top">Contract
 ID</a>' (a human readable path-like string), and their '<a class="ulink" href="" target="_top">Class
 ID</a>' (a GUID hex-string). In addition, the interfaces they implement each have a hex
 'Interface ID'. It is possible to 'hook' system components - to reimplement
 their interface members with your own wrappers - but only if the rest of the
 browser refers to the component by its Contract ID. If the browser refers to
 the component by Class ID, it bypasses your hooks in that use case.
 Technically, it may be possible to hook Class IDs by unregistering the
 original component, and then re-registering your own, but this relies on
 obsolete and deprecated interfaces and has proved to be less than
 stable.</p><p>'Chrome' is a combination of XML and Javascript used to describe a window.
 Extensions are allowed to create 'overlays' that are 'bound' to existing XML
 window definitions, or they can create their own windows. The DTD for this XML
 is called <a class="ulink" href="" target="_top">XUL</a>.</p></div></div><div class="sect1" title="2. Components"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="components"></a>2. Components</h2></div></div></div><p>
 Torbutton installs components for two purposes: hooking existing components to
 reimplement their interfaces; and creating new components that provide
 services to other pieces of the extension.
   </p><div class="sect2" title="2.1. Hooked Components"><div class="titlepage"><div><div><h3 class="title"><a id="hookedxpcom"></a>2.1. Hooked Components</h3></div></div></div><p>Torbutton makes extensive use of Contract ID hooking, and implements some
 of its own standalone components as well.  Let's discuss the hooked components
 first.</p><div class="sect3" title=";1 ,;1, and;1 - components/external-app-blocker.js"><div class="titlepage"><div><div><h4 class="title"><a id="appblocker"></a><a class="ulink" href="" target="_top">;1
 </a>, <a class="ulink" href="" target="_top">;1</a>,
 and <a class="ulink" href="" target="_top">;1</a>
 - <a class="ulink" href="" target="_top">components/external-app-blocker.js</a></h4></div></div></div><p>
 Due to <a class="link" href="#FirefoxBugs" title="6. Relevant Firefox Bugs">Firefox Bug</a> <a class="ulink" href="" target="_top">440892</a> allowing Firefox 3.x to automatically launch some
 applications without user intervention, Torbutton had to wrap the three
 components involved in launching external applications to provide user
 confirmation before doing so while Tor is enabled. Since external applications
 do not obey proxy settings, they can be manipulated to automatically connect
 back to arbitrary servers outside of Tor with no user intervention. Fixing
 this issue helps to satisfy Torbutton's <a class="link" href="#proxy">Proxy
 Obedience</a> Requirement.
  </p></div><div class="sect3" title=";2 - components/ignore-history.js"><div class="titlepage"><div><div><h4 class="title"><a id="id2696239"></a><a class="ulink" href=";2" target="_top">;2</a>
 - <a class="ulink" href="" target="_top">components/ignore-history.js</a></h4></div></div></div><p>This component was contributed by <a class="ulink" href="" target="_top">Collin Jackson</a> as a method for defeating
 CSS and Javascript-based methods of history disclosure. The global-history
 component is what is used by Firefox to determine if a link was visited or not
 (to apply the appropriate style to the link). By hooking the <a class="ulink" href="" target="_top">isVisited</a>
 and <a class="ulink" href="" target="_top">addURI</a>
 methods, Torbutton is able to selectively prevent history items from being
 added or being displayed as visited, depending on the Tor state and the user's
 This component helps satisfy the <a class="link" href="#state">State Separation</a>
 and <a class="link" href="#disk">Disk Avoidance</a> requirements of Torbutton. It
 is only needed for Firefox 3.x. On Firefox 4, we omit this component in favor
 of the <a class="ulink" href="" target="_top">built-in
 history protections</a>.
 </p></div><div class="sect3" title=";2 - components/block-livemarks.js"><div class="titlepage"><div><div><h4 class="title"><a id="livemarks"></a><a class="ulink" href=";2" target="_top">;2</a>
 - <a class="ulink" href="" target="_top">components/block-livemarks.js</a></h4></div></div></div><p>
 The <a class="ulink" href="" target="_top">livemark</a> service
 is started by a timer that runs 5 seconds after Firefox
 startup. As a result, we cannot simply call the stopUpdateLivemarks() method to
 disable it. We must wrap the component to prevent this start() call from
 firing in the event the browser starts in Tor mode.
 This component helps satisfy the <a class="link" href="#isolation">Network
 Isolation</a> and <a class="link" href="#setpreservation">Anonymity Set
 Preservation</a> requirements.
 </p></div></div><div class="sect2" title="2.2. New Components"><div class="titlepage"><div><div><h3 class="title"><a id="id2690319"></a>2.2. New Components</h3></div></div></div><p>Torbutton creates four new components that are used throughout the
 extension. These components do not hook any interfaces, nor are they used
 anywhere besides Torbutton itself.</p><div class="sect3" title=";2 - components/cookie-jar-selector.js"><div class="titlepage"><div><div><h4 class="title"><a id="cookiejar"></a><a class="ulink" href="" target="_top">;2
 - components/cookie-jar-selector.js</a></h4></div></div></div><p>The cookie jar selector (also based on code from <a class="ulink" href="" target="_top">Collin
 Jackson</a>) is used by the Torbutton chrome to switch between
 Tor and Non-Tor cookies. It stores an XML representation of the current
 cookie state in memory and/or on disk. When Tor is toggled, it syncs the
 current cookies to this XML store, and then loads the cookies for the other
 state from the XML store.
 This component helps to address the <a class="link" href="#state">State
 Isolation</a> requirement of Torbutton.
 </p></div><div class="sect3" title=";1 - components/torbutton-logger.js"><div class="titlepage"><div><div><h4 class="title"><a id="id2683534"></a><a class="ulink" href="" target="_top">;1
 - components/torbutton-logger.js</a></h4></div></div></div><p>The torbutton logger component allows on-the-fly redirection of torbutton
 logging messages to either Firefox stderr
 (<span class="command"><strong>extensions.torbutton.logmethod=0</strong></span>), the Javascript error console
 (<span class="command"><strong>extensions.torbutton.logmethod=1</strong></span>), or the DebugLogger extension (if
 available - <span class="command"><strong>extensions.torbutton.logmethod=2</strong></span>). It also allows you to
 change the loglevel on the fly by changing
 <span class="command"><strong>extensions.torbutton.loglevel</strong></span> (1-5, 1 is most verbose).
 </p></div><div class="sect3" title=";1 - components/window-mapper.js"><div class="titlepage"><div><div><h4 class="title"><a id="windowmapper"></a><a class="ulink" href="" target="_top">;1
 - components/window-mapper.js</a></h4></div></div></div><p>Torbutton tags Firefox <a class="ulink" href="" target="_top">tabs</a> with a special variable that indicates the Tor
 state the tab was most recently used under to fetch a page. The problem is
 that for many Firefox events, it is not possible to determine the tab that is
 actually receiving the event. The Torbutton window mapper allows the Torbutton
 chrome and other components to look up a <a class="ulink" href="" target="_top">browser
 tab</a> for a given <a class="ulink" href="" target="_top">HTML content
 window</a>. It does this by traversing all windows and all browsers, until it
 finds the browser with the requested <a class="ulink" href="" target="_top">contentWindow</a> element. Since the content policy
 and page loading in general can generate hundreds of these lookups, this
 result is cached inside the component.
 </p></div><div class="sect3" title=";1"><div class="titlepage"><div><div><h4 class="title"><a id="crashobserver"></a><a class="ulink" href="" target="_top">;1</a></h4></div></div></div><p>
 This component detects when Firefox crashes by altering Firefox prefs during
 runtime and checking for the same values at startup. It <a class="ulink" href="" target="_top">synchronizes
 the preference service</a> to ensure the altered prefs are written to disk
   </p></div><div class="sect3" title=";1"><div class="titlepage"><div><div><h4 class="title"><a id="tbsessionstore"></a><a class="ulink" href="" target="_top">;1</a></h4></div></div></div><p>
 This component subscribes to the Firefox <a class="ulink" href="" target="_top">sessionstore-state-write</a>
 observer event to filter out URLs from tabs loaded during Tor, to prevent them
 from being written to disk. To do this, it checks the
 <span class="command"><strong>__tb_tor_fetched</strong></span> tag of tab objects before writing them out. If
 the tag is from a blocked Tor state, the tab is not written to disk.  This is
 a rather expensive operation that involves potentially very large JSON
 evaluations and object tree traversals, but it preferable to replacing the
 Firefox session store with our own implementation, which is what was done in
 years past.
   </p></div><div class="sect3" title=";1"><div class="titlepage"><div><div><h4 class="title"><a id="refspoofer"></a><a class="ulink" href="" target="_top">;1</a></h4></div></div></div><p>
 This component handles optional referer spoofing for Torbutton. It implements a
 form of "smart" referer spoofing using <a class="ulink" href="" target="_top">http-on-modify-request</a>
 to modify the Referer header. The code sends the default browser referer
 header only if the destination domain is a suffix of the source, or if the
 source is a suffix of the destination. Otherwise, it sends no referer. This
 strange suffix logic is used as a heuristic: some rare sites on the web block
 requests without proper referer headers, and this logic is an attempt to cater
 to them. Unfortunately, it may not be enough. For example, will not
 send a referer to using this logic. Hence, it is off by default.
  </p></div><div class="sect3" title=";1 - components/cssblocker.js"><div class="titlepage"><div><div><h4 class="title"><a id="contentpolicy"></a><a class="ulink" href="" target="_top">;1
 - components/cssblocker.js</a></h4></div></div></div><p>This is a key component to Torbutton's security measures. When Tor is
 toggled, Javascript is disabled, and pages are instructed to stop loading.
 However, CSS is still able to perform network operations by loading styles for
 onmouseover events and other operations. In addition, favicons can still be
 loaded by the browser. The cssblocker component prevents this by implementing
 and registering an <a class="ulink" href="" target="_top">nsIContentPolicy</a>.
 When an nsIContentPolicy is registered, Firefox checks every attempted network
 request against its <a class="ulink" href="" target="_top">shouldLoad</a>
 member function to determine if the load should proceed. In Torbutton's case,
 the content policy looks up the appropriate browser tab using the <a class="link" href="#windowmapper" title=";1 - components/window-mapper.js">window mapper</a>,
 and checks that tab's load tag against the current Tor state. If the tab was
 loaded in a different state than the current state, the fetch is denied.
 Otherwise, it is allowed.</p> This helps to achieve the <a class="link" href="#isolation">Network
 Isolation</a> requirements of Torbutton.
 <p>In addition, the content policy also blocks website javascript from
 <a class="ulink" href="" target="_top">querying for
 versions and existence of extension chrome</a> while Tor is enabled, and
 also masks the presence of Torbutton to website javascript while Tor is
 disabled. </p><p>
 Finally, some of the work that logically belongs to the content policy is
 instead handled by the <span class="command"><strong>torbutton_http_observer</strong></span> and
 <span class="command"><strong>torbutton_weblistener</strong></span> in <a class="ulink" href="" target="_top">torbutton.js</a>. These two objects handle blocking of
 Firefox 3 favicon loads, popups, and full page plugins, which for whatever
 reason are not passed to the Firefox content policy itself (see Firefox Bugs 
 <a class="ulink" href="" target="_top">437014</a> and 
 <a class="ulink" href="" target="_top">401296</a>).
 This helps to fulfill both the <a class="link" href="#setpreservation">Anonymity Set Preservation</a> and the <a class="link" href="#undiscoverability">Tor Undiscoverability</a> requirements of
 Torbutton.</p></div></div></div><div class="sect1" title="3. Chrome"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2681735"></a>3. Chrome</h2></div></div></div><p>The chrome is where all the torbutton graphical elements and windows are
 located. </p><div class="sect2" title="3.1. XUL Windows and Overlays"><div class="titlepage"><div><div><h3 class="title"><a id="id2702019"></a>3.1. XUL Windows and Overlays</h3></div></div></div><p>
 Each window is described as an <a class="ulink" href="" target="_top">XML file</a>, with zero or more Javascript
 files attached. The scope of these Javascript files is their containing
 window. XUL files that add new elements and script to existing Firefox windows
 are called overlays.</p><div class="sect3" title="Browser Overlay - torbutton.xul"><div class="titlepage"><div><div><h4 class="title"><a id="browseroverlay"></a>Browser Overlay - <a class="ulink" href="" target="_top">torbutton.xul</a></h4></div></div></div><p>The browser overlay, torbutton.xul, defines the toolbar button, the status
 bar, and events for toggling the button. The overlay code is in <a class="ulink" href="" target="_top">chrome/content/torbutton.js</a>.
 It contains event handlers for preference update, shutdown, upgrade, and
 location change events.</p></div><div class="sect3" title="Preferences Window - preferences.xul"><div class="titlepage"><div><div><h4 class="title"><a id="id2704559"></a>Preferences Window - <a class="ulink" href="" target="_top">preferences.xul</a></h4></div></div></div><p>The preferences window of course lays out the Torbutton preferences, with
 handlers located in <a class="ulink" href="" target="_top">chrome/content/preferences.js</a>.</p></div><div class="sect3" title="Other Windows"><div class="titlepage"><div><div><h4 class="title"><a id="id2669673"></a>Other Windows</h4></div></div></div><p>There are additional windows that describe popups for right clicking on
 the status bar, the toolbutton, and the about page.</p></div></div><div class="sect2" title="3.2. Major Chrome Observers"><div class="titlepage"><div><div><h3 class="title"><a id="id2694797"></a>3.2. Major Chrome Observers</h3></div></div></div><p>
 In addition to the <a class="link" href="#components" title="2. Components">components described
 above</a>, Torbutton also instantiates several observers in the browser
 overlay window. These mostly grew due to scoping convenience, and many should
 probably be relocated into their own components.
  </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><span class="command"><strong>torbutton_window_pref_observer</strong></span><p>
 This is an observer that listens for Torbutton state changes, for the purposes
 of updating the Torbutton button graphic as the Tor state changes.
     </p></li><li class="listitem"><span class="command"><strong>torbutton_unique_pref_observer</strong></span><p>
 This is an observer that only runs in one window, called the main window. It
 listens for changes to all of the Torbutton preferences, as well as Torbutton
 controlled Firefox preferences. It is what carries out the toggle path when
 the proxy settings change. When the main window is closed, the
 torbutton_close_window event handler runs to dub a new window the "main
     </p></li><li class="listitem"><span class="command"><strong>tbHistoryListener</strong></span><p>
 The tbHistoryListener exists to prevent client window Javascript from
 interacting with window.history to forcibly navigate a user to a tab session
 history entry from a different Tor state. It also expunges the window.history
 entries during toggle. This listener helps Torbutton
 satisfy the <a class="link" href="#isolation">Network Isolation</a> requirement as
 well as the <a class="link" href="#state">State Separation</a> requirement.
     </p></li><li class="listitem"><span class="command"><strong>torbutton_http_observer</strong></span><p>
 The torbutton_http_observer performs some of the work that logically belongs
 to the content policy. This handles blocking of
 Firefox 3 favicon loads, which for whatever
 reason are not passed to the Firefox content policy itself (see Firefox Bugs
 <a class="ulink" href="" target="_top">437014</a> and
 <a class="ulink" href="" target="_top">401296</a>).
 The observer is also responsible for redirecting users to alternate
 search engines when Google presents them with a Captcha, as well as copying
 Google Captcha-related cookies between international Google domains.
     </p></li><li class="listitem"><span class="command"><strong>torbutton_proxyservice</strong></span><p>
 The Torbutton proxy service handles redirecting Torbutton-related update
 checks on through Tor. This is done to help satisfy the
 <a class="link" href="#undiscoverability">Tor Undiscoverability</a> requirement.
     </p></li><li class="listitem"><span class="command"><strong>torbutton_weblistener</strong></span><p>The <a class="ulink" href="" target="_top">location
 change</a> <a class="ulink" href="" target="_top">webprogress
 listener</a>, <span class="command"><strong>torbutton_weblistener</strong></span> is one of the most
 important parts of the chrome from a security standpoint. It is a <a class="ulink" href="" target="_top">webprogress
 listener</a> that handles receiving an event every time a page load or
 iframe load occurs. This class eventually calls down to
 <code class="function">torbutton_update_tags()</code> and
 <code class="function">torbutton_hookdoc()</code>, which apply the browser Tor load
 state tags, plugin permissions, and install the Javascript hooks to hook the
 <a class="ulink" href="" target="_top">window.screen</a>
 object to obfuscate browser and desktop resolution information.
 </p></li></ol></div></div></div><div class="sect1" title="4. Toggle Code Path"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2696524"></a>4. Toggle Code Path</h2></div></div></div><p>
 The act of toggling is connected to <code class="function">torbutton_toggle()</code>
 via the <a class="ulink" href="" target="_top">torbutton.xul</a>
 and <a class="ulink" href="" target="_top">popup.xul</a>
 overlay files. Most of the work in the toggling process is present in <a class="ulink" href="" target="_top">torbutton.js</a> 
 Toggling is a 3 stage process: Button Click, Proxy Update, and
 Settings Update. These stages are reflected in the prefs
 <span class="command"><strong>extensions.torbutton.tor_enabled</strong></span>,
 <span class="command"><strong>extensions.torbutton.proxies_applied</strong></span>, and
 <span class="command"><strong>extensions.torbutton.settings_applied</strong></span>. The reason for the
 three stage preference update is to ensure immediate enforcement of <a class="link" href="#isolation">Network Isolation</a> via the <a class="link" href="#contentpolicy" title=";1 - components/cssblocker.js">content policy</a>. Since the content window
 javascript runs on a different thread than the chrome javascript, it is
 important to properly convey the stages to the content policy to avoid race
 conditions and leakage, especially with <a class="ulink" href="" target="_top">Firefox Bug 
 409737</a> unfixed. The content policy does not allow any network activity
 whatsoever during this three stage transition.
  </p><div class="sect2" title="4.1. Button Click"><div class="titlepage"><div><div><h3 class="title"><a id="id2699452"></a>4.1. Button Click</h3></div></div></div><p>
 This is the first step in the toggling process. When the user clicks the
 toggle button or the toolbar, <code class="function">torbutton_toggle()</code> is
 called. This function checks the current Tor status by comparing the current
 proxy settings to the selected Tor settings, and then sets the proxy settings
 to the opposite state, and sets the pref
 <span class="command"><strong>extensions.torbutton.tor_enabled</strong></span> to reflect the new state.
 It is this proxy pref update that gives notification via the <a class="ulink" href="" target="_top">pref
 <span class="command"><strong>torbutton_unique_pref_observer</strong></span> to perform the rest of the
   </p></div><div class="sect2" title="4.2. Proxy Update"><div class="titlepage"><div><div><h3 class="title"><a id="id2697978"></a>4.2. Proxy Update</h3></div></div></div><p>
 When Torbutton receives any proxy change notifications via its
 <span class="command"><strong>torbutton_unique_pref_observer</strong></span>, it calls
 <code class="function">torbutton_set_status()</code> which checks against the Tor
 settings to see if the Tor proxy settings match the current settings. If so,
 it calls <code class="function">torbutton_update_status()</code>, which determines if
 the Tor state has actually changed, and sets
 <span class="command"><strong>extensions.torbutton.proxies_applied</strong></span> to the appropriate Tor
 state value, and ensures that
 <span class="command"><strong>extensions.torbutton.tor_enabled</strong></span> is also set to the correct
 value. This is decoupled from the button click functionality via the pref
 observer so that other addons (such as SwitchProxy) can switch the proxy
 settings between multiple proxies.
   </p></div><div class="sect2" title="4.3. Settings Update"><div class="titlepage"><div><div><h3 class="title"><a id="id2697015"></a>4.3. Settings Update</h3></div></div></div><p>
 The next stage is also handled by
 <code class="function">torbutton_update_status()</code>. This function sets scores of
 Firefox preferences, saving the original values to prefs under
 <span class="command"><strong>extensions.torbutton.saved.*</strong></span>, and performs the <a class="link" href="#cookiejar" title=";2 - components/cookie-jar-selector.js">cookie jarring</a>, state clearing (such as
 and DOM storage), and <a class="link" href="#preferences" title="4.4. Firefox preferences touched during Toggle">preference
 toggling</a>. At the
 end of its work, it sets
 <span class="command"><strong>extensions.torbutton.settings_applied</strong></span>, which signifies the
 completion of the toggle operation to the <a class="link" href="#contentpolicy" title=";1 - components/cssblocker.js">content policy</a>.
   </p></div><div class="sect2" title="4.4. Firefox preferences touched during Toggle"><div class="titlepage"><div><div><h3 class="title"><a id="preferences"></a>4.4. Firefox preferences touched during Toggle</h3></div></div></div><p>
 There are also a number of Firefox preferences set in
 <code class="function">torbutton_update_status()</code> that aren't governed by any
 Torbutton setting. These are:
 </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><a class="ulink" href="" target="_top"></a><p>
 Torbutton sets this setting to add ports 8123, 8118, 9050 and 9051 (which it
 reads from <span class="command"><strong>extensions.torbutton.banned_ports</strong></span>) to the list
 of ports Firefox is forbidden to access. These ports are Polipo, Privoxy, Tor,
 and the Tor control port, respectively. This is set for both Tor and Non-Tor
 usage, and prevents websites from attempting to do http fetches from these
 ports to see if they are open, which addresses the <a class="link" href="#undiscoverability">Tor Undiscoverability</a> requirement.
  </p></li><li class="listitem"><a class="ulink" href="" target="_top">browser.send_pings</a><p>
 This setting is currently always disabled. If anyone ever complains saying
 that they *want* their browser to be able to send ping notifications to a
 page or arbitrary link, I'll make this a pref or Tor-only. But I'm not holding
 my breath. I haven't checked if the content policy is called for pings, but if
 not, this setting helps with meeting the <a class="link" href="#isolation">Network
 Isolation</a> requirement.
  </p></li><li class="listitem"><a class="ulink" href="" target="_top">browser.safebrowsing.remoteLookups</a><p>
 Likewise for this setting. I find it hard to imagine anyone who wants to ask
 Google in real time if each URL they visit is safe, especially when the list
 of unsafe URLs is downloaded anyway. This helps fulfill the <a class="link" href="#disk">Disk Avoidance</a> requirement, by preventing your entire
 browsing history from ending up on Google's disks.
  </p></li><li class="listitem"><a class="ulink" href="" target="_top">browser.safebrowsing.enabled</a><p>
 Safebrowsing does <a class="ulink" href="" target="_top">unauthenticated
 updates under Firefox 2</a>, so it is disabled during Tor usage. 
 This helps fulfill the <a class="link" href="#updates">Update
 Safety</a> requirement. Firefox 3 has the fix for that bug, and so
 safebrowsing updates are enabled during Tor usage.
  </p></li><li class="listitem"><a class="ulink" href="" target="_top">network.protocol-handler.warn-external.(protocol)</a><p>
 If Tor is enabled, we need to prevent random external applications from
 launching without at least warning the user. This group of settings only
 partially accomplishes this, however. Applications can still be launched via
 plugins. The mechanisms for handling this are described under the "Disable
 Plugins During Tor Usage" preference. This helps fulfill the <a class="link" href="#proxy">Proxy Obedience</a> requirement, by preventing external
 applications from accessing network resources at the command of Tor-fetched
 pages. Unfortunately, due to <a class="link" href="#FirefoxBugs" title="6. Relevant Firefox Bugs">Firefox Bug</a>
 <a class="ulink" href="" target="_top">440892</a>,
 these prefs are no longer obeyed. They are set still anyway out of respect for
 the dead.
  </p></li><li class="listitem"><a class="ulink" href="" target="_top">browser.sessionstore.max_tabs_undo</a><p>
 To help satisfy the Torbutton <a class="link" href="#state">State Separation</a>
 and <a class="link" href="#isolation">Network Isolation</a> requirements,
 Torbutton needs to purge the Undo Tab history on toggle to prevent repeat
 "Undo Close" operations from accidentally restoring tabs from a different Tor
 State. This purge is accomplished by setting this preference to 0 and then
 restoring it to the previous user value upon toggle.
    </p></li><li class="listitem"><span class="command"><strong>security.enable_ssl2</strong></span> or <a class="ulink" href="" target="_top">nsIDOMCrypto::logout()</a><p>
 TLS Session IDs can persist for an indefinite duration, providing an
 identifier that is sent to TLS sites that can be used to link activity. This
 is particularly troublesome now that we have certificate verification in place
 in Firefox 3: The OCSP server can use this Session ID to build a history of
 TLS sites someone visits, and also correlate their activity as users move from
 network to network (such as home to work to coffee shop, etc), inside and
 outside of Tor. To handle this and to help satisfy our <a class="link" href="#state">State Separation Requirement</a>, we call the logout()
 function of nsIDOMCrypto. Since this may be absent, or may fail, we fall back
 to toggling
 <span class="command"><strong>security.enable_ssl2</strong></span>, which clears the SSL Session ID
 cache via the pref observer at <a class="ulink" href="" target="_top">nsNSSComponent.cpp</a>.
    </p></li><li class="listitem"><span class="command"><strong>security.OCSP.enabled</strong></span><p>
 Similarly, we toggle <span class="command"><strong>security.OCSP.enabled</strong></span>, which clears the OCSP certificate
 validation cache via the pref observer at <a class="ulink" href="" target="_top">nsNSSComponent.cpp</a>.
 In this way, exit nodes will not be able to fingerprint you
 based the fact that non-Tor OCSP lookups were obviously previously cached.
 To handle this and to help satisfy our <a class="link" href="#state">State Separation Requirement</a>,
    </p></li><li class="listitem"><span class="command"><strong><a class="ulink" href="" target="_top">extensions.e0204bd5-9d31-402b-a99d-a6aa8ffebdca.getAddons.cache.enabled</a></strong></span><p>
 We permanently disable addon usage statistic reporting to the statistics engine. These statistics send version
 information about Torbutton users via non-Tor, allowing their Tor use to be
 uncovered. Disabling this reporting helps Torbutton to satisfy its <a class="link" href="#undiscoverability">Tor Undiscoverability</a> requirement.
   </p></li><li class="listitem"><span class="command"><strong><a class="ulink" href="" target="_top">geo.enabled</a></strong></span><p>
 Torbutton disables Geolocation support in Firefox 3.5 and above whenever tor
 is enabled. This helps Torbutton maintain its
 <a class="link" href="#location">Location Neutrality</a> requirement.
 While Firefox does prompt before divulging geolocational information,
 the assumption is that Tor users will never want to give their
 location away during Tor usage, and even allowing websites to prompt
 them to do so will only cause confusion and accidents to happen. Moreover,
 just because users may approve a site to know their location in non-Tor mode
 does not mean they want it divulged during Tor mode.
    </p></li><li class="listitem"><span class="command"><strong><a class="ulink" href="" target="_top">browser.zoom.siteSpecific</a></strong></span><p>
 Firefox actually remembers your zoom settings for certain sites. CSS
 and Javascript rule can use this to recognize previous visitors to a site.
 This helps Torbutton fulfill its <a class="link" href="#state">State Separation</a>
    </p></li><li class="listitem"><span class="command"><strong><a class="ulink" href="" target="_top">network.dns.disablePrefetch</a></strong></span><p>
 Firefox 3.5 and above implement prefetching of DNS resolution for hostnames in
 links on a page to decrease page load latency. While Firefox does typically
 disable this behavior when proxies are enabled, we set this pref for added
 safety during Tor usage. Additionally, to prevent Tor-loaded tabs from having
 their links prefetched after a toggle to Non-Tor mode occurs,
 we also set the docShell attribute
 <a class="ulink" href="" target="_top">
 allowDNSPrefetch</a> to false on Tor loaded tabs. This happens in the same
 positions in the code as those for disabling plugins via the allowPlugins
 docShell attribute. This helps Torbutton fulfill its <a class="link" href="#isolation">Network Isolation</a> requirement.
    </p></li><li class="listitem"><span class="command"><strong><a class="ulink" href="" target="_top">browser.cache.offline.enable</a></strong></span><p>
 Firefox has the ability to store web applications in a special cache to allow
 them to continue to operate while the user is offline. Since this subsystem
 is actually different than the normal disk cache, it must be dealt with
 separately. Thus, Torbutton sets this preference to false whenever Tor is
 enabled. This helps Torbutton fulfill its <a class="link" href="#disk">Disk
 Avoidance</a> and <a class="link" href="#state">State Separation</a>
    </p></li></ol></div></div></div><div class="sect1" title="5. Description of Options"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2702702"></a>5. Description of Options</h2></div></div></div><p>This section provides a detailed description of Torbutton's options. Each
 option is presented as the string from the preferences window, a summary, the
 preferences it touches, and the effect this has on the components, chrome, and
 browser properties.</p><div class="sect2" title="5.1. Proxy Settings"><div class="titlepage"><div><div><h3 class="title"><a id="id2704948"></a>5.1. Proxy Settings</h3></div></div></div><div class="sect3" title="Test Settings"><div class="titlepage"><div><div><h4 class="title"><a id="id2683681"></a>Test Settings</h4></div></div></div><p>
 This button under the Proxy Settings tab provides a way to verify that the 
 proxy settings are correct, and actually do route through the Tor network. It
 performs this check by issuing an <a class="ulink" href="" target="_top">XMLHTTPRequest</a>
 for <a class="ulink" href="" target="_top"></a>.
 This is a special page that returns very simple, yet well-formed XHTML that
 Torbutton can easily inspect for a hidden link with an id of
 <span class="command"><strong>TorCheckResult</strong></span> and a target of <span class="command"><strong>success</strong></span>
 or <span class="command"><strong>failure</strong></span> to indicate if the
 user hit the page from a Tor IP, a non-Tor IP. This check is handled in
 <code class="function">torbutton_test_settings()</code> in <a class="ulink" href="" target="_top">torbutton.js</a>.
 Presenting the results to the user is handled by the <a class="ulink" href="" target="_top">preferences
 callback <code class="function">torbutton_prefs_test_settings()</code> in <a class="ulink" href="" target="_top">preferences.js</a>.  
   </p></div></div><div class="sect2" title="5.2. Dynamic Content Settings"><div class="titlepage"><div><div><h3 class="title"><a id="id2686645"></a>5.2. Dynamic Content Settings</h3></div></div></div><div class="sect3" title="Disable plugins on Tor Usage (crucial)"><div class="titlepage"><div><div><h4 class="title"><a id="plugins"></a>Disable plugins on Tor Usage (crucial)</h4></div></div></div><p>Option: <span class="command"><strong>extensions.torbutton.no_tor_plugins</strong></span></p><p>Java and plugins <a class="ulink" href="" target="_top">can query</a> the <a class="ulink" href="" target="_top">local IP
 address</a> and report it back to the
 remote site. They can also <a class="ulink" href="" target="_top">bypass proxy settings</a> and directly connect to a
 remote site without Tor. Every browser plugin we have tested with Firefox has
 some form of network capability, and every one ignores proxy settings or worse - only
 partially obeys them. This includes but is not limited to:
 QuickTime, Windows Media Player, RealPlayer, mplayerplug-in, AcroRead, and
 Enabling this preference causes the above mentioned Torbutton chrome web progress
  listener <span class="command"><strong>torbutton_weblistener</strong></span> to disable Java via <span class="command"><strong>security.enable_java</strong></span> and to disable
  plugins via the browser <a class="ulink" href="" target="_top">docShell</a>
  attribute <span class="command"><strong>allowPlugins</strong></span>. These flags are set every time a new window is
  created (<code class="function">torbutton_tag_new_browser()</code>), every time a web
 event occurs
  (<code class="function">torbutton_update_tags()</code>), and every time the tor state is changed
  (<code class="function">torbutton_update_status()</code>). As a backup measure, plugins are also
  prevented from loading by the content policy in <a class="ulink" href="" target="_top">;1</a> if Tor is
  enabled and this option is set.
  </p><p>All of this turns out to be insufficient if the user directly clicks
 on a plugin-handled mime-type. <a class="ulink" href="" target="_top">In this case</a>,
 the browser decides that maybe it should ignore all these other settings and
 load the plugin anyways, because maybe the user really did want to load it
 (never mind this same load-style could happen automatically  with meta-refresh
 or any number of other ways..). To handle these cases, Torbutton stores a list
 of plugin-handled mime-types, and sets the pref
 <span class="command"><strong>plugin.disable_full_page_plugin_for_types</strong></span> to this list.
 Additionally, (since nothing can be assumed when relying on Firefox
 preferences and internals) if it detects a load of one of them from the web
 progress listener, it cancels the request, tells the associated DOMWindow to
 stop loading, clears the document, AND throws an exception. Anything short of
 all this and the plugin managed to find some way to load.
  All this could be avoided, of course, if Firefox would either <a class="ulink" href="" target="_top">obey
  allowPlugins</a> for directly visited URLs, or notify its content policy for such
  loads either <a class="ulink" href="" target="_top">via</a> <a class="ulink" href="" target="_top">shouldProcess</a> or shouldLoad. The fact that it does not is
  not very encouraging.
 Since most plugins completely ignore browser proxy settings, the actions
 performed by this setting are crucial to satisfying the <a class="link" href="#proxy">Proxy Obedience</a> requirement.
  </p></div><div class="sect3" title="Isolate Dynamic Content to Tor State (crucial)"><div class="titlepage"><div><div><h4 class="title"><a id="id2688604"></a>Isolate Dynamic Content to Tor State (crucial)</h4></div></div></div><p>Option: <span class="command"><strong>extensions.torbutton.isolate_content</strong></span></p><p>Enabling this preference is what enables the <a class="ulink" href="" target="_top">;1</a> content policy
 mentioned above, and causes it to block content load attempts in pages an
 opposite Tor state from the current state. Freshly loaded <a class="ulink" href="" target="_top">browser
 tabs</a> are tagged
 with a <span class="command"><strong>__tb_load_state</strong></span> member in
 <code class="function">torbutton_update_tags()</code> and this
 value is compared against the current tor state in the content policy.</p><p>It also kills all Javascript in each page loaded under that state by
 toggling the <span class="command"><strong>allowJavascript</strong></span> <a class="ulink" href="" target="_top">docShell</a> property, and issues a
 <a class="ulink" href="" target="_top">webNavigation.stop(webNavigation.STOP_ALL)</a> to each browser tab (the
 equivalent of hitting the STOP button).</p><p>
 Unfortunately, <a class="ulink" href="" target="_top">Firefox bug
 409737</a> prevents <span class="command"><strong>docShell.allowJavascript</strong></span> from killing
 all event handlers, and event handlers registered with <a class="ulink" href="" target="_top">addEventListener()</a>
 are still able to execute. The <a class="link" href="#contentpolicy" title=";1 - components/cssblocker.js">Torbutton Content
 Policy</a> should prevent such code from performing network activity within
 the current tab, but activity that happens via a popup window or via a
 Javascript redirect can still slip by. For this reason, Torbutton blocks
 popups by checking for a valid <a class="ulink" href="" target="_top">window.opener</a>
 attribute in <code class="function">torbutton_check_progress()</code>. If the window
 has an opener from a different Tor state, its load is blocked. The content
 policy also takes similar action to prevent Javascript redirects. This also
 has the side effect/feature of preventing the user from following any links
 from a page loaded in an opposite Tor state.
 This setting is responsible for satisfying the <a class="link" href="#isolation">Network Isolation</a> requirement.
 </p></div><div class="sect3" title="Hook Dangerous Javascript"><div class="titlepage"><div><div><h4 class="title"><a id="jshooks"></a>Hook Dangerous Javascript</h4></div></div></div><p>Option: <span class="command"><strong>extensions.torbutton.kill_bad_js</strong></span></p><p>This setting enables injection of the <a class="ulink" href="" target="_top">Javascript
 hooking code</a>. This is done in the chrome in
 <code class="function">torbutton_hookdoc()</code>, which is called ultimately by both the 
 <a class="ulink" href="" target="_top">webprogress
 listener</a> <span class="command"><strong>torbutton_weblistener</strong></span> and the <a class="link" href="#contentpolicy" title=";1 - components/cssblocker.js">content policy</a> (the latter being a hack to handle
 javascript: urls).
 In the Firefox 2 days, this option did a lot more than
 it does now. It used to be responsible for timezone and improved useragent
 spoofing, and history object cloaking. However, now it only provides
 obfuscation of the <a class="ulink" href="" target="_top">window.screen</a>
 object to mask your browser and desktop resolution.
 The resolution hooks
 effectively make the Firefox browser window appear to websites as if the renderable area
 takes up the entire desktop, has no toolbar or other GUI element space, and
 the desktop itself has no toolbars.
 These hooks drastically reduce the amount of information available to do <a class="link" href="#fingerprinting">anonymity set reduction attacks</a> and help to
 meet the <a class="link" href="#setpreservation">Anonymity Set Preservation</a>
 requirements. Unfortunately, Gregory Fleischer discovered it is still possible
 to retrieve the original screen values by using <a class="ulink" href="" target="_top">XPCNativeWrapper</a>
 or <a class="ulink" href="" target="_top">Components.lookupMethod</a>.
 We are still looking for a workaround as of Torbutton 1.3.2.
 </p></div><div class="sect3" title="Resize windows to multiples of 50px during Tor usage (recommended)"><div class="titlepage"><div><div><h4 class="title"><a id="id2663307"></a>Resize windows to multiples of 50px during Tor usage (recommended)</h4></div></div></div><p>Option: <span class="command"><strong>extensions.torbutton.resize_windows</strong></span></p><p>
 This option drastically cuts down on the number of distinct anonymity sets
 that divide the Tor web userbase. Without this setting, the dimensions for a
 typical browser window range from 600-1200 horizontal pixels and 400-1000
 vertical pixels, or about 600x600 = 360000 different sets. Resizing the
 browser window to multiples of 50 on each side reduces the number of sets by
 50^2, bringing the total number of sets to 144. Of course, the distribution
 among these sets are not uniform, but scaling by 50 will improve the situation
 due to this non-uniformity for users in the less common resolutions.
 Obviously the ideal situation would be to lie entirely about the browser
 window size, but this will likely cause all sorts of rendering issues, and is
 also not implementable in a foolproof way from extension land.
 The implementation of this setting is spread across a couple of different
 locations in the Torbutton javascript <a class="link" href="#browseroverlay" title="Browser Overlay - torbutton.xul">browser
 overlay</a>. Since resizing minimized windows causes them to be restored,
 and since maximized windows remember their previous size to the pixel, windows
 must be resized before every document load (at the time of browser tagging)
 via <code class="function">torbutton_check_round()</code>, called by
 <code class="function">torbutton_update_tags()</code>. To prevent drift, the extension
 tracks the original values of the windows and uses this to perform the
 rounding on document load. In addition, to prevent the user from resizing a
 window to a non-50px multiple, a resize listener
 (<code class="function">torbutton_do_resize()</code>) is installed on every new browser
 window to record the new size and round it to a 50px multiple while Tor is
 enabled. In all cases, the browser's contentWindow.innerWidth and innerHeight
 are set. This ensures that there is no discrepancy between the 50 pixel cutoff
 and the actual renderable area of the browser (so that it is not possible to
 infer toolbar size/presence by the distance to the nearest 50 pixel roundoff).
 This setting helps to meet the <a class="link" href="#setpreservation">Anonymity Set Preservation</a> requirements.
 </p></div><div class="sect3" title="Disable Search Suggestions during Tor (recommended)"><div class="titlepage"><div><div><h4 class="title"><a id="id2663391"></a>Disable Search Suggestions during Tor (recommended)</h4></div></div></div><p>Option: <span class="command"><strong>extensions.torbutton.no_search</strong></span></p><p>
 This setting causes Torbutton to disable <a class="ulink" href="" target="_top"><span class="command"><strong></strong></span></a>
 during Tor usage.
 This governs if you get Google search suggestions during Tor
 usage. Your Google cookie is transmitted with google search suggestions, hence
 this is recommended to be disabled.
 While this setting doesn't satisfy any Torbutton requirements, the fact that
 cookies are transmitted for partially typed queries does not seem desirable
 for Tor usage.
 </p></div><div class="sect3" title="Disable Updates During Tor"><div class="titlepage"><div><div><h4 class="title"><a id="id2663430"></a>Disable Updates During Tor</h4></div></div></div><p>Option: <span class="command"><strong>extensions.torbutton.no_updates</strong></span></p><p>This setting causes Torbutton to disable the four <a class="ulink" href="" target="_top">Firefox
 update settings</a> during Tor
   usage: <span class="command"><strong>extensions.update.enabled</strong></span>,
 <span class="command"><strong>app.update.enabled</strong></span>,
   <span class="command"><strong></strong></span>, and
 <span class="command"><strong></strong></span>.  These prevent the
   browser from updating extensions, checking for Firefox upgrades, and
   checking for search plugin updates while Tor is enabled.
 This setting satisfies the <a class="link" href="#updates">Update Safety</a> requirement.
 </p></div><div class="sect3" title="Redirect Torbutton Updates Via Tor (recommended)"><div class="titlepage"><div><div><h4 class="title"><a id="id2663492"></a>Redirect Torbutton Updates Via Tor (recommended)</h4></div></div></div><p>Option: <span class="command"><strong>extensions.torbutton.update_torbutton_via_tor</strong></span></p><p>This setting causes Torbutton to install an
 <a class="ulink" href="" target="_top">nsIProtocolProxyFilter</a>
 in order to redirect all version update checks and Torbutton update downloads
 via Tor, regardless of if Tor is enabled or not. This was done both to address
 concerns about data retention done by <a class="ulink" href="" target="_top"></a>, as well as to
 help censored users meet the <a class="link" href="#undiscoverability">Tor
 Undiscoverability</a> requirement.
   </p></div><div class="sect3" title="Disable livemarks updates during Tor usage (recommended)"><div class="titlepage"><div><div><h4 class="title"><a id="id2663536"></a>Disable livemarks updates during Tor usage (recommended)</h4></div></div></div><p>Option:
    </p><table border="0" summary="Simple list" class="simplelist"><tr><td><span class="command"><strong>extensions.torbutton.disable_livemarks</strong></span></td></tr></table><p>
 This option causes Torbutton to prevent Firefox from loading <a class="ulink" href="" target="_top">Livemarks</a> during
 Tor usage. Because people often have very personalized Livemarks (such as RSS
 feeds of Wikipedia articles they maintain, etc). This is accomplished both by
 <a class="link" href="#livemarks" title=";2 - components/block-livemarks.js">wrapping the livemark-service component</a> and
 by calling stopUpdateLivemarks() on the <a class="ulink" href=";2" target="_top">Livemark
 service</a> when Tor is enabled.
 This helps satisfy the <a class="link" href="#isolation">Network
 Isolation</a> and <a class="link" href="#setpreservation">Anonymity Set
 Preservation</a> requirements.
 </p></div><div class="sect3" title="Block Tor/Non-Tor access to network from file:// urls (recommended)"><div class="titlepage"><div><div><h4 class="title"><a id="id2663607"></a>Block Tor/Non-Tor access to network from file:// urls (recommended)</h4></div></div></div><p>Options:
    </p><table border="0" summary="Simple list" class="simplelist"><tr><td><span class="command"><strong>extensions.torbutton.block_tor_file_net</strong></span></td></tr><tr><td><span class="command"><strong>extensions.torbutton.block_nontor_file_net</strong></span></td></tr></table><p>
 These settings prevent file urls from performing network operations during the
 respective Tor states. Firefox 2's implementation of same origin policy allows
 file urls to read and <a class="ulink" href="" target="_top">submit
 arbitrary files from the local filesystem</a> to arbitrary websites. To
 make matters worse, the 'Content-Disposition' header can be injected
 arbitrarily by exit nodes to trick users into running arbitrary html files in
 the local context. These preferences cause the <a class="link" href="#contentpolicy" title=";1 - components/cssblocker.js">content policy</a> to block access to any network
 resources from File urls during the appropriate Tor state.
 This preference helps to ensure Tor's <a class="link" href="#isolation">Network
 Isolation</a> requirement, by preventing file urls from executing network
 operations in opposite Tor states. Also, allowing pages to submit arbitrary
 files to arbitrary sites just generally seems like a bad idea.
 </p></div><div class="sect3" title="Close all Tor/Non-Tor tabs and windows on toggle (optional)"><div class="titlepage"><div><div><h4 class="title"><a id="id2663679"></a>Close all Tor/Non-Tor tabs and windows on toggle (optional)</h4></div></div></div><p>Options:
    </p><table border="0" summary="Simple list" class="simplelist"><tr><td><span class="command"><strong>extensions.torbutton.close_nontor</strong></span></td></tr><tr><td><span class="command"><strong>extensions.torbutton.close_tor</strong></span></td></tr></table><p>
 These settings cause Torbutton to enumerate through all windows and close all
 tabs in each window for the appropriate Tor state. This code can be found in
 <code class="function">torbutton_update_status()</code>.  The main reason these settings
 exist is as a backup mechanism in the event of any Javascript or content policy
 leaks due to <a class="ulink" href="" target="_top">Firefox Bug
 409737</a>.  Torbutton currently tries to block all Javascript network
 activity via the content policy, but until that bug is fixed, there is some
 risk that there are alternate ways to bypass the policy. This option is
 available as an extra assurance of <a class="link" href="#isolation">Network
 Isolation</a> for those who would like to be sure that when Tor is toggled
 all page activity has ceased. It also serves as a potential future workaround
 in the event a content policy failure is discovered, and provides an additional
 level of protection for the <a class="link" href="#disk">Disk Avoidance</a>
 protection so that browser state is not sitting around waiting to be swapped
 out longer than necessary.
 While this setting doesn't satisfy any Torbutton requirements, the fact that
 cookies are transmitted for partially typed queries does not seem desirable
 for Tor usage.
 </p></div></div><div class="sect2" title="5.3. History and Forms Settings"><div class="titlepage"><div><div><h3 class="title"><a id="id2705261"></a>5.3. History and Forms Settings</h3></div></div></div><div class="sect3" title="Isolate Access to History navigation to Tor state (crucial)"><div class="titlepage"><div><div><h4 class="title"><a id="id2705267"></a>Isolate Access to History navigation to Tor state (crucial)</h4></div></div></div><p>Option: <span class="command"><strong>extensions.torbutton.block_js_history</strong></span></p><p>
 This setting determines if Torbutton installs an <a class="ulink" href="" target="_top">nsISHistoryListener</a>
 attached to the <a class="ulink" href="" target="_top">sessionHistory</a> of 
 of each browser's <a class="ulink" href="" target="_top">webNavigatator</a>.
 The nsIShistoryListener is instantiated with a reference to the containing
 browser window and blocks the back, forward, and reload buttons on the browser
 navigation bar when Tor is in an opposite state than the one to load the
 current tab. In addition, Tor clears the session history during a new document
 load if this setting is enabled. 
 This is marked as a crucial setting in part
 because Javascript access to the history object is indistinguishable from 
 user clicks, and because
 <a class="ulink" href="" target="_top">Firefox Bug
 409737</a> allows javascript to execute in opposite Tor states, javascript
 can issue reloads after Tor toggle to reveal your original IP. Even without
 this bug, however, Javascript is still able to access previous pages in your
 session history that may have been loaded under a different Tor state, to
 attempt to correlate your activity.
 This setting helps to fulfill Torbutton's <a class="link" href="#state">State
 Separation</a> and (until Bug 409737 is fixed) <a class="link" href="#isolation">Network Isolation</a>
    </p></div><div class="sect3" title="History Access Settings"><div class="titlepage"><div><div><h4 class="title"><a id="id2705344"></a>History Access Settings</h4></div></div></div><p>Options:
   </p><table border="0" summary="Simple list" class="simplelist"><tr><td><span class="command"><strong>extensions.torbutton.block_thread</strong></span></td></tr><tr><td><span class="command"><strong>extensions.torbutton.block_nthread</strong></span></td></tr><tr><td><span class="command"><strong>extensions.torbutton.block_thwrite</strong></span></td></tr><tr><td><span class="command"><strong>extensions.torbutton.block_nthwrite</strong></span></td></tr></table><p>
   </p><p>On Firefox 3.x, these four settings govern the behavior of the <a class="ulink" href="" target="_top">components/ignore-history.js</a>
 history blocker component mentioned above. By hooking the browser's view of
 the history itself via the <a class="ulink" href=";2" target="_top">;2</a>
 and <a class="ulink" href=";1" target="_top">;1</a>
 components, this mechanism defeats all document-based <a class="ulink" href="" target="_top">history disclosure
 attacks</a>, including <a class="ulink" href="" target="_top">CSS-only attacks</a>.
 The component also hooks functions involved in writing history to disk via
 both the <a class="ulink" href="" target="_top">Places
 Database</a> and the older Firefox 2 mechanisms.
 On Firefox 4, Mozilla finally <a class="ulink" href="" target="_top">addressed
 these issues</a>, so we can effectively ignore the "read" pair of the
 above prefs. We then only need to link the write prefs to
 <span class="command"><strong>places.history.enabled</strong></span>, which disabled writing to the
 history store while set.
 This setting helps to satisfy the <a class="link" href="#state">State Separation</a> and <a class="link" href="#disk">Disk Avoidance</a> requirements.
 </p></div><div class="sect3" title="Clear History During Tor Toggle (optional)"><div class="titlepage"><div><div><h4 class="title"><a id="id2705472"></a>Clear History During Tor Toggle (optional)</h4></div></div></div><p>Option: <span class="command"><strong>extensions.torbutton.clear_history</strong></span></p><p>This setting governs if Torbutton calls
 <a class="ulink" href="" target="_top">nsIBrowserHistory.removeAllPages</a>
 and <a class="ulink" href="" target="_top">nsISHistory.PurgeHistory</a>
 for each tab on Tor toggle.</p><p>
 This setting is an optional way to help satisfy the <a class="link" href="#state">State Separation</a> requirement.
 </p></div><div class="sect3" title="Block Password+Form saving during Tor/Non-Tor"><div class="titlepage"><div><div><h4 class="title"><a id="id2705515"></a>Block Password+Form saving during Tor/Non-Tor</h4></div></div></div><p>Options:
   </p><table border="0" summary="Simple list" class="simplelist"><tr><td><span class="command"><strong>extensions.torbutton.block_tforms</strong></span></td></tr><tr><td><span class="command"><strong>extensions.torbutton.block_ntforms</strong></span></td></tr></table><p>
   </p><p>These settings govern if Torbutton disables
 <span class="command"><strong>browser.formfill.enable</strong></span>
 and <span class="command"><strong>signon.rememberSignons</strong></span> during Tor and Non-Tor usage.
 Since form fields can be read at any time by Javascript, this setting is a lot
 more important than it seems.
 This setting helps to satisfy the <a class="link" href="#state">State Separation</a> and <a class="link" href="#disk">Disk Avoidance</a> requirements.
 </p></div></div><div class="sect2" title="5.4. Cache Settings"><div class="titlepage"><div><div><h3 class="title"><a id="id2705577"></a>5.4. Cache Settings</h3></div></div></div><div class="sect3" title="Block Tor disk cache and clear all cache on Tor Toggle"><div class="titlepage"><div><div><h4 class="title"><a id="id2705582"></a>Block Tor disk cache and clear all cache on Tor Toggle</h4></div></div></div><p>Option: <span class="command"><strong>extensions.torbutton.clear_cache</strong></span>
   </p><p>This option causes Torbutton to call <a class="ulink" href="" target="_top">nsICacheService.evictEntries(0)</a>
 on Tor toggle to remove all entries from the cache. In addition, this setting
 causes Torbutton to set <a class="ulink" href="" target="_top">browser.cache.disk.enable</a> to false.
 This setting helps to satisfy the <a class="link" href="#state">State Separation</a> and <a class="link" href="#disk">Disk Avoidance</a> requirements.
 </p></div><div class="sect3" title="Block disk and memory cache during Tor"><div class="titlepage"><div><div><h4 class="title"><a id="id2705632"></a>Block disk and memory cache during Tor</h4></div></div></div><p>Option: <span class="command"><strong>extensions.torbutton.block_cache</strong></span></p><p>This setting
 causes Torbutton to set <a class="ulink" href="" target="_top">browser.cache.memory.enable</a>,
 <a class="ulink" href="" target="_top">browser.cache.disk.enable</a> and
 <a class="ulink" href="" target="_top">network.http.use-cache</a> to false during tor usage.
 This setting helps to satisfy the <a class="link" href="#state">State Separation</a> and <a class="link" href="#disk">Disk Avoidance</a> requirements.
 </p></div></div><div class="sect2" title="5.5. Cookie and Auth Settings"><div class="titlepage"><div><div><h3 class="title"><a id="id2705686"></a>5.5. Cookie and Auth Settings</h3></div></div></div><div class="sect3" title="Clear Cookies on Tor Toggle"><div class="titlepage"><div><div><h4 class="title"><a id="id2705691"></a>Clear Cookies on Tor Toggle</h4></div></div></div><p>Option: <span class="command"><strong>extensions.torbutton.clear_cookies</strong></span>
 This setting causes Torbutton to call <a class="ulink" href="" target="_top">nsICookieManager.removeAll()</a> on
 every Tor toggle. In addition, this sets <a class="ulink" href="" target="_top">network.cookie.lifetimePolicy</a>
 to 2 for Tor usage, which causes all cookies to be demoted to session cookies,
 which prevents them from being written to disk. 
 This setting helps to satisfy the <a class="link" href="#state">State Separation</a> and <a class="link" href="#disk">Disk Avoidance</a> requirements.
 </p></div><div class="sect3" title="Store Non-Tor cookies in a protected jar"><div class="titlepage"><div><div><h4 class="title"><a id="id2705742"></a>Store Non-Tor cookies in a protected jar</h4></div></div></div><p>Option: <span class="command"><strong>extensions.torbutton.cookie_jars</strong></span>
 This setting causes Torbutton to use <a class="ulink" href="" target="_top">;2</a> to store
 non-tor cookies in a cookie jar during Tor usage, and clear the Tor cookies
 before restoring the jar.
 This setting also sets <a class="ulink" href="" target="_top">network.cookie.lifetimePolicy</a>
 to 2 for Tor usage, which causes all cookies to be demoted to session cookies,
 which prevents them from being written to disk. 
 This setting helps to satisfy the <a class="link" href="#state">State Separation</a> and <a class="link" href="#disk">Disk Avoidance</a> requirements.
 </p></div><div class="sect3" title="Store both Non-Tor and Tor cookies in a protected jar (dangerous)"><div class="titlepage"><div><div><h4 class="title"><a id="id2705799"></a>Store both Non-Tor and Tor cookies in a protected jar (dangerous)</h4></div></div></div><p>Option: <span class="command"><strong>extensions.torbutton.dual_cookie_jars</strong></span>
 This setting causes Torbutton to use <a class="ulink" href="" target="_top">;2</a> to store
 both Tor and Non-Tor cookies into protected jars.
 This setting helps to satisfy the <a class="link" href="#state">State Separation</a> requirement.
 </p></div><div class="sect3" title="Manage My Own Cookies (dangerous)"><div class="titlepage"><div><div><h4 class="title"><a id="id2705841"></a>Manage My Own Cookies (dangerous)</h4></div></div></div><p>Options: None</p><p>This setting disables all Torbutton cookie handling by setting the above
 cookie prefs all to false.</p></div><div class="sect3" title="Disable DOM Storage during Tor usage (crucial)"><div class="titlepage"><div><div><h4 class="title"><a id="id2705856"></a>Disable DOM Storage during Tor usage (crucial)</h4></div></div></div><div class="sect3" title="Do not write Tor/Non-Tor cookies to disk"><div class="titlepage"><div><div><h4 class="title"><a id="id2705859"></a>Do not write Tor/Non-Tor cookies to disk</h4></div></div></div><p>Options:
   </p><table border="0" summary="Simple list" class="simplelist"><tr><td><span class="command"><strong>extensions.torbutton.tor_memory_jar</strong></span></td></tr><tr><td><span class="command"><strong>extensions.torbutton.nontor_memory_jar</strong></span></td></tr></table><p>
 These settings (contributed by arno) cause Torbutton to set <a class="ulink" href="" target="_top">network.cookie.lifetimePolicy</a>
 to 2 during the appropriate Tor state, and to store cookies acquired in that
 state into a Javascript
 <a class="ulink" href="" target="_top">E4X</a>
 object as opposed to writing them to disk.
 This allows Torbutton to provide an option to preserve a user's 
 cookies while still satisfying the <a class="link" href="#disk">Disk Avoidance</a>
 </p></div><p>Option: <span class="command"><strong>extensions.torbutton.disable_domstorage</strong></span>
 This setting causes Torbutton to toggle <span class="command"><strong></strong></span> during Tor
 usage to prevent 
 <a class="ulink" href="" target="_top">DOM Storage</a> from
   being used to store persistent information across Tor states.</p><p>
 This setting helps to satisfy the <a class="link" href="#state">State Separation</a> requirement.
 </p></div><div class="sect3" title="Clear HTTP Auth on Tor Toggle (recommended)"><div class="titlepage"><div><div><h4 class="title"><a id="id2705960"></a>Clear HTTP Auth on Tor Toggle (recommended)</h4></div></div></div><p>Option: <span class="command"><strong>extensions.torbutton.clear_http_auth</strong></span>
 This setting causes Torbutton to call <a class="ulink" href="" target="_top">nsIHttpAuthManager.clearAll()</a>
 every time Tor is toggled.
 This setting helps to satisfy the <a class="link" href="#state">State Separation</a> requirement.
 </p></div></div><div class="sect2" title="5.6. Startup Settings"><div class="titlepage"><div><div><h3 class="title"><a id="id2705999"></a>5.6. Startup Settings</h3></div></div></div><div class="sect3" title="On Browser Startup, set Tor state to: Tor, Non-Tor"><div class="titlepage"><div><div><h4 class="title"><a id="id2706004"></a>On Browser Startup, set Tor state to: Tor, Non-Tor</h4></div></div></div><p>Options:
    <span class="command"><strong>extensions.torbutton.restore_tor</strong></span>
   </p><p>This option governs what Tor state tor is loaded in to.
 <code class="function">torbutton_set_initial_state()</code> covers the case where the
 browser did not crash, and <code class="function">torbutton_crash_recover()</code>
 covers the case where the <a class="link" href="#crashobserver" title=";1">crash observer</a>
 detected a crash.
 Since the Tor state after a Firefox crash is unknown/indeterminate, this
 setting helps to satisfy the <a class="link" href="#state">State Separation</a>
 requirement in the event of Firefox crashes by ensuring all cookies,
 settings and saved sessions are reloaded from a fixed Tor state.
 </p></div><div class="sect3" title="Prevent session store from saving Non-Tor/Tor-loaded tabs"><div class="titlepage"><div><div><h4 class="title"><a id="id2706055"></a>Prevent session store from saving Non-Tor/Tor-loaded tabs</h4></div></div></div><p>Options: 
   </p><table border="0" summary="Simple list" class="simplelist"><tr><td><span class="command"><strong>extensions.torbutton.nonontor_sessionstore</strong></span></td></tr><tr><td><span class="command"><strong>extensions.torbutton.notor_sessionstore</strong></span></td></tr></table><p>
   </p><p>If these options are enabled, the <a class="link" href="#tbsessionstore" title=";1">tbSessionStore.js</a> component uses the session
 store listeners to filter out the appropriate tabs before writing the session
 store data to disk.
 This setting helps to satisfy the <a class="link" href="#disk">Disk Avoidance</a>
 requirement, and also helps to satisfy the <a class="link" href="#state">State Separation</a> requirement in the event of Firefox
 </p></div></div><div class="sect2" title="5.7. Shutdown Settings"><div class="titlepage"><div><div><h3 class="title"><a id="id2706113"></a>5.7. Shutdown Settings</h3></div></div></div><div class="sect3" title="Clear cookies on Tor/Non-Tor shutdown"><div class="titlepage"><div><div><h4 class="title"><a id="id2706119"></a>Clear cookies on Tor/Non-Tor shutdown</h4></div></div></div><p>Option: <span class="command"><strong>extensions.torbutton.shutdown_method</strong></span>
   </p><p> This option variable can actually take 3 values: 0, 1, and 2. 0 means no
 cookie clearing, 1 means clear only during Tor-enabled shutdown, and 2 means
 clear for both Tor and Non-Tor shutdown. When set to 1 or 2, Torbutton listens
 for the <a class="ulink" href="" target="_top">quit-application-granted</a> event in
 <a class="link" href="#crashobserver" title=";1">crash-observer.js</a> and use <a class="ulink" href="" target="_top">;2</a>
 to clear out all cookies and all cookie jars upon shutdown.
 This setting helps to satisfy the <a class="link" href="#state">State Separation</a> requirement.
 </p></div></div><div class="sect2" title="5.8. Header Settings"><div class="titlepage"><div><div><h3 class="title"><a id="id2706173"></a>5.8. Header Settings</h3></div></div></div><div class="sect3" title="Set user agent during Tor usage (crucial)"><div class="titlepage"><div><div><h4 class="title"><a id="id2706179"></a>Set user agent during Tor usage (crucial)</h4></div></div></div><p>Options:
    </p><table border="0" summary="Simple list" class="simplelist"><tr><td><span class="command"><strong>extensions.torbutton.set_uagent</strong></span></td></tr><tr><td><span class="command"><strong>extensions.torbutton.platform_override</strong></span></td></tr><tr><td><span class="command"><strong>extensions.torbutton.oscpu_override</strong></span></td></tr><tr><td><span class="command"><strong>extensions.torbutton.buildID_override</strong></span></td></tr><tr><td><span class="command"><strong>extensions.torbutton.productsub_override</strong></span></td></tr><tr><td><span class="command"><strong>extensions.torbutton.appname_override</strong></span></td></tr><tr><td><span class="command"><strong>extensions.torbutton.appversion_override</strong></span></td></tr><tr><td><span class="command"><strong>extensions.torbutton.useragent_override</strong></span></td></tr><tr><td><span class="command"><strong>extensions.torbutton.useragent_vendor</strong></span></td></tr><tr><td><span class="command"><strong>extensions.torbutton.useragent_vendorSub</strong></span></td></tr></table><p>
    </p><p>On face, user agent switching appears to be straight-forward in Firefox.
 It provides several options for controlling the browser user agent string:
 <span class="command"><strong>general.appname.override</strong></span>,
 <span class="command"><strong>general.appversion.override</strong></span>,
 <span class="command"><strong>general.platform.override</strong></span>,
 <span class="command"><strong>general.oscpu.override</strong></span>,
 <span class="command"><strong>general.productSub.override</strong></span>,
 <span class="command"><strong>general.buildID.override</strong></span>,
 <span class="command"><strong>general.useragent.override</strong></span>,
 <span class="command"><strong>general.useragent.vendor</strong></span>, and
 <span class="command"><strong>general.useragent.vendorSub</strong></span>. If
 the Torbutton preference <span class="command"><strong>extensions.torbutton.set_uagent</strong></span> is
 true, Torbutton copies all of the other above prefs into their corresponding
 browser preferences during Tor usage.</p><p>
 It also turns out that it is possible to detect the original Firefox version
 by <a class="ulink" href="" target="_top">inspecting
 certain resource:// files</a>. These cases are handled by Torbutton's
 <a class="link" href="#contentpolicy" title=";1 - components/cssblocker.js">content policy</a>.
 This setting helps to satisfy the <a class="link" href="#setpreservation">Anonymity Set Preservation</a> requirement.
 </p></div><div class="sect3" title="Spoof US English Browser"><div class="titlepage"><div><div><h4 class="title"><a id="id2706353"></a>Spoof US English Browser</h4></div></div></div><p>Options:
 </p><table border="0" summary="Simple list" class="simplelist"><tr><td><span class="command"><strong>extensions.torbutton.spoof_english</strong></span></td></tr><tr><td><span class="command"><strong>extensions.torbutton.spoof_charset</strong></span></td></tr><tr><td><span class="command"><strong>extensions.torbutton.spoof_language</strong></span></td></tr></table><p>
 </p><p> This option causes Torbutton to set
 <span class="command"><strong>general.useragent.locale</strong></span>
 <span class="command"><strong>intl.accept_languages</strong></span> to the value specified in
 <span class="command"><strong>extensions.torbutton.spoof_locale</strong></span>,
 <span class="command"><strong>extensions.torbutton.spoof_charset</strong></span> and
 <span class="command"><strong>extensions.torbutton.spoof_language</strong></span> during Tor usage, as
 well as hooking <span class="command"><strong>navigator.language</strong></span> via its <a class="link" href="#jshooks" title="Hook Dangerous Javascript">javascript hooks</a>.
 This setting helps to satisfy the <a class="link" href="#setpreservation">Anonymity Set Preservation</a> and <a class="link" href="#location">Location Neutrality</a> requirements.
 </p></div><div class="sect3" title="Referer Spoofing Options"><div class="titlepage"><div><div><h4 class="title"><a id="id2706446"></a>Referer Spoofing Options</h4></div></div></div><p>Option: <span class="command"><strong>extensions.torbutton.refererspoof</strong></span>
 This option variable has three values. If it is 0, "smart" referer spoofing is
 enabled. If it is 1, the referer behaves as normal. If it is 2, no referer is
 sent. The default value is 1. The smart referer spoofing is implemented by the
 <a class="link" href="#refspoofer" title=";1">torRefSpoofer</a> component.
 This setting also does not directly satisfy any Torbutton requirement, but
 some may desire to mask their referer for general privacy concerns.
 </p></div><div class="sect3" title="Strip platform and language off of Google Search Box queries"><div class="titlepage"><div><div><h4 class="title"><a id="id2706480"></a>Strip platform and language off of Google Search Box queries</h4></div></div></div><p>Option: <span class="command"><strong>extensions.torbutton.fix_google_srch</strong></span>
 This option causes Torbutton to use the <a class="ulink" href="" target="_top">;1</a>
 component to wrap the Google search plugin. On many platforms, notably Debian
 and Ubuntu, the Google search plugin is set to reveal a lot of language and
 platform information. This setting strips off that info while Tor is enabled.
 This setting helps Torbutton to fulfill its <a class="link" href="#setpreservation">Anonymity Set Preservation</a> requirement.
 </p></div><div class="sect3" title="Automatically use an alternate search engine when presented with a Google Captcha"><div class="titlepage"><div><div><h4 class="title"><a id="id2706521"></a>Automatically use an alternate search engine when presented with a
 Google Captcha</h4></div></div></div><p>Options:
 </p><table border="0" summary="Simple list" class="simplelist"><tr><td><span class="command"><strong>extensions.torbutton.asked_google_captcha</strong></span></td></tr><tr><td><span class="command"><strong>extensions.torbutton.dodge_google_captcha</strong></span></td></tr><tr><td><span class="command"><strong>extensions.torbutton.google_redir_url</strong></span></td></tr></table><p>
 Google's search engine has rate limiting features that cause it to
 <a class="ulink" href="" target="_top">present
 captchas</a> and sometimes even outright ban IPs that issue large numbers
 of search queries, especially if a lot of these queries appear to be searching
 for software vulnerabilities or unprotected comment areas.
 Despite multiple discussions with Google, we were unable to come to a solution
 or any form of compromise that would reduce the number of captchas and
 outright bans seen by Tor users issuing regular queries.
 As a result, we've implemented this option as an <a class="ulink" href="" target="_top">'http-on-modify-request'</a>
 http observer to optionally redirect banned or captcha-triggering Google
 queries to search engines that do not rate limit Tor users. The current
 options are,,, and These are
 encoded in the preferences
 <span class="command"><strong>extensions.torbutton.redir_url.[1-5]</strong></span>.
 </p></div><div class="sect3" title="Store SSL/CA Certs in separate jars for Tor/Non-Tor (recommended)"><div class="titlepage"><div><div><h4 class="title"><a id="id2706601"></a>Store SSL/CA Certs in separate jars for Tor/Non-Tor (recommended)</h4></div></div></div><p>Options:
 </p><table border="0" summary="Simple list" class="simplelist"><tr><td><span class="command"><strong>extensions.torbutton.jar_certs</strong></span></td></tr><tr><td><span class="command"><strong>extensions.torbutton.jar_ca_certs</strong></span></td></tr></table><p>
 These settings govern if Torbutton attempts to isolate the user's SSL
 certificates into separate jars for each Tor state. This isolation is
 implemented in <code class="function">torbutton_jar_certs()</code> in <a class="ulink" href="" target="_top">chrome/content/torbutton.js</a>,
 which calls <code class="function">torbutton_jar_cert_type()</code> and
 <code class="function">torbutton_unjar_cert_type()</code> for each certificate type in
 the <a class="ulink" href=";1" target="_top">;1</a>.
 Certificates are deleted from and imported to the <a class="ulink" href=";1" target="_top">;1</a>.
 The first time this pref is used, a backup of the user's certificates is
 created in their profile directory under the name
 <code class="filename">cert8.db.bak</code>. This file can be copied back to
 <code class="filename">cert8.db</code> to fully restore the original state of the
 user's certificates in the event of any error.
 Since exit nodes and malicious sites can insert content elements sourced to
 specific SSL sites to query if a user has a certain certificate,
 this setting helps to satisfy the <a class="link" href="#state">State
 Separation</a> requirement of Torbutton. Unfortunately, <a class="ulink" href="" target="_top">Firefox Bug
 435159</a> prevents it from functioning correctly in the event of rapid Tor toggle, so it
 is currently not exposed via the preferences UI.
 </p></div></div></div><div class="sect1" title="6. Relevant Firefox Bugs"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="FirefoxBugs"></a>6. Relevant Firefox Bugs</h2></div></div></div><p>
 Future releases of Torbutton are going to be designed around supporting only
 <a class="ulink" href="" target="_top">Tor
 Browser Bundle</a>, which greatly simplifies the number and nature of Firefox
 bugs we must fix. This allows us to abandon the complexities of <a class="link" href="#state">State
 Separation</a> and <a class="link" href="#isolation">Network Isolation</a> requirements
 associated with the Toggle Model.
   </p><div class="sect2" title="6.1. Tor Browser Bugs"><div class="titlepage"><div><div><h3 class="title"><a id="TorBrowserBugs"></a>6.1. Tor Browser Bugs</h3></div></div></div><p>
 The list of Firefox patches we must create to improve privacy on the
 Tor Browser Bundle are collected in the Tor Bug Tracker under <a class="ulink" href="" target="_top">ticket
 #2871</a>. These bugs are also applicable to the Toggle Model, and
 should be considered higher priority than all Toggle Model specific bugs
    </p></div><div class="sect2" title="6.2. Toggle Model Bugs"><div class="titlepage"><div><div><h3 class="title"><a id="ToggleModelBugs"></a>6.2. Toggle Model Bugs</h3></div></div></div><p>
 In addition to the Tor Browser bugs, the Torbutton Toggle Model suffers from
 additional bugs specific to the need to isolate state across the toggle.
 Toggle model bugs are considered a lower priority than the bugs against the
 Tor Browser model.
    </p><div class="sect3" title="Bugs impacting security"><div class="titlepage"><div><div><h4 class="title"><a id="FirefoxSecurity"></a>Bugs impacting security</h4></div></div></div><p>
 Torbutton has to work around a number of Firefox bugs that impact its
 security. Most of these are mentioned elsewhere in this document, but they
 have also been gathered here for reference. In order of decreasing severity,
 they are:
    </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><a class="ulink" href="" target="_top">Bug 435159 -
 nsNSSCertificateDB::DeleteCertificate has race conditions</a><p>
 In Torbutton 1.2.0rc1, code was added to attempt to isolate SSL certificates
 the user has installed. Unfortunately, the method call to delete a certificate
 from the current certificate database acts lazily: it only sets a variable
 that marks a cert for deletion later, and it is not cleared if that
 certificate is re-added. This means that if the Tor state is toggled quickly,
 that certificate could remain present until it is re-inserted (causing an
 error dialog), and worse, it would still be deleted after that.  The lack of
 this functionality is considered a Torbutton security bug because cert
 isolation is considered a <a class="link" href="#state">State Separation</a>
       </p></li><li class="listitem">Give more visibility into and control over TLS
 There are several <a class="ulink" href="" target="_top">TLS issues
 impacting Torbutton security</a>. It is not clear if these should be one
 Firefox bug or several, but in particular we need better control over various
 aspects of TLS connections. Firefox currently provides no observer capable of
 extracting TLS parameters or certificates early enough to cancel a TLS
 request. We would like to be able to provide <a class="ulink" href="" target="_top">HTTPS-Everywhere</a> users with
 the ability to <a class="ulink" href="" target="_top">have
 their certificates audited</a> by a <a class="ulink" href="" target="_top">Perspectives</a>-style set of
 notaries. The problem with this is that the API observer points do not exist
 for any Firefox addon to actually block authentication token submission over a
 TLS channel, so every addon to date (including Perspectives) is actually
 providing users with notification *after* their authentication tokens have
 already been compromised. This obviously needs to be fixed.
      </p></li><li class="listitem"><a class="ulink" href="" target="_top">Bug 122752 - SOCKS
 Username/Password Support</a><p>
 We need <a class="ulink" href="" target="_top">Firefox
 APIs</a> or about:config settings to control the SOCKS Username and
 Password fields. The reason why we need this support is to utilize an (as yet
 unimplemented) scheme to separate Tor traffic based <a class="ulink" href="" target="_top">on
 SOCKS username/password</a>.
     </p></li><li class="listitem"><a class="ulink" href="" target="_top">Bug 409737 -
 javascript.enabled and docShell.allowJavascript do not disable all event
 This bug allows pages to execute javascript via addEventListener and perhaps
 other callbacks. In order to prevent this bug from enabling an attacker to
 break the <a class="link" href="#isolation">Network Isolation</a> requirement,
 Torbutton 1.1.13 began blocking popups and history manipulation from different
 Tor states.  So long as there are no ways to open popups or redirect the user
 to a new page, the <a class="link" href="#contentpolicy" title=";1 - components/cssblocker.js">Torbutton content
 policy</a> should block Javascript network access. However, if there are
 ways to open popups or perform redirects such that Torbutton cannot block
 them, pages may still have free reign to break that requirement and reveal a
 user's original IP address.
      </p></li><li class="listitem"><a class="ulink" href="" target="_top">Bug 448743 -
 Decouple general.useragent.locale from spoofing of navigator.language</a><p>
 Currently, Torbutton spoofs the <span class="command"><strong>navigator.language</strong></span>
 attribute via <a class="link" href="#jshooks" title="Hook Dangerous Javascript">Javascript hooks</a>. Unfortunately,
 these do not work on Firefox 3. It would be ideal to have
 a pref to set this value (something like a
 <span class="command"><strong>general.useragent.override.locale</strong></span>),
 to avoid fragmenting the anonymity set of users of foreign locales. This issue
 impedes Torbutton from fully meeting its <a class="link" href="#setpreservation">Anonymity Set Preservation</a>
 requirement on Firefox 3.
      </p></li></ol></div></div><div class="sect3" title="Bugs blocking functionality"><div class="titlepage"><div><div><h4 class="title"><a id="FirefoxWishlist"></a>Bugs blocking functionality</h4></div></div></div><p>
 The following bugs impact Torbutton and similar extensions' functionality.
    </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><a class="ulink" href="" target="_top">Bug 629820 - nsIContentPolicy::shouldLoad not
 called for web request in Firefox Mobile</a><p>
 The new <a class="ulink" href="" target="_top">Electrolysis</a>
 multiprocess system appears to have some pretty rough edge cases with respect
 to registering XPCOM category managers such as the nsIContentPolicy, which
 make it difficult to do a straight-forward port of Torbutton or
 HTTPS-Everywhere to Firefox Mobile.  It probably also has similar issues with
 wrapping existing <a class="link" href="#hookedxpcom" title="2.1. Hooked Components">Firefox XPCOM components</a>,
 which will also cause more problems for porting Torbutton.
     </p></li><li class="listitem"><a class="ulink" href="" target="_top">Bug 417869 -
 Browser context is difficult to obtain from many XPCOM callbacks</a><p>
 It is difficult to determine which tabbrowser many XPCOM callbacks originate
 from, and in some cases absolutely no context information is provided at all.
 While this doesn't have much of an effect on Torbutton, it does make writing
 extensions that would like to do per-tab settings and content filters (such as
 FoxyProxy) difficult to impossible to implement securely.
    </p></li></ol></div></div><div class="sect3" title="Low Priority Bugs"><div class="titlepage"><div><div><h4 class="title"><a id="FirefoxMiscBugs"></a>Low Priority Bugs</h4></div></div></div><p>
 The following bugs have an effect upon Torbutton, but are superseded by more
 practical and more easily fixable variant bugs above; or have stable, simple
   </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><a class="ulink" href="" target="_top">Bug 440892 -
 network.protocol-handler.warn-external are ignored</a><p>
 Sometime in the Firefox 3 development cycle, the preferences that governed
 warning a user when external apps were launched got disconnected from the code
 that does the launching. Torbutton depended on these prefs to prevent websites
 from launching specially crafted documents and application arguments that
 caused Proxy Bypass. We currently work around this issue by <a class="link" href="#appblocker" title=";1 ,;1, and;1 - components/external-app-blocker.js">wrapping the app launching components</a> to present a
 popup before launching external apps while Tor is enabled. While this works,
 it would be nice if these prefs were either fixed or removed.
      </p></li><li class="listitem"><a class="ulink" href="" target="_top">Bug 437014 -
 nsIContentPolicy::shouldLoad no longer called for favicons</a><p>
 Firefox 3.0 stopped calling the shouldLoad call of content policy for favicon
 loads. Torbutton had relied on this call to block favicon loads for opposite
 Tor states. The workaround it employs for Firefox 3 is to cancel the request
 when it arrives in the <span class="command"><strong>torbutton_http_observer</strong></span> used for
 blocking full page plugin loads. This seems to work just fine, but is a bit
     </p></li><li class="listitem"><a class="ulink" href="" target="_top">Bug 309524</a>
 and <a class="ulink" href="" target="_top">Bug
 380556</a> - nsIContentPolicy::shouldProcess is not called.
 This is a call that would be useful to develop a better workaround for the
 allowPlugins issue above. If the content policy were called before a URL was
 handed over to a plugin or helper app, it would make the workaround for the
 above allowPlugins bug a lot cleaner. Obviously this bug is not as severe as
 the others though, but it might be nice to have this API as a backup.
      </p></li><li class="listitem"><a class="ulink" href="" target="_top">Bug 401296 - docShell.allowPlugins
 not honored for direct links</a> (Perhaps subset of <a class="ulink" href="" target="_top">Bug 282106</a>?)
 Similar to the javascript plugin disabling attribute, the plugin disabling
 attribute is also not perfect — it is ignored for direct links to plugin
 handled content, as well as meta-refreshes to plugin handled content.  This
 requires Torbutton to listen to a number of different http events to intercept
 plugin-related mime type URLs and cancel their requests. Again, since plugins
 are quite horrible about obeying proxy settings, loading a plugin pretty much
 ensures a way to break the <a class="link" href="#isolation">Network Isolation</a>
 requirement and reveal a user's original IP address. Torbutton's code to
 perform this workaround has been subverted at least once already by Kyle
      </p></li></ol></div></div></div></div><div class="sect1" title="7. Testing"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="TestPlan"></a>7. 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
 is that it will be useful both for creating a "Tor Safety Check"
 page, and for developing novel tests and actively attacking Torbutton with the
 goal of finding vulnerabilities in either it or the Mozilla components,
 interfaces and settings upon which it relies.
   </p><div class="sect2" title="7.1. Single state testing"><div class="titlepage"><div><div><h3 class="title"><a id="SingleStateTesting"></a>7.1. Single state testing</h3></div></div></div><p>
 Torbutton is a complicated piece of software. During development, changes to
 one component can affect a whole slough of unrelated features.  A number of
 aggregated test suites exist that can be used to test for regressions in
 Torbutton and to help aid in the development of Torbutton-like addons and
 other privacy modifications of other browsers. Some of these test suites exist
 as a single automated page, while others are a series of pages you must visit
 individually. They are provided here for reference and future regression
 testing, and also in the hope that some brave soul will one day decide to
 combine them into a comprehensive automated test suite.
      </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><a class="ulink" href="" target="_top"></a><p> is the canonical source of plugin and external-application based
 proxy-bypass exploits. It is a fully automated test suite maintained by <a class="ulink" href="" target="_top">HD Moore</a> as a service for people to
 use to test their anonymity systems.
        </p></li><li class="listitem"><a class="ulink" href="" target="_top"></a><p> is another automated test suite that tests for proxy bypass
 and other information disclosure vulnerabilities. It is maintained by Kyle
 Williams, the author of <a class="ulink" href="" target="_top">JanusVM</a>
 and <a class="ulink" href="" target="_top">JanusPA</a>.
        </p></li><li class="listitem"><a class="ulink" href="" target="_top">JonDos
 The <a class="ulink" href="" target="_top">JonDos people</a> also provide an
 anonymity tester. It is more focused on HTTP headers than plugin bypass, and
 points out a couple of headers Torbutton could do a better job with
        </p></li><li class="listitem"><a class="ulink" href="" target="_top"></a><p> provides a tremendous collection of browser fingerprinting and
 general privacy tests. Unfortunately they are only available one page at a
 time, and there is not really solid feedback on good vs bad behavior in
 the test results.
        </p></li><li class="listitem"><a class="ulink" href="" target="_top">Privacy
 The Privacy Analyzer provides a dump of all sorts of browser attributes and
 settings that it detects, including some information on your origin IP
 address. Its page layout and lack of good vs bad test result feedback makes it
 not as useful as a user-facing testing tool, but it does provide some
 interesting checks in a single page.
        </p></li><li class="listitem"><a class="ulink" href="" target="_top">Mr. T</a><p>
 Mr. T is a collection of browser fingerprinting and deanonymization exploits
 discovered by the <a class="ulink" href="" target="_top"></a> crew
 and others. It is also not as user friendly as some of the above tests, but it
 is a useful collection.
        </p></li><li class="listitem">Gregory Fleischer's <a class="ulink" href="" target="_top">Torbutton</a> and
 <a class="ulink" href="" target="_top">Defcon
 17</a> Test Cases
 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
        </p></li><li class="listitem"><a class="ulink" href="" target="_top">Xenobite's
 TorCheck Page</a><p>
 This page checks to ensure you are using a valid Tor exit node and checks for
 some basic browser properties related to privacy. It is not very fine-grained
 or complete, but it is automated and could be turned into something useful
 with a bit of work.
     </p></div><div class="sect2" title="7.2. Multi-state testing"><div class="titlepage"><div><div><h3 class="title"><a id="id2707624"></a>7.2. Multi-state testing</h3></div></div></div><p>
 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.
    </p><div class="sect3" title="Cookies and Cache Correlation"><div class="titlepage"><div><div><h4 class="title"><a id="id2707636"></a>Cookies and Cache Correlation</h4></div></div></div><p>
 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 <a class="ulink" href="" target="_top">store unique
 identifiers</a>. The default settings of Torbutton should also protect
 against these from persisting across Tor Toggle.
     </p></div><div class="sect3" title="Javascript timers and event handlers"><div class="titlepage"><div><div><h4 class="title"><a id="id2707658"></a>Javascript timers and event handlers</h4></div></div></div><p>
 Javascript can set timers and register event handlers in the hopes of fetching
 URLs after the user has toggled Torbutton. 
     </p></div><div class="sect3" title="CSS Popups and non-script Dynamic Content"><div class="titlepage"><div><div><h4 class="title"><a id="id2707671"></a>CSS Popups and non-script Dynamic Content</h4></div></div></div><p>
 Even if Javascript is disabled, CSS is still able to 
 <a class="ulink" href="" target="_top">create popup-like
 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.
     </p></div></div><div class="sect2" title="7.3. Active testing (aka How to Hack Torbutton)"><div class="titlepage"><div><div><h3 class="title"><a id="HackTorbutton"></a>7.3. Active testing (aka How to Hack Torbutton)</h3></div></div></div><p>
 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 <a class="link" href="#requirements" title="1.2. Torbutton Requirements">its requirements</a>. 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
    </p><div class="sect3" title="Some suggested vectors to investigate"><div class="titlepage"><div><div><h4 class="title"><a id="id2707726"></a>Some suggested vectors to investigate</h4></div></div></div><p>
     </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem">Strange ways to register Javascript <a class="ulink" href="" target="_top">events</a> and <a class="ulink" href="" target="_top">timeouts</a> should
 be verified to actually be ineffective after Tor has been toggled.</li><li class="listitem">Other ways to cause Javascript to be executed after
 <span class="command"><strong>javascript.enabled</strong></span> has been toggled off.</li><li class="listitem">Odd ways to attempt to load plugins. Kyle Williams has had
 some success with direct loads/meta-refreshes of plugin-handled URLs.</li><li class="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 <a class="ulink" href="" target="_top">same-origin and
 non-same-origin</a> domains.</li><li class="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.</li><li class="listitem">Similarly, is there any way to confuse the <a class="link" href="#contentpolicy" title=";1 - components/cssblocker.js">content policy</a>
 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? </li><li class="listitem">Alternate ways to store and fetch unique identifiers. For example, <a class="ulink" href="" target="_top">DOM Storage</a>
 caught us off guard. 
 It was
 also discovered by <a class="ulink" href="" target="_top">Gregory
 Fleischer</a> that <a class="ulink" href="" target="_top">content window access to
 chrome</a> can be used to build <a class="link" href="#fingerprinting">unique
 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?
      </li><li class="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.</li><li class="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?</li><li class="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).