tor-webwml.git

@@ -0,0 +1,120 @@

+- Investigation of Privacy Mode:

+  - Good:

+    - Cookies Cleared+memory only

+    - Cache cleared and memory-only

+    - History not available via javascript or CSS

+    - Safe because currently unsupported:

+      - Geolocation not supported in browser

+      - DOM Storage not supported

+      - HTML5 Storage not supported

+    - Http auth is cleared

+    - Do they have a session store?

+      - Yes. It is disabled.

+    - Form history disabled

+      - But non-private entries still available

+    - Malware and phishing protection

+      - Per-url check?

+        - Doesn't seem like it..

+  - Bad:

+    - RLZ Identifier sent with all queries even in Incognito mode

+      - http://www.google.com/support/chrome/bin/answer.py?hl=en&answer=107684

+    - Flash cookies not cleared

+    - Google gears are still available

+      - Do they have their own storage?

+        - Yes. Completely ignores private mode.

+    - Safebrowsing API key not cleared?

+      - but updates may not happen "under" the incognito window

+    - Desktop resolution available

+    - Browser resolution is available

+    - SSL session keys

+      - Not cleared!

+      - They clear trusted certs tho

+    - Timezone not spoofed

+

+- Misc Features we definitely need:

+  - Incognito-specific proxy settings

+    - Browser proxy settings currently do not apply immediately

+  - Plugin enable/disable controls

+  - Spoof user agent

+  - Referer alteration API

+  - Autolaunching of remote apps needs to be disabled

+  - API to opt-out of all the opt-in tracking for incognito mode

+  - Cookie API would be nice

+  - Need network.security.ports.banned

+    - http://www.remote.org/jochen/sec/hfpa/hfpa.pdf

+  - Resize windows (content-window side possibly ok)

+

+- Future investigation

+  - Non-private form history still available

+    - Forms seem to not be auto-filled, but this may be different

+      for some fields?

+  - How evil is google update? will it happen over incognito?

+    - http://en.wikipedia.org/wiki/Google_Updater#Google_Updater

+    - http://en.wikipedia.org/wiki/SRWare_Iron#Differences_from_Chrome

+    - http://foliovision.com/2008/12/09/adwords-ppc-organic-rlz/

+  - Test in more detail with sysinternals for disk writes

+  - What about safebrowsing requests? Can they bypass proxy?

+  - Video tag supports H264 and ogg via ffmpeg

+    - Hrmm.. proxy bypass ability?

+

+- Test results. Used Incognito Mode with the test suites from:

+  https://www.torproject.org/torbutton/design/#SingleStateTesting

+  - Decloak.net:

+    - Recovers IP and DNS via Java

+    - Recovers IP via flash

+  - Deanonymizer.com

+    - Failed NNTP and FTP quicktime

+  - JohnDo's hated some headers

+  - Mr. T got a lot of shit wrong...

+  - http://labs.isecpartners.com/breadcrumbs/breadcrumbs.html

+

+- Comparison with Torora

+  - http://github.com/mwenge/torora/tree/master/doc/DESIGN.torora

+  - Good ideas for both chrome and torbutton:

+    - Cache/Cookie expiry every 24hrs

+    - Random preturbation on Date() object..

+      - No longer possible without js hooks :/

+      - Possible if Chrome allows non-delatable shadowing of window.Date()

+        from user scripts. ECMA says it should

+

+==========================================

+

+- Incognito Issues:

+  - SSL session keys

+    - Not cleared!

+  - Flash cookies not cleared

+    - Better Privacy? Permissions?

+  - Google gears are still available

+    - Do they have their own storage?

+      - Yes. Completely ignores private mode.

+  - RLZ override/disable for incognito

+  - Opt out of opt-in tracking?

+  - Source code:

+    http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/profile.cc

+

+- Privacy Enhancing API Wishlist (remove existing items):

+  - http://code.google.com/chrome/extensions/devguide.html

+  - Prefs (copy-on-write for incognito mode)

+    - Incognito-specific proxy settings

+      - Should not be used for safebrowsing or app/addon update

+    - pref to disable autolaunch of apps/warn user

+    - network.security.ports.banned

+    - User agent (that also govern navigator.*)

+      - could be done (better) via http headers and good hook support

+  - Core APIs:

+    - Per-Plugin enable/disable controls

+    - Cookie API

+    - Cache control

+    - HTTP header alteration ("on-modify-request")

+      - Referrer, accept, user agent

+  - Javascript hooks:

+    - http://code.google.com/chrome/extensions/content_scripts.html

+      - Bleh, these suck... Too limited.

+    - ECMA compliance

+    - desktop+screen resolution

+    - Date hooking

+    - navigator.* hooking

+

+- Posted at:

+  - http://groups.google.com/group/chromium-extensions/t/ceba26ca9e2f6a78

+

@@ -0,0 +1,195 @@

+First pass: Quick Review of Firefox Features

+- Video Tag

+  - Docs:

+    - https://developer.mozilla.org/En/HTML/Element/Audio

+    - https://developer.mozilla.org/En/HTML/Element/Video

+    - https://developer.mozilla.org/En/HTML/Element/Source

+    - https://developer.mozilla.org/En/Manipulating_video_using_canvas

+    - https://developer.mozilla.org/En/nsIDOMHTMLMediaElement

+    - https://developer.mozilla.org/En/Media_formats_supported_by_the_audio_and_video_elements

+    - http://en.flossmanuals.net/TheoraCookbook

+  - nsIContentPolicy is checked on load

+  - Uses NSIChannels for initial load

+  - Wrapped in nsHTMLMediaElement::mDecoder

+    - is nsOggDecoder() or nsWaveDecoder()

+    - liboggplay

+  - Governed by media.* prefs

+  - Preliminary audit shows they do not use the liboggplay tcp functions

+- Geolocation

+  - Wifi:

+    - https://developer.mozilla.org/En/Monitoring_WiFi_access_points

+    - Requires security policy to allow. Then still prompted

+  - navigator.geolocation

+    - Governed by geo.enabled

+    - "2 week access token" is set

+      - geo.wifi.access_token.. Clearing is prob a good idea

+    - http://mxr.mozilla.org/mozilla1.9.1/source/dom/src/geolocation/NetworkGeolocationProvider.js

+    - https://developer.mozilla.org/En/Using_geolocation

+- DNS prefetching after toggle

+  - prefetch pref? Always disable for now?

+    - network.dns.disablePrefetch

+    - Also disabled in netwerk/dns/src/nsDNSService2.cpp when manual proxies

+      are set..

+    - This should prevent prefetching of non-tor urls in tor mode..

+    - But the reverse is unclear.

+    - DocShell attribute!!1 YAY

+      - http://www.oxymoronical.com/experiments/apidocs/interface/nsIDocShell

+      - "Takes effect for the NEXT document loaded...."

+        - Do we win this race? hrmm.. If we do, the tor->nontor direction

+          should also be safe.

+  - Content policy called?

+    - No. See content/html/content/src/nsHTMLDNSPrefetch.cpp

+- Storage

+  - https://developer.mozilla.org/en/Storage

+  - "It is available to trusted callers, meaning extensions and Firefox

+    components only."

+- New content policy

+  - Content Security Policy. Addon-only

+- "Offline resources"

+  - https://developer.mozilla.org/en/Offline_resources_in_Firefox

+  - https://developer.mozilla.org/en/nsIApplicationCache

+  - browser.cache.offline.enable toggles

+  - browser.cache.disk.enable does not apply. Seperate "device".

+  - Does our normal cache clearing mechanism apply?

+    - We call nsICacheService.evictEntries()

+    - May need: nsOfflineCacheDevice::EvictEntries(NULL)

+  - Code is smart enough to behave cleanly if we simply set

+    browser.cache.offline.enable or enable private browsing.

+- Mouse gesture and other new DOM events

+- Fonts

+  - Remote fonts obey content policy. Good.

+  - XXX: Are they cached independent of regular cache? Prob not.

+  - Hrmm can probe for installed fonts:

+    http://remysharp.com/2008/07/08/how-to-detect-if-a-font-is-installed-only-using-javascript/

+    http://www.lalit.org/lab/javascript-css-font-detect

+    http://www.ajaxupdates.com/cssjavascript-font-detector/

+    http://code.google.com/p/jquery-fontavailable/

+- Drag and drop

+  - https://developer.mozilla.org/En/DragDrop/Drag_and_Drop

+  - https://developer.mozilla.org/En/DragDrop/Drag_Operations

+  - https://developer.mozilla.org/En/DragDrop/Dragging_and_Dropping_Multiple_Items

+  - https://developer.mozilla.org/En/DragDrop/Recommended_Drag_Types

+  - https://developer.mozilla.org/En/DragDrop/DataTransfer

+  - Should be no different than normal url handling..

+- Local Storage

+  - https://developer.mozilla.org/en/DOM/Storage#localStorage

+  - Disabled by dom storage pref..

+  - Private browsing mode has its own DB

+    - Memory only?

+  - Disk Avoidance of gStorage and local storage:

+    - mSessionOnly set via nsDOMStorage::CanUseStorage()

+      - Seems to be set to true if cookies are session-only or private

+        browsing mode

+        - Our cookies are NOT session-only with dual cookie jars

+          - but this is ok if we clear the session storage..

+            - XXX: Technically clearing session storage may break

+              sites if cookies remain though

+      - nsDOMStoragePersistentDB not used if mSessionOnly

+  - Can clear with nsDOMStorage::ClearAll() or nsIDOMStorage2::clear()?

+    - These only work for a particular storage. There's both global now

+      and per-origin storage instances

+    - Each docshell has tons of storages for each origin contained in it

+    - Toggling dom.storage.enabled does not clear existing storage

+    - Oh HOT! cookie-changed to clear cookies clears all storages!

+      - happens for both ff3.0 and 3.5 in dom/src/storage/nsDOMStorage.cpp

+  - Conclusion:

+    - can safely enable dom storage

+      - May have minor buggy usability issues unless we preserve it

+        when user is preserving cookies..

+

+Second Pass: Verification of all Torbutton Assumptions

+- "Better privacy controls"

+  - Basically UI stuff for prefs we set already

+  - address bar search disable option is interesting, but not

+    torbutton's job to toggle. Users will hate us.

+- Private browsing

+  - https://developer.mozilla.org/En/Supporting_private_browsing_mode

+    - We should consider an option (off by default) to enable PBM during

+      toggle

+      - It is a good idea because it will let our users use DOM storage

+        safely and also may cause their plugins and other addons to be

+        safe

+      - Doing it always will cause the user to lose fine-grained control

+        of many settings

+        - Also we'll need to prevent them from leaving without toggling tor

+        - Stuff the emit does (grep for NS_PRIVATE_BROWSING_SWITCH_TOPIC and

+          "private-browsing")

+          - XXX:  clear mozilla.org/security/sdr;1. We should too! Wtf is it??

+            - Neg. Best to let them handle this. Users will be annoyed

+              at having to re-enter their passwords..

+          - They also clear the console service..

+          - Recommend watching private-browsing-cancel-vote and blocking if

+            we are performing a db operation

+            - Maybe we want to block transitions during our toggle for safety

+          - XXX: They also clear general.open_location.last_url

+          - XXX: mozilla.org/permissionmanager

+          - XXX: mozilla.org/content-pref/service

+          - XXX: Sets browser.zoom.siteSpecific to false

+          - Interesting.. They clear their titles.. I wonder if some

+            window managers log titles.. But that level of surveillance is

+            unbeatable..

+            - XXX: Unless there is some way for flash or script to read titles?

+          - They empty the clipboard..

+            - Can js access the clipboard?? ...

+            - Yes, but needs special pref+confirmation box

+              - http://www.dynamic-tools.net/toolbox/copyToClipboard/

+          - They clear cache..

+          - Cookies:

+            - Use in-memory table that is different than their default

+              - This could fuck up our cookie storage options

+              - We could maybe prevent them from getting this

+                event by wrapping nsCookieService::Observe(). Lullz..

+          - NavHistory:

+            - XXX: nsNavHistory::AutoCompleteFeedback() doesn't track

+              awesomebar choices for feedback.. Is this done on disk?

+            - Don't add history entries

+            - We should block this observe event too if we can..

+          - The session store stops storing tabs

+            - We could block this observe

+          - XXX: They expunge private temporary files on exit from PMB

+            - This is not done normally until browser exit or

+              "on-profile-change"

+            - emits browser:purge-domain-data.. Mostly just for session

+              editing it appears

+            - Direct component query for pbs.privateBrowsingEnabled

+              - This is where we have no ability to provide certain option

+                control

+              - browser.js seems to prevent user from allowing blocked

+                popups?

+              - Some items in some places context menu get blocked:

+                - Can't delete items from history? placesContext_deleteHost

+              - nsCookiePermission::InPrivateBrowsing() calls direct

+                - but is irellevant

+              - Form history cannot be saved while in PBM.. :(

+              - User won't be prompted for adding login passwords..

+              - Can't remember prefs on content types

+              - Many components read this value upon init:

+                - This fucks up our observer game if tor starts enabled

+                - NavHistory and cookie and dl manager

+                - We could just wrap the bool on startup and lie

+                  and emit later... :/

+                  - Or! emit an exit and an enter always at startup if tor is

+                    enabled.

+  - Read iSec report

+  - Compare to Chrome

+    - API use cases

+- SessionStore

+  - Has been reworked with observers and write methods. Should use those.

+- security.enable_ssl2 to clear session id

+  - Still cleared

+- browser.sessionstore.max_tabs_undo

+  - Yep.

+- SafeBrowsing Update Key removed on cookie clear still?

+  - Yep.

+- Livemark updates have kill events now

+- Test if nsICertStore is still buggy...

+

+Third Pass: Exploit Auditing

+- Remote fonts

+- SVG with HTML

+- Javascript threads+locking

+- Ogg theora and vorbis codecs

+- SQLite

+

+

+- https://developer.mozilla.org/en/Firefox_3_for_developers

@@ -0,0 +1 @@

+xsltproc  --output index.html.en  --stringparam section.autolabel.max.depth 2 --stringparam  section.autolabel 1 /usr/share/sgml/docbook/xsl-stylesheets-1.75.2/xhtml/docbook.xsl design.xml 

@@ -0,0 +1,2640 @@

+<?xml version="1.0" encoding="ISO-8859-1"?>

+<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"

+     "file:///usr/share/sgml/docbook/xml-dtd-4.4-1.0-30.1/docbookx.dtd">

+

+<article id="design">

+ <articleinfo>

+  <title>Torbutton Design Documentation</title>

+   <author>

+    <firstname>Mike</firstname><surname>Perry</surname>

+    <affiliation>

+     <address><email>mikeperry.fscked/org</email></address>

+    </affiliation>

+   </author>

+   <pubdate>Dec 15 2009</pubdate>

+ </articleinfo>

+

+<sect1>

+  <title>Introduction</title>

+  <para>

+

+This document describes the goals, operation, and testing procedures of the

+Torbutton Firefox extension. It is current as of Torbutton 1.2.4.

+

+  </para>

+  <sect2 id="adversary">

+   <title>Adversary Model</title>

+   <para>

+

+A Tor web browser adversary has a number of goals, capabilities, and attack

+types that can be used to guide us towards a set of requirements for the

+Torbutton extension. Let's start with the goals.

+

+   </para>

+   <sect3 id="adversarygoals">

+    <title>Adversary Goals</title>

+    <orderedlist>

+<!-- These aren't really commands.. But it's the closest I could find in an

+acceptable style.. Don't really want to make my own stylesheet -->

+     <listitem><command>Bypassing proxy settings</command>

+     <para>The adversary's primary goal is direct compromise and bypass of 

+Tor, causing the user to directly connect to an IP of the adversary's

+choosing.</para>

+     </listitem>

+     <listitem><command>Correlation of Tor vs Non-Tor Activity</command>

+     <para>If direct proxy bypass is not possible, the adversary will likely

+happily settle for the ability to correlate something a user did via Tor with

+their non-Tor activity. This can be done with cookies, cache identifiers,

+javascript events, and even CSS. Sometimes the fact that a user uses Tor may

+be enough for some authorities.</para>

+     </listitem>

+     <listitem><command>History disclosure</command>

+     <para>

+The adversary may also be interested in history disclosure: the ability to

+query a user's history to see if they have issued certain censored search

+queries, or visited censored sites.

+     </para>

+     </listitem>

+     <listitem><command>Location information</command>

+     <para>

+

+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.

+

+     </para>

+     </listitem>

+     <listitem><command>Miscellaneous anonymity set reduction</command>

+     <para>

+

+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 <link

+linkend="fingerprinting">tracking their activities</link>.

+

+     </para>

+     </listitem>

+     <listitem><command>History records and other on-disk

+information</command>

+     <para>

+In some cases, the adversary may opt for a heavy-handed approach, such as

+seizing the computers of all Tor users in an area (especially after narrowing

+the field by the above two pieces of information). History records and cache

+data are the primary goals here.

+     </para>

+     </listitem>

+    </orderedlist>

+   </sect3>

+

+   <sect3 id="adversarypositioning">

+    <title>Adversary Capabilities - Positioning</title>

+    <para>

+The adversary can position themselves at a number of different locations in

+order to execute their attacks.

+    </para>

+    <orderedlist>

+     <listitem><command>Exit Node or Upstream Router</command>

+     <para>

+The adversary can run exit nodes, or alternatively, they may control routers

+upstream of exit nodes. Both of these scenarios have been observed in the

+wild.

+     </para>

+     </listitem>

+     <listitem><command>Adservers and/or Malicious Websites</command>

+     <para>

+The adversary can also run websites, or more likely, they can contract out

+ad space from a number of different 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.

+     </para>

+     </listitem>

+     <listitem><command>Local Network/ISP/Upstream Router</command>

+     <para>

+The adversary can also inject malicious content at the user's upstream router

+when they have Tor disabled, in an attempt to correlate their Tor and Non-Tor

+activity.

+     </para>

+     </listitem>

+     <listitem><command>Physical Access</command>

+     <para>

+Some users face adversaries with intermittent or constant physical access.

+Users in Internet cafes, for example, face such a threat. In addition, in

+countries where simply using tools like Tor is illegal, users may face

+confiscation of their computer equipment for excessive Tor usage or just

+general suspicion.

+     </para>

+     </listitem>

+    </orderedlist>

+   </sect3>

+

+   <sect3 id="attacks">

+    <title>Adversary Capabilities - Attacks</title>

+    <para>

+

+The adversary can perform the following attacks from a number of different 

+positions to accomplish various aspects of their goals. It should be noted

+that many of these attacks (especially those involving IP address leakage) are

+often performed by accident by websites that simply have Javascript, dynamic 

+CSS elements, and plugins. Others are performed by 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.

+

+    </para>

+    <orderedlist>

+     <listitem><command>Inserting Javascript</command>

+     <para>

+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 <ulink

+url="http://whattheinternetknowsaboutyou.com/">history disclosure attacks</ulink>:

+to query the history via the different attributes of 'visited' links to search

+for particular google queries, sites, or even to <ulink

+url="http://www.mikeonads.com/2008/07/13/using-your-browser-url-history-estimate-gender/">profile

+users based on gender and other classifications</ulink>. Finally,

+Javascript can be used to query the user's timezone via the

+<function>Date()</function> object, and to reduce the anonymity set by querying

+the <function>navigator</function> object for operating system, CPU, locale, 

+and user agent information.

+     </para>

+     </listitem>

+

+     <listitem><command>Inserting Plugins</command>

+     <para>

+

+Plugins are abysmal at obeying the proxy settings of the browser. Every plugin

+capable of performing network activity that the author has

+investigated is also capable of performing network activity independent of

+browser proxy settings - and often independent of its own proxy settings.

+Sites that have plugin content don't even have to be malicious to obtain a

+user's

+Non-Tor IP (it usually leaks by itself), though <ulink

+url="http://decloak.net">plenty of active

+exploits</ulink> are possible as well. In addition, plugins can be used to store unique identifiers that are more

+difficult to clear than standard cookies. 

+<ulink url="http://epic.org/privacy/cookies/flash.html">Flash-based

+cookies</ulink> fall into this category, but there are likely numerous other

+examples.

+

+     </para>

+     </listitem>

+     <listitem><command>Inserting CSS</command>

+     <para>

+

+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

+<ulink url="http://www.tjkdesign.com/articles/css%20pop%20ups/">CSS

+popups</ulink> - 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 <ulink

+url="http://ha.ckers.org/weird/CSS-history.cgi">CSS-only history disclosure

+attacks</ulink>.

+     </para>

+     </listitem>

+     <listitem><command>Read and insert cookies</command>

+     <para>

+

+An adversary in a position to perform MITM content alteration can inject

+document content elements to both read and inject cookies for

+arbitrary domains. In fact, many "SSL secured" websites are vulnerable to this

+sort of <ulink url="http://seclists.org/bugtraq/2007/Aug/0070.html">active

+sidejacking</ulink>.

+

+     </para>

+     </listitem>

+     <listitem><command>Create arbitrary cached content</command>

+     <para>

+

+Likewise, the browser cache can also be used to <ulink

+url="http://crypto.stanford.edu/sameorigin/safecachetest.html">store unique

+identifiers</ulink>. 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.

+

+     </para>

+     </listitem>

+     <listitem id="fingerprinting"><command>Fingerprint users based on browser

+attributes</command>

+<para>

+

+There is an absurd amount of information available to websites via attributes

+of the browser. This information can be used to reduce anonymity set, or even

+<ulink url="http://mandark.fr/0x000000/articles/Total_Recall_On_Firefox..html">uniquely

+fingerprint individual users</ulink>. </para>

+<para>

+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 <ulink

+url="http://developer.mozilla.org/en/docs/DOM:window">window</ulink> and

+<ulink

+url="http://developer.mozilla.org/en/docs/DOM:window.screen">window.screen</ulink>

+objects. 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<superscript>3</superscript>=8). Interface effects such as titlebar fontsize

