[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

[tor-commits] [tor-browser-spec/master] Begin work on design doc updates for Firefox 17.



commit c9da119126462ad40d075712f47cdd60813c8568
Author: Mike Perry <mikeperry-git@xxxxxxxxxx>
Date:   Tue Jan 15 23:42:17 2013 -0800

    Begin work on design doc updates for Firefox 17.
---
 docs/design/Firefox17-TODO |   54 +++++
 docs/design/build.sh       |    2 +-
 docs/design/design.xml     |  569 ++++++++++++++++++++++++--------------------
 3 files changed, 362 insertions(+), 263 deletions(-)

diff --git a/docs/design/Firefox17-TODO b/docs/design/Firefox17-TODO
new file mode 100644
index 0000000..5d016e5
--- /dev/null
+++ b/docs/design/Firefox17-TODO
@@ -0,0 +1,54 @@
+- Cleanups
+  + We specify browser.cache.memory.enable under disk avoidance. That's
+    wrong. We don't even set it at all. Torbutton relic?
+  + Disk leak documentation
+  - Firefox 17 will mess up all patch links
+ 
+- Heavy Writing by section
+  + Intro:
+    + We target Firefox ESR
+  - Adversary Goals
+    - Describe how each adversary attack violates design goals
+    - "Correlate activity across multiple site visits" as one of the adversary
+      goals. This is the primary goal of the ad networks, though. We need to
+      explicitly mention it in the Adversary Goals section for completeness.
+  - Misc implementation
+    - document the environment variables and settings used to provide a non-grey "New Identity" button.
+    - Link to prefs.js
+    - Mockup privacy UI
+  - Identifier Linkability 
+    - 3.5.8 is not clear that what we're trying to limit is non-click
+      driven/non-interactive linkability rather than linkability in all cases.
+      Other sections may have this problem, too.
+      - This is a subtlety that arises from both the impossibility of satisfying
+        unlinkability due to covert channels in GET/POST, as well as the desire
+        to avoid breaking thinks like consensual federated login.
+    - He reminded me about documenting disabling IndexedDB, but that is just one
+      of the many prefs.js changes we need to document.
+    - We should only preserve window.name if the url bar domain remains the
+      same. I could be convinced of this, but it's going to be trickier to
+      implement and I think it's not really possible to remove linkability for user
+      clicks in general.
+  - Fingerprinting
+    - describe our resolution defenses
+    - Explain why panopticlick is weirdsauce
+    - provide an entropy count estimate for fingerprinting defenses
+    - We should perhaps be more vocal about the fingerprinting issues with
+      some or all of  http://www.w3.org/TR/navigation-timing/. I think I agree.
+  - Deprecation List/Future Philosophy:
+    - Linkability Transparency from
+      https://trac.torproject.org/projects/tor/ticket/5273#comment:12
+    - Referer Header
+    - Window.name
+
+- List links to design violations/enhancements:
+  - https://trac.torproject.org/projects/tor/query?keywords=~tbb-linkability
+  - https://trac.torproject.org/projects/tor/query?keywords=~tbb-fingerprinting
+
+- Tests
+  - Sync with QA pages
+  - Many are out of date
+  - http://www.stayinvisible.com/
+  - Evercookie test page, and perhaps also
+    http://jeremiahgrossman.blogspot.de/2007/04/tracking-users-without-cookies.html
+
diff --git a/docs/design/build.sh b/docs/design/build.sh
index 6531077..68809d5 100755
--- a/docs/design/build.sh
+++ b/docs/design/build.sh
@@ -1 +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 
+xsltproc  --output index.html.en  --stringparam section.autolabel.max.depth 2 --stringparam  section.autolabel 1 /usr/share/xml/docbook/stylesheet/docbook-xsl/xhtml-1_1/docbook.xsl design.xml 
diff --git a/docs/design/design.xml b/docs/design/design.xml
index 3677816..d723542 100644
--- a/docs/design/design.xml
+++ b/docs/design/design.xml
@@ -23,7 +23,7 @@
      <address><email>sjmurdoch#torproject org</email></address>
     </affiliation>
    </author>
-   <pubdate>Dec 28 2011</pubdate>
+   <pubdate>Dec 30 2012</pubdate>
  </articleinfo>
 
 <!--
@@ -39,8 +39,8 @@ This document describes the <link linkend="adversary">adversary model</link>,
 <link linkend="DesignRequirements">design requirements</link>,
 <link linkend="Implementation">implementation</link>, <link
 linkend="Packaging">packaging</link> and <link linkend="Testing">testing
-procedures</link> of the Tor Browser. It is
-current as of Tor Browser 2.2.35-1 and Torbutton 1.4.5.
+procedures</link> of the Tor Browser. <!-- XXX: It is
+current as of Tor Browser 2.2.35-1 and Torbutton 1.4.5. -->
 
   </para>
   <para>
@@ -51,268 +51,32 @@ against active network adversaries, in addition to the passive forensic local
 adversary currently addressed by the major browsers.
 
   </para>
-  <sect2 id="adversary">
-   <title>Adversary Model</title>
+  <sect2 id="components">
+   <title>Browser Component Overview</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
-Tor Browser. Let's start with the goals.
+The Tor Browser is based on <ulink
+url="https://www.mozilla.org/en-US/firefox/organizations/";>Mozilla's Extended
+Support Release (ESR) Firefox branch</ulink>. We have a <link
+linkend="firefox-patches">series of patches</link> against this browser to
+enhance privacy and security. Browser behavior is additionally augmented
+through the <ulink
+url="https://gitweb.torproject.org/torbutton.git/tree/master";>Torbutton
+extension</ulink>, though we are in the process of moving this
+functionality into direct Firefox patches. We also <ulink
+url="https://gitweb.torproject.org/torbrowser.git/blob/HEAD:/build-scripts/config/prefs.js";>change
+a number of Firefox preferences</ulink> from their defaults.
 
    </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>Ad servers 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 ad servers and inject content that way. For
-some users, the adversary may be the ad servers themselves. It is not
-inconceivable that ad servers 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 ad servers 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>Read and insert identifiers</command>
-     <para>
-
-The browser contains multiple facilities for storing identifiers that the
-adversary creates for the purposes of tracking users. These identifiers are
-most obviously cookies, but also include HTTP auth, DOM storage, cached
-scripts and other elements with embedded identifiers, client certificates, and
-even TLS Session IDs.
-
-     </para>
-     <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, even many "SSL secured" websites are vulnerable to this sort of
-<ulink url="http://seclists.org/bugtraq/2007/Aug/0070.html";>active
-sidejacking</ulink>. In addition, the ad networks of course perform tracking
-with cookies as well.
-
-     </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
-uniquely fingerprint individual users. Fingerprinting is an intimidating
-problem to attempt to tackle, especially without a metric to determine or at
-least intuitively understand and estimate which features will most contribute
-to linkability between visits.
-
-</para>
-
-<para>
-
-The <ulink url="https://panopticlick.eff.org/about.php";>Panopticlick study
-done</ulink> by the EFF uses the actual entropy - the number of identifying
-bits of information encoded in browser properties - as this metric. Their
-<ulink url="https://wiki.mozilla.org/Fingerprinting#Data";>result data</ulink>
-is definitely useful, and the metric is probably the appropriate one for
-determining how identifying a particular browser property is. However, some
-quirks of their study means that they do not extract as much information as
-they could from display information: they only use desktop resolution and do
-not attempt to infer the size of toolbars. In the other direction, they may be
-over-counting in some areas, as they did not compute joint entropy over
-multiple attributes that may exhibit a high degree of correlation. Also, new
-browser features are added regularly, so the data should not be taken as
-final.
-
-      </para>
-     <para>
-
-Despite the uncertainty, all fingerprinting attacks leverage the following
-attack vectors:
-
-     </para>
-     <orderedlist>
-     <listitem><command>Observing Request Behavior</command>
-     <para>
-
-Properties of the user's request behavior comprise the bulk of low-hanging
-fingerprinting targets. These include: User agent, Accept-* headers, pipeline
-usage, and request ordering. Additionally, the use of custom filters such as
-AdBlock and other privacy filters can be used to fingerprint request patterns
-(as an extreme example).
-
-     </para>
-     </listitem>
-
-     <listitem><command>Inserting Javascript</command>
-     <para>
-
-Javascript can reveal a lot of fingerprinting information. It provides DOM
-objects such as window.screen and window.navigator to extract information
-about the useragent. 
-
-Also, Javascript can be used to query the user's timezone via the
-<function>Date()</function> object, <ulink
-url="https://www.khronos.org/registry/webgl/specs/1.0/#5.13";>WebGL</ulink> can
-reveal information about the video card in use, and high precision timing
-information can be used to <ulink
-url="http://w2spconf.com/2011/papers/jspriv.pdf";>fingerprint the CPU and
-interpreter speed</ulink>. In the future, new JavaScript features such as
-<ulink url="http://w3c-test.org/webperf/specs/ResourceTiming/";>Resource
-Timing</ulink> may leak an unknown amount of network timing related
-information.
-
-<!-- FIXME: resource-timing stuff?  -->
-
-     </para>
-     </listitem>
-
-     <listitem><command>Inserting Plugins</command>
-     <para>
-
-The Panopticlick project found that the mere list of installed plugins (in
-navigator.plugins) was sufficient to provide a large degree of
-fingerprintability. Additionally, plugins are capable of extracting font lists,
-interface addresses, and other machine information that is beyond what the
-browser would normally provide to content. In addition, plugins can be used to
-store unique identifiers that are more difficult to clear than standard
-cookies.  <ulink url="http://epic.org/privacy/cookies/flash.html";>Flash-based
-cookies</ulink> fall into this category, but there are likely numerous other
-examples. Beyond fingerprinting, plugins are also abysmal at obeying the proxy
-settings of the browser. 
-
-
-     </para>
-     </listitem>
-     <listitem><command>Inserting CSS</command>
-     <para>
-
-<ulink url="https://developer.mozilla.org/En/CSS/Media_queries";>CSS media
-queries</ulink> can be inserted to gather information about the desktop size,
-widget size, display type, DPI, user agent type, and other information that
-was formerly available only to Javascript.
-
-     </para>
-     </listitem>
-     </orderedlist>
-     </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 our ability to defend against, but it is worth mentioning for
-completeness. <ulink url="http://tails.boum.org/contribute/design/";>The Tails
-system</ulink> however can provide some limited defenses against this
-adversary.
+   <para>
 
-     </para>
-     </listitem>
-    </orderedlist>
-   </sect3>
+To help protect against potential Tor Exit Node eavesdroppers, we include
+<ulink url="https://www.eff.org/https-everywhere";>HTTPS-Everywhere</ulink>. To
+provide users with optional defense-in-depth against Javascript and other
+potential exploit vectors, we also include <ulink
+url="http://noscript.net/";>NoScript</ulink>
 
+   </para>
   </sect2>
 </sect1>
 
@@ -652,6 +416,269 @@ high-risk features pending analysis, audit, and mitigation.
       - Location + timezone is part of this
   - Patches?
 -->
+  <sect1 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
+Tor Browser. Let's start with the goals.
+
+   </para>
+   <sect2 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>
+   </sect2>
+
+   <sect2 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>Ad servers 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 ad servers and inject content that way. For
+some users, the adversary may be the ad servers themselves. It is not
+inconceivable that ad servers 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>
+   </sect2>
+
+   <sect2 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 ad servers 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>Read and insert identifiers</command>
+     <para>
+
+The browser contains multiple facilities for storing identifiers that the
+adversary creates for the purposes of tracking users. These identifiers are
+most obviously cookies, but also include HTTP auth, DOM storage, cached
+scripts and other elements with embedded identifiers, client certificates, and
+even TLS Session IDs.
+
+     </para>
+     <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, even many "SSL secured" websites are vulnerable to this sort of
+<ulink url="http://seclists.org/bugtraq/2007/Aug/0070.html";>active
+sidejacking</ulink>. In addition, the ad networks of course perform tracking
+with cookies as well.
+
+     </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
+uniquely fingerprint individual users. Fingerprinting is an intimidating
+problem to attempt to tackle, especially without a metric to determine or at
+least intuitively understand and estimate which features will most contribute
+to linkability between visits.
+
+</para>
+
+<para>
+
+The <ulink url="https://panopticlick.eff.org/about.php";>Panopticlick study
+done</ulink> by the EFF uses the actual entropy - the number of identifying
+bits of information encoded in browser properties - as this metric. Their
+<ulink url="https://wiki.mozilla.org/Fingerprinting#Data";>result data</ulink>
+is definitely useful, and the metric is probably the appropriate one for
+determining how identifying a particular browser property is. However, some
+quirks of their study means that they do not extract as much information as
+they could from display information: they only use desktop resolution and do
+not attempt to infer the size of toolbars. In the other direction, they may be
+over-counting in some areas, as they did not compute joint entropy over
+multiple attributes that may exhibit a high degree of correlation. Also, new
+browser features are added regularly, so the data should not be taken as
+final.
+
+      </para>
+     <para>
+
+Despite the uncertainty, all fingerprinting attacks leverage the following
+attack vectors:
+
+     </para>
+     <orderedlist>
+     <listitem><command>Observing Request Behavior</command>
+     <para>
+
+Properties of the user's request behavior comprise the bulk of low-hanging
+fingerprinting targets. These include: User agent, Accept-* headers, pipeline
+usage, and request ordering. Additionally, the use of custom filters such as
+AdBlock and other privacy filters can be used to fingerprint request patterns
+(as an extreme example).
+
+     </para>
+     </listitem>
+
+     <listitem><command>Inserting Javascript</command>
+     <para>
+
+Javascript can reveal a lot of fingerprinting information. It provides DOM
+objects such as window.screen and window.navigator to extract information
+about the useragent. 
+
+Also, Javascript can be used to query the user's timezone via the
+<function>Date()</function> object, <ulink
+url="https://www.khronos.org/registry/webgl/specs/1.0/#5.13";>WebGL</ulink> can
+reveal information about the video card in use, and high precision timing
+information can be used to <ulink
+url="http://w2spconf.com/2011/papers/jspriv.pdf";>fingerprint the CPU and
+interpreter speed</ulink>. In the future, new JavaScript features such as
+<ulink url="http://w3c-test.org/webperf/specs/ResourceTiming/";>Resource
+Timing</ulink> may leak an unknown amount of network timing related
+information.
+
+<!-- FIXME: resource-timing stuff?  -->
+
+     </para>
+     </listitem>
+
+     <listitem><command>Inserting Plugins</command>
+     <para>
+
+The Panopticlick project found that the mere list of installed plugins (in
+navigator.plugins) was sufficient to provide a large degree of
+fingerprintability. Additionally, plugins are capable of extracting font lists,
+interface addresses, and other machine information that is beyond what the
+browser would normally provide to content. In addition, plugins can be used to
+store unique identifiers that are more difficult to clear than standard
+cookies.  <ulink url="http://epic.org/privacy/cookies/flash.html";>Flash-based
+cookies</ulink> fall into this category, but there are likely numerous other
+examples. Beyond fingerprinting, plugins are also abysmal at obeying the proxy
+settings of the browser. 
+
+
+     </para>
+     </listitem>
+     <listitem><command>Inserting CSS</command>
+     <para>
+
+<ulink url="https://developer.mozilla.org/En/CSS/Media_queries";>CSS media
+queries</ulink> can be inserted to gather information about the desktop size,
+widget size, display type, DPI, user agent type, and other information that
+was formerly available only to Javascript.
+
+     </para>
+     </listitem>
+     </orderedlist>
+     </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 our ability to defend against, but it is worth mentioning for
+completeness. <ulink url="http://tails.boum.org/contribute/design/";>The Tails
+system</ulink> however can provide some limited defenses against this
+adversary.
+
+     </para>
+     </listitem>
+    </orderedlist>
+   </sect2>
+
+</sect1>
 
 <sect1 id="Implementation">
   <title>Implementation</title>
@@ -789,36 +816,54 @@ using several Firefox preferences.
 
 The set of prefs is:
 <command>dom.storage.enabled</command>,
-<command>browser.cache.memory.enable</command>,
 <command>network.http.use-cache</command>,
 <command>browser.cache.disk.enable</command>,
+<command>browser.cache.disk.capacity</command>,
 <command>browser.cache.offline.enable</command>,
 <command>general.open_location.last_url</command>,
 <command>places.history.enabled</command>,
 <command>browser.formfill.enable</command>,
 <command>signon.rememberSignons</command>,
 <command>browser.download.manager.retention</command>,
+<command>dom.indexedDB.enabled</command>,
 and <command>network.cookie.lifetimePolicy</command>.
     </blockquote>
    </sect3>
     <para>
+
+Torbutton also <ulink
+url="https://gitweb.torproject.org/torbutton.git/blob/HEAD:/src/components/tbSessionStore.js";>contains
+code</ulink> to prevent the Firefox session store from writing to disk.
+
+    </para>
+    <para>
 In addition, three Firefox patches are needed to prevent disk writes, even if
 Private Browsing Mode is enabled. We need to
 
+<!-- XXX: Firefox 17 will mess up all these patch links -->
 <ulink
 url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.2:/src/current-patches/firefox/0002-Make-Permissions-Manager-memory-only.patch";>prevent
 the permissions manager from recording HTTPS STS state</ulink>,
 <ulink
 url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.2:/src/current-patches/firefox/0003-Make-Intermediate-Cert-Store-memory-only.patch";>prevent
-intermediate SSL certificates from being recorded</ulink>, and
+intermediate SSL certificates from being recorded</ulink>,
 <ulink
-url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.2:/src/current-patches/firefox/0008-Make-content-pref-service-memory-only-clearable.patch";>prevent
+url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.2:/src/current-patches/firefox/0013-Make-Download-manager-memory-only.patch";>prevent
+download history from being recorded</ulink>, and
+<ulink
+url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.2:/src/current-patches/firefox/0006-Make-content-pref-service-memory-only-clearable.patch";>prevent
 the content preferences service from recording site zoom</ulink>.
 
+<!-- XXX: DOM Storage patch, too. -->
+
 For more details on these patches, <link linkend="firefox-patches">see the
 Firefox Patches section</link>.
 
    </para>
+   <para>
+For more details on disk leak bugs and enhancements, see the <ulink
+url="https://trac.torproject.org/projects/tor/query?status=accepted&status=assigned&status=needs_information&status=needs_review&status=needs_revision&status=new&status=reopened&order=priority&col=id&col=summary&col=keywords&col=owner&col=type&col=status&col=priority&keywords=~tbb-disk-leak";>tbb-disk-leak tag in our bugtracker</ulink>
+   </para>
   </sect2>
   <sect2 id="app-data-isolation">
    <title>Application Data Isolation</title>



_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits