tor-webwml.git

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

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

-

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

-First pass: Quick Review of Firefox Features

-- Video Tag

-  - Docs:

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

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

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

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

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

-    - https://developer.mozilla.org/En/Media_formats_supported_by_the_audio_and_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

@@ -1 +0,0 @@

-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 

@@ -1,2760 +0,0 @@

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

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

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

-

-<article id="design">

- <articleinfo>

-  <title>Torbutton Design Documentation</title>

-   <author>

-    <firstname>Mike</firstname><surname>Perry</surname>

-    <affiliation>

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

-    </affiliation>

-   </author>

-   <pubdate>Jun 28 2010</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.5.

-

-  </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,