+and window manager settings gives a factor of about 9 (say 3 common font sizes

+for the titlebar 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<superscript>29</superscript>, or a 29 bit identifier based on resolution

+information alone. </para>

+

+<para>

+

+Of course, this space is non-uniform and prone to incremental changes.

+However, if a bit vector space consisting of the above extracted attributes

+were used instead of the hash approach from <ulink

+url="http://mandark.fr/0x000000/articles/Total_Recall_On_Firefox..html">The Hacker

+Webzine article above</ulink>, minor changes in browser window resolution will

+no longer generate totally new identifiers. 

+

+</para>

+<para>

+

+To add insult to injury, <ulink

+url="http://pseudo-flaw.net/content/tor/torbutton/">chrome URL disclosure

+attacks</ulink> mean that each and every extension on <ulink

+url="https://addons.mozilla.org">addons.mozilla.org</ulink> adds another bit

+to that 2<superscript>29</superscript>. With hundreds of popular extensions

+and thousands of extensions total, it is easy to see that this sort of

+information is an impressively powerful identifier if used properly by a

+competent and determined adversary such as an ad network.  Again, a

+nearest-neighbor bit vector space approach here would also gracefully handle

+incremental changes to installed extensions.

+

+</para>

+

+     </listitem>

+     <listitem><command>Remotely or locally exploit browser and/or

+OS</command>

+     <para>

+Last, but definitely not least, the adversary can exploit either general 

+browser vulnerabilities, plugin vulnerabilities, or OS vulnerabilities to

+install malware and surveillance software. An adversary with physical access

+can perform similar actions. Regrettably, this last attack capability is

+outside of Torbutton's ability to defend against, but it is worth mentioning

+for completeness.

+     </para>

+     </listitem>

+    </orderedlist>

+   </sect3>

+

+  </sect2>

+

+  <sect2 id="requirements">

+   <title>Torbutton Requirements</title>

+<note>

+

+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.

+

+</note>

+   <para>

+

+From the above Adversary Model, a number of requirements become clear. 

+

+   </para>

+

+<orderedlist> 

+<!-- These aren't really commands.. But it's the closest I could find in an

+acceptable style.. Don't really want to make my own stylesheet -->

+ <listitem id="proxy"><command>Proxy Obedience</command> 

+ <para>The browser

+MUST NOT bypass Tor proxy settings for any content.</para></listitem>

+ <listitem id="isolation"><command>Network Isolation</command>

+ <para>Pages MUST NOT perform any network activity in a Tor state different

+ from the state they were originally loaded in.</para></listitem>

+ <listitem id="state"><command>State Separation</command>

+ <para>Browser state (cookies, cache, history, 'DOM storage'), accumulated in

+ one Tor state MUST NOT be accessible via the network in

+ another Tor state.</para></listitem>

+ <listitem id="undiscoverability"><command>Tor Undiscoverability</command><para>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.</para></listitem>

+ <listitem id="disk"><command>Disk Avoidance</command><para>The browser SHOULD NOT write any Tor-related state to disk, or store it

+ in memory beyond the duration of one Tor toggle.</para></listitem>

+ <listitem id="location"><command>Location Neutrality</command><para>The browser SHOULD NOT leak location-specific information, such as

+ timezone or locale via Tor.</para></listitem>

+ <listitem id="setpreservation"><command>Anonymity Set

+Preservation</command><para>The browser SHOULD NOT leak any other anonymity set reducing 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.

+</para></listitem>

+ <listitem id="updates"><command>Update Safety</command><para>The browser

+SHOULD NOT perform unauthenticated updates or upgrades via Tor.</para></listitem>

+ <listitem id="interoperate"><command>Interoperability</command><para>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.</para></listitem>

+</orderedlist>

+  </sect2>

+  <sect2 id="layout">

+   <title>Extension Layout</title>

+

+<para>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 <ulink

+url="https://developer.mozilla.org/en/XPCOM">can be

+written</ulink> in C++,

+Javascript, or a mixture of both. Components have two identifiers: their

+'<ulink

+url="http://www.mozilla.org/projects/xpcom/book/cxc/html/quicktour2.html#1005005">Contract

+ID</ulink>' (a human readable path-like string), and their '<ulink

+url="http://www.mozilla.org/projects/xpcom/book/cxc/html/quicktour2.html#1005329">Class

+ID</ulink>' (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.</para>

+

+<para>'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 <ulink

+url="http://developer.mozilla.org/en/docs/XUL_Reference">XUL</ulink>.</para>

+  </sect2>

+</sect1>

+<sect1>

+  <title>Components</title>

+  <para>

+

+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.

+

+  </para>

+

+  <sect2>

+   <title>Hooked Components</title>

+

+<para>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.</para>

+

+<sect3 id="sessionstore">

+ <title><ulink

+url="http://developer.mozilla.org/en/docs/nsISessionStore">@mozilla.org/browser/sessionstore;1</ulink> -

+<ulink

+url="https://git.torproject.org/checkout/torbutton/master/src/components/nsSessionStore36.js">components/nsSessionStore36.js</ulink></title>

+

+<para>These components address the <link linkend="disk">Disk Avoidance</link>

+requirements of Torbutton. As stated in the requirements, Torbutton needs to

+prevent Tor tabs from being written to disk by the Firefox session store for a

+number of reasons, primary among them is the fact that Firefox can crash at

+any time, and a restart can cause you to fetch tabs in the incorrect Tor

+state.</para>

+

+<para>These components illustrate a complication with Firefox hooking: you can

+only hook member functions of a class if they are published in an

+interface that the class implements. Unfortunately, the sessionstore has no

+published interface that is amenable to disabling the writing out of Tor tabs

+in specific. As such, Torbutton had to include the <emphasis>entire</emphasis>

+nsSessionStore from both Firefox 2.0, 3.0, 3.5 and 3.6

+with a couple of modifications to prevent tabs that were loaded with Tor

+enabled from being written to disk, and some version detection code to

+determine which component to load. The <ulink

+url="https://git.torproject.org/checkout/torbutton/master/src/components/nsSessionStore36.diff">diff against the original session

+store</ulink> is included in the git repository.</para>

+</sect3>

+<sect3 id="appblocker">

+ <title><ulink

+url="http://www.oxymoronical.com/experiments/xpcomref/applications/Firefox/3.5/components/%40mozilla.org/uriloader/external-protocol-service%3B1">@mozilla.org/uriloader/external-protocol-service;1

+</ulink>, <ulink

+url="http://www.oxymoronical.com/experiments/xpcomref/applications/Firefox/3.5/components/%40mozilla.org/uriloader/external-helper-app-service%3B1">@mozilla.org/uriloader/external-helper-app-service;1</ulink>,

+and <ulink url="http://www.oxymoronical.com/experiments/xpcomref/applications/Firefox/3.5/components/%40mozilla.org/mime%3B1">@mozilla.org/mime;1</ulink>

+- <ulink

+  url="https://git.torproject.org/checkout/torbutton/master/src/components/external-app-blocker.js">components/external-app-blocker.js</ulink></title>

+ <para>

+Due to <link linkend="FirefoxBugs">Firefox Bug</link> <ulink

+url="https://bugzilla.mozilla.org/show_bug.cgi?id=440892">440892</ulink> 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 <link linkend="proxy">Proxy

+Obedience</link> Requirement.

+ </para>

+</sect3>

+<sect3>

+<title><ulink

+url="http://lxr.mozilla.org/seamonkey/source/browser/components/sessionstore/src/nsSessionStartup.js">@mozilla.org/browser/sessionstartup;1</ulink> -

+    <ulink

+url="https://git.torproject.org/checkout/torbutton/master/src/components/crash-observer.js">components/crash-observer.js</ulink></title>

+

+<para>This component wraps the Firefox Session Startup component that is in

+charge of <ulink

+url="http://developer.mozilla.org/en/docs/Session_store_API">restoring saved

+sessions</ulink>. The wrapper's only job is to intercept the

+<function>doRestore()</function> function, which is called by Firefox if it is determined that the

+browser crashed and the session needs to be restored. The wrapper notifies the

+Torbutton chrome that the browser crashed by setting the pref

+<command>extensions.torbutton.crashed</command>, or that it is a normal

+startup via the pref <command>extensions.torbutton.noncrashed</command>. The Torbutton Chrome <ulink

+url="https://developer.mozilla.org/en/NsIPrefBranch2#addObserver.28.29">listens for a

+preference change</ulink> for this value and then does the appropriate cleanup. This

+includes setting the Tor state to the one the user selected for crash recovery

+in the preferences window (<command>extensions.torbutton.restore_tor</command>), and

+restoring cookies for the corresponding cookie jar, if it exists.</para>

+

+<para>By performing this notification, this component assists in the 

+<link linkend="proxy">Proxy Obedience</link>, and <link

+linkend="isolation">Network Isolation</link> requirements.

+</para>

+

+

+</sect3>

+<sect3>

+<title><ulink url="http://www.oxymoronical.com/experiments/xpcomref/applications/Firefox/3.5/components/%40mozilla.org/browser/global-history;2">@mozilla.org/browser/global-history;2</ulink>

+- <ulink

+  url="https://git.torproject.org/checkout/torbutton/master/src/components/ignore-history.js">components/ignore-history.js</ulink></title>

+

+<para>This component was contributed by <ulink

+url="http://www.collinjackson.com/">Collin Jackson</ulink> 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 <ulink

+url="https://developer.mozilla.org/en/nsIGlobalHistory2#isVisited.28.29">isVisited</ulink>

+and <ulink 

+url="https://developer.mozilla.org/en/nsIGlobalHistory2#addURI.28.29">addURI</ulink>

+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

+preferences.

+</para>

+<para>

+This component helps satisfy the <link linkend="state">State Separation</link>

+and <link linkend="disk">Disk Avoidance</link> requirements of Torbutton.

+</para>

+</sect3>

+<sect3 id="livemarks">

+<title><ulink

+url="http://www.oxymoronical.com/experiments/xpcomref/applications/Firefox/3.5/components/%40mozilla.org/browser/livemark-service;2">@mozilla.org/browser/livemark-service;2</ulink>

+- <ulink

+  url="https://git.torproject.org/checkout/torbutton/master/src/components/block-livemarks.js">components/block-livemarks.js</ulink></title>

+<para>

+

+The <ulink

+url="http://www.mozilla.com/en-US/firefox/livebookmarks.html">livemark</ulink> 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.

+

+</para>

+<para>

+This component helps satisfy the <link linkend="isolation">Network

+Isolation</link> and <link linkend="setpreservation">Anonymity Set

+Preservation</link> requirements.

+</para>

+</sect3>

+</sect2>

+<sect2>

+<title>New Components</title>

+

+<para>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.</para>

+

+<sect3>

+<title><ulink

+url="https://git.torproject.org/checkout/torbutton/master/src/components/cookie-jar-selector.js">@torproject.org/cookie-jar-selector;2

+- components/cookie-jar-selector.js</ulink></title>

+

+<para>The cookie jar selector (also based on code from <ulink

+url="http://www.collinjackson.com/">Collin

+Jackson</ulink>) is used by the Torbutton chrome to switch between

+Tor and Non-Tor cookies. Its operations are simple: sync cookies to disk, then

+move the current cookies.txt file to the appropriate backup location

+(cookies-tor.txt or cookies-nontor.txt), and then moving the other cookie jar

+into place.</para>

+

+<para>

+This component helps to address the <link linkend="state">State

+Isolation</link> requirement of Torbutton.

+</para>

+

+</sect3>

+<sect3>

+<title><ulink

+url="https://git.torproject.org/checkout/torbutton/master/src/components/torbutton-logger.js">@torproject.org/torbutton-logger;1

+- components/torbutton-logger.js</ulink></title>

+

+<para>The torbutton logger component allows on-the-fly redirection of torbutton

+logging messages to either Firefox stderr

+(<command>extensions.torbutton.logmethod=0</command>), the Javascript error console

+(<command>extensions.torbutton.logmethod=1</command>), or the DebugLogger extension (if

+available - <command>extensions.torbutton.logmethod=2</command>). It also allows you to

+change the loglevel on the fly by changing

+<command>extensions.torbutton.loglevel</command> (1-5, 1 is most verbose).

+</para>

+</sect3>

+<sect3 id="windowmapper">

+

+<title><ulink

+url="https://git.torproject.org/checkout/torbutton/master/src/components/window-mapper.js">@torproject.org/content-window-mapper;1

+- components/window-mapper.js</ulink></title>

+

+<para>Torbutton tags Firefox <ulink

+url="https://developer.mozilla.org/en/XUL_Tutorial/Tabboxes">tabs</ulink> 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 <ulink

+url="https://developer.mozilla.org/en/XUL/tabbrowser">browser

+tab</ulink> for a given <ulink

+url="https://developer.mozilla.org/en/nsIDOMWindow">HTML content

+window</ulink>. It does this by traversing all windows and all browsers, until it

+finds the browser with the requested <ulink

+url="https://developer.mozilla.org/en/XUL/tabbrowser#p-contentWindow">contentWindow</ulink> element. Since the content policy

+and page loading in general can generate hundreds of these lookups, this

+result is cached inside the component.

+</para>

+</sect3>

+<sect3 id="contentpolicy">

+<title><ulink

+url="https://git.torproject.org/checkout/torbutton/master/src/components/cssblocker.js">@torproject.org/cssblocker;1

+- components/cssblocker.js</ulink></title>

+

+<para>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 <ulink

+url="https://developer.mozilla.org/en/nsIContentPolicy">nsIContentPolicy</ulink>.

+When an nsIContentPolicy is registered, Firefox checks every attempted network

+request against its <ulink

+url="https://developer.mozilla.org/en/nsIContentPolicy#shouldLoad()">shouldLoad</ulink>

+member function to determine if the load should proceed. In Torbutton's case,

+the content policy looks up the appropriate browser tab using the <link

+linkend="windowmapper">window mapper</link>,

+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.</para> This helps to achieve the <link

+linkend="isolation">Network

+Isolation</link> requirements of Torbutton.

+

+<para>In addition, the content policy also blocks website javascript from

+<ulink url="http://pseudo-flaw.net/content/tor/torbutton/">querying for

+versions and existence of extension chrome</ulink> while Tor is enabled, and

+also masks the presence of Torbutton to website javascript while Tor is

+disabled. </para>

+

+<para>

+

+Finally, some of the work that logically belongs to the content policy is

+instead handled by the <command>torbutton_http_observer</command> and

+<command>torbutton_weblistener</command> in <ulink

+url="https://git.torproject.org/checkout/torbutton/master/src/chrome/content/torbutton.js">torbutton.js</ulink>. 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 

+<ulink

+url="https://bugzilla.mozilla.org/show_bug.cgi?id=437014">437014</ulink> and 

+<ulink

+url="https://bugzilla.mozilla.org/show_bug.cgi?id=401296">401296</ulink>).

+

+</para>

+

+<!-- 

+FIXME: Hrmm, the content policy doesn't really lend itself well to display 

+this way.. People looking for this much detail should consult the source.

+

+<para>

+    <table rowheader="firstcol" frame='all'><title>Access Permissions Table</title>

+    <tgroup cols='5' align='left' colsep='1' rowsep='1'>

+       <tbody>

+       <row>

+         <entry></entry>

+         <entry>chrome/resource</entry>

+         <entry>a3</entry>

+         <entry>a4</entry>

+         <entry>a5</entry>

+       </row>

+       <row>

+         <entry>file</entry>

+         <entry>b2</entry>

+         <entry>b3</entry>

+         <entry>b4</entry>

+         <entry>b5</entry>

+       </row>

+       <row>

+         <entry>c1</entry>

+         <entry>c2</entry>

+         <entry>c3</entry>

+         <entry>c4</entry>

+         <entry>c5</entry>

+       </row>

+       <row>

+         <entry>d1</entry>

+         <entry>d2</entry>

+         <entry>d3</entry>

+         <entry>d4</entry>

+         <entry>d5</entry>

+       </row>

+       </tbody>

+       </tgroup>

+       </table>

+</para>

+-->

+

+<para>

+

+This helps to fulfill both the <link

+linkend="setpreservation">Anonymity Set Preservation</link> and the <link

+linkend="undiscoverability">Tor Undiscoverability</link> requirements of

+Torbutton.</para>

+

+</sect3>

+</sect2>

+</sect1>

+<sect1>

+ <title>Chrome</title>

+

+<para>The chrome is where all the torbutton graphical elements and windows are

+located. Each window is described as an <ulink

+url="http://developer.mozilla.org/en/docs/XUL_Reference">XML file</ulink>, with zero or more Javascript

+files attached. The scope of these Javascript files is their containing

+window.</para>

+

+<sect2 id="browseroverlay">

+<title>Browser Overlay - <ulink

+url="https://git.torproject.org/checkout/torbutton/master/src/chrome/content/torbutton.xul">torbutton.xul</ulink></title>

+

+<para>The browser overlay, torbutton.xul, defines the toolbar button, the status

+bar, and events for toggling the button. The overlay code is in <ulink

+url="https://git.torproject.org/checkout/torbutton/master/src/chrome/content/torbutton.js">chrome/content/torbutton.js</ulink>.

+It contains event handlers for preference update, shutdown, upgrade, and

+location change events.</para>

+

+<para>The <ulink

+url="https://developer.mozilla.org/en/nsIWebProgressListener#onLocationChange">location

+change</ulink> <ulink

+url="https://developer.mozilla.org/en/nsIWebProgress">webprogress

+listener</ulink>, <command>torbutton_weblistener</command> is one of the most

+important parts of the chrome from a security standpoint. It is a <ulink

+url="https://developer.mozilla.org/en/nsIWebProgressListener">webprogress

+listener</ulink> that handles receiving an event every time a page load or

+iframe load occurs. This class eventually calls down to

+<function>torbutton_update_tags()</function> and

+<function>torbutton_hookdoc()</function>, which apply the browser Tor load

+state tags, plugin permissions, and install the Javascript hooks to hook the

+<ulink

+url="https://developer.mozilla.org/en/DOM/window.screen">window.screen</ulink>

+object to obfuscate browser and desktop resolution information.

+

+</para>

+

+<para>

+The browser overlay helps to satisfy a number of Torbutton requirements. These

+are better enumerated in each of the Torbutton preferences below. However,

+there are also a number of Firefox preferences set in

+<function>torbutton_update_status()</function> that aren't governed by any

+Torbutton setting. These are:

+</para>

+<orderedlist>

+

+<!--

+Not set any more.

+ <listitem><ulink

+url="http://kb.mozillazine.org/Browser.bookmarks.livemark_refresh_seconds">browser.bookmarks.livemark_refresh_seconds</ulink>

+<para>

+This pref is set in an attempt to disable the fetching of LiveBookmarks via

+Tor. Since users can potentially collect a large amount of live bookmarks to

+very personal sites (blogs of friends, wikipedia articles they maintain,

+comment feeds of their own blog), it is not possible to cleanly isolate these

+fetches and they are simply disabled during Tor usage.

+This helps to address the <link

+linkend="state">State Separation</link> requirement.

+Unfortunately <ulink

+url="https://bugzilla.mozilla.org/show_bug.cgi?id=436250">Firefox Bug

+436250</ulink> prevents this from

+functioning completely correctly.

+</para>

+  </listitem>

+-->

+

+ <listitem><ulink

+url="http://kb.mozillazine.org/Network.security.ports.banned">network.security.ports.banned</ulink>

+ <para>

+Torbutton sets this setting to add ports 8123, 8118, 9050 and 9051 (which it

+reads from <command>extensions.torbutton.banned_ports</command>) 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 <link

+linkend="undiscoverability">Tor Undiscoverability</link> requirement.

+ </para>

+ </listitem>

+ <listitem><ulink url="http://kb.mozillazine.org/Browser.send_pings">browser.send_pings</ulink>

+ <para>

+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 <link linkend="isolation">Network

+Isolation</link> requirement.

+ </para>

+ </listitem>

+ <listitem><ulink

+url="http://kb.mozillazine.org/Browser.safebrowsing.remoteLookups">browser.safebrowsing.remoteLookups</ulink>

+ <para>

+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 <link

+linkend="disk">Disk Avoidance</link> requirement, by preventing your entire

+browsing history from ending up on Google's disks.

+ </para>

+ </listitem>

+ <listitem><ulink

+url="http://kb.mozillazine.org/Browser.safebrowsing.enabled">browser.safebrowsing.enabled</ulink>

+ <para>

+Safebrowsing does <ulink

+url="https://bugzilla.mozilla.org/show_bug.cgi?id=360387">unauthenticated

+updates under Firefox 2</ulink>, so it is disabled during Tor usage. 

+This helps fulfill the <link linkend="updates">Update

+Safety</link> requirement. Firefox 3 has the fix for that bug, and so

+safebrowsing updates are enabled during Tor usage.

+ </para>

+ </listitem>

+ <listitem><ulink

+url="http://kb.mozillazine.org/Network.protocol-handler.warn-external.%28protocol%29">network.protocol-handler.warn-external.(protocol)</ulink>

+ <para>

+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 <link

+linkend="proxy">Proxy Obedience</link> requirement, by preventing external

+applications from accessing network resources at the command of Tor-fetched

+pages. Unfortunately, due to <link linkend="FirefoxBugs">Firefox Bug</link>

+<ulink

+url="https://bugzilla.mozilla.org/show_bug.cgi?id=440892">440892</ulink>,

+these prefs are no longer obeyed. They are set still anyway out of respect for

+the dead.

+ </para>

+</listitem>

+  <listitem><ulink

+url="http://kb.mozillazine.org/Browser.sessionstore.max_tabs_undo">browser.sessionstore.max_tabs_undo</ulink>

+   <para>

+

+To help satisfy the Torbutton <link linkend="state">State Separation</link>

+and <link linkend="isolation">Network Isolation</link> requirements,