tor-commits
Threads by month
- ----- 2025 -----
- June
- May
- April
- March
- February
- January
- ----- 2024 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2011 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
April 2014
- 22 participants
- 2020 discussions

28 Apr '14
commit db1b7d233aa7f61f6e47fccb6907ba1997c116b6
Author: Mike Perry <mikeperry-git(a)fscked.org>
Date: Thu Sep 29 17:34:40 2011 -0700
Add fingerprinting material.
Also minor cleanups.
---
docs/design/design.xml | 219 ++++++++++++++++++++++++++++++++++++++++++------
1 file changed, 194 insertions(+), 25 deletions(-)
diff --git a/docs/design/design.xml b/docs/design/design.xml
index b0e261f..0c9b052 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>Sep 15 2011</pubdate>
+ <pubdate>Sep 29 2011</pubdate>
</articleinfo>
<!--
@@ -552,6 +552,7 @@ addons can introduce strange breakage and cause usability nightmares, and will a
fail to do their job if an adversary simply registers a new domain or creates
a new url path.
+<!-- XXX: Don't forget: Filters are also crazy fingerprintable -->
</para>
<para>
Furthermore, we are generally opposed to shipping an always-on Ad blocker with
@@ -821,14 +822,20 @@ used to load the page, as opposed to relying solely on the referer property.
Therefore, <ulink
url="http://crypto.stanford.edu/sameorigin/safecachetest.html">the original
stanford test
-cases</ulink> are expected to fail.
+cases</ulink> are expected to fail. Functionality can still be verified by
+navigating to <ulink url="about:cache">about:cache</ulink> and viewing the key
+used for each cache entry. Each third party element should have an additional
+"domain=string" property prepended, which will list the top-level urlbar
+domain that was used to source the third party element.
</para>
</listitem>
<listitem>HTTP Auth
<para>
-HTTP authentication tokens are removed for third parties on-modify-request
-observer to remove the headers to prevent <ulink
+HTTP authentication tokens are removed for third party elements using the
+<ulink
+url="https://developer.mozilla.org/en/Setting_HTTP_request_headers#Observers">http-on-modify-request
+observer</ulink> to remove the Authorization headers to prevent <ulink
url="http://jeremiahgrossman.blogspot.com/2007/04/tracking-users-without-cookies…">silent
linkability between domains</ulink>. We also needed to <ulink
url="https://gitweb.torproject.org/torbrowser.git/blob/refs/heads/maint-2.2:/src…">patch
@@ -922,7 +929,7 @@ properties that extend beyond any stored origin-related state. <ulink
url="https://panopticlick.eff.org/about.php">The Panopticlick Project</ulink>
by the EFF provides us with exactly this metric. The researchers conducted a
survey of volunteers who were asked to visit an experiment page that harvested
-many of the above compo- nents. They then computed the Shannon Entropy of the
+many of the above components. They then computed the Shannon Entropy of the
resulting distribution of each of several key attributes to determine how many
bits of identifying information each attribute provided.
@@ -931,10 +938,10 @@ bits of identifying information each attribute provided.
The study is not exhaustive, though. In particular, the test does not take in
all aspects of resolution information. It did not calculate the size of
-widgets, window decoration, or toolbar size. We believe this may add high
-amounts of entropy to the screen field. It also did not measure clock offset
-and other time-based fingerprints. Furthermore, as new browser features are
-added, this experiment should be repeated to include them.
+widgets, window decoration, or toolbar size, which we believe may add high
+amounts of entropy. It also did not measure clock offset and other time-based
+fingerprints. Furthermore, as new browser features are added, this experiment
+should be repeated to include them.
</para>
<para>
@@ -955,57 +962,205 @@ window.navigator.plugins, as well as their internal functionality.
</para>
<para><command>Design Goal:</command>
+
All plugins that have not been specifically audited or sandboxed must be
-disabled. Additionally, version information should be obfuscated until the
-plugin object is loaded... <!-- XXX: finish -->
+disabled. To reduce linkability potential, even sandboxed plugins should not
+be allowed to load objects until the user has clicked through a click-to-play
+barrier. Additionally, version information should be reduced or obfuscated
+until the plugin object is loaded.
+
</para>
<para><command>Implementation Status:</command>
+
+Currently, we entirely disable all plugins in Tor Browser. However, as a
+compromise due to the popularity of Flash, we intend to <ulink
+url="https://trac.torproject.org/projects/tor/ticket/3974">work
+towards</ulink> a
+click-to-play barrier using NoScript that is available only after the user has
+specifically enabled plugins. Flash will be the only plugin available, and we
+will ship a settings.sol file to disable Flash cookies, and to restrict P2P
+features that likely bypass proxy settings.
+
</para>
</listitem>
<listitem>Fonts
<para>
+According to the Panopticlick study, fonts provide the most linkability when
+they are provided as an enumeratable list in filesystem order, via either the
+Flash or Java plugins. However, it is still possible to use CSS and/or
+Javascript to query for the existence of specific fonts. With a large enough
+pre-built list to query, a large amount of fingerprintable information may
+still be available.
</para>
<para><command>Design Goal:</command>
+
+To address the Javascript issue, we intend to <ulink
+url="https://trac.torproject.org/projects/tor/ticket/2872">limit the number of
+fonts</ulink> an origin can load, gracefully degrading to built-in and/or
+remote fonts once the limit is reached.
+
</para>
<para><command>Implementation Status:</command>
+
+Aside from disabling plugins to prevent enumeration, we have not yet
+implmented any defense against CSS or Javascript fonts.
+
</para>
</listitem>
<listitem>User Agent and HTTP Headers
<para><command>Design Goal:</command>
+
+All Tor Browser users should provide websites with an identical user agent and
+HTTP header set for a given request type. We omit the Firefox minor revision,
+and report a popular Windows platform. If the software is kept up to date,
+these headers should remain identical across the population even when updated.
+
</para>
<para><command>Implementation Status:</command>
- </para>
+
+Firefox provides several options for controlling the browser user agent string
+which we leverage. We also set similar prefs for controlling the
+Accept-Language and Accept-Charset headers, which we spoof to English by default. Additionally, we
+<ulink
+url="https://gitweb.torproject.org/torbrowser.git/blob/refs/heads/maint-2.2:/src…">remove
+content script access</ulink> to Components.interfaces, which <ulink
+url="http://pseudo-flaw.net/tor/torbutton/fingerprint-firefox.html">can be
+used</ulink> to fingerprint OS, platform, and Firefox minor version. </para>
+
</listitem>
<listitem>Desktop resolution and CSS Media Queries
+ <para>
+
+Both CSS and Javascript have a lot of irrelevant information about the screen
+resolution, usable desktop size, OS widget size, toolbar size, title bar size, and
+other desktop features that are not at all relevant to rendering and serve
+only to provide information for fingerprinting.
+
+ </para>
<para><command>Design Goal:</command>
+
+Our design goal here is to reduce the resolution information down to the bare
+minimum required for properly rendering inside a content window. We intend to
+report all rendering information correctly with respect to the size and
+properties of the content window, but report an effective size of 0 for all
+border material, and also report that the desktop is only as big as the
+inner content window. Additionally, new browser windows are sized such that
+their content windows are one of ~5 fixed sizes based on the user's
+desktop resolution.
+
</para>
<para><command>Implementation Status:</command>
+
+We have implemented the above strategy for Javascript using Torbutton's <ulink
+url="https://gitweb.torproject.org/torbutton.git/blob/HEAD:/src/chrome/content/j…">JavaScript
+hooks</ulink> as well as a window observer to <ulink
+url="https://gitweb.torproject.org/torbutton.git/blob/HEAD:/src/chrome/content/t…">resize
+new windows based on desktop resolution</ulink>. However, CSS Media Queries
+still <ulink url="https://trac.torproject.org/projects/tor/ticket/2875">need
+to be dealt with</ulink>.
+
</para>
</listitem>
<listitem>Timezone and clock offset
<para><command>Design Goal:</command>
+
+All Tor Browser users should report the same timezone to websites. Currently,
+we choose UTC for this purpose, although an equally valid argument could be
+made for EDT/EST due to the large English-speaking population density.
+Additionally, the Tor software should detect if the users clock is
+significantly divergent from the clocks of the relays that it connects to, and
+use this to reset the clock values used in Tor Browser to something reasonably
+accurate.
+
</para>
<para><command>Implementation Status:</command>
+
+We set the timezone using the TZ environment variable, which is supported on
+all platforms. Additionally, we plan to <ulink
+url="https://trac.torproject.org/projects/tor/ticket/3652">obtain a clock
+offset from Tor</ulink>, but this won't be available until Tor 0.2.3.x is in
+use.
+
</para>
</listitem>
<listitem>Javascript performance fingerprinting
+ <para>
+
+<ulink url="http://w2spconf.com/2011/papers/jspriv.pdf">Javascript performance
+fingerprinting</ulink> is the act of profiling the performance
+of various Javascript functions for the purpose of fingerprinting the
+Javascript engine and the CPU.
+
+ </para>
<para><command>Design Goal:</command>
+
+We have <ulink
+url="https://trac.torproject.org/projects/tor/ticket/3059">several potential
+mitigation approaches</ulink> to reduce the accuracy of performance
+fingerprinting without risking too much damage to functionality. Our current
+favorite is to reduce the resolution of the Event.timeStamp and the Javascript
+Date() object, while also introducing jitter. Our goal is to increase the
+amount of time it takes to mount a successful attack. <ulink
+url="http://w2spconf.com/2011/papers/jspriv.pdf">Mowery et al</ulink> found that
+even with the default precision in most browsers, they required up to 120
+seconds of amortization and repeated trials to get stable results from their
+feature set. We intend to work with the research community to establish the
+optimum tradeoff between quantization+jitter and amoritization time.
+
+
</para>
<para><command>Implementation Status:</command>
+
+We have no implementation as of yet.
+
</para>
</listitem>
<listitem>Keystroke fingerprinting
+ <para>
+
+Keystroke fingerprinting is the act of measuring key strike time and key
+flight time. It is seeing increasing use as a biometric.
+
+ </para>
<para><command>Design Goal:</command>
+
+We intend to rely on the same mechanisms for defeating Javascript performance
+fingerprinting: timestamp quantization and jitter.
+
</para>
<para><command>Implementation Status:</command>
+We have no implementation as of yet.
</para>
</listitem>
<listitem>WebGL
+ <para>
+
+WebGL is fingerprintable both through information that is exposed about the
+underlying driver and optimizations, as well as through performance
+fingerprinting.
+
+ </para>
<para><command>Design Goal:</command>
+
+Because of the large amount of potential fingerprinting vectors, we intend to
+deploy a similar strategy against WebGL as for plugins. First, WebGL canvases
+will have click-to-play placeholders, and will not run until authorized by the
+user. Second, we indend to <ulink
+url="https://trac.torproject.org/projects/tor/ticket/3323">obfuscate driver
+information</ulink> by hooking
+<command>getParameter()</command>,
+<command>getSupportedExtensions()</command>,
+<command>getExtension()</command>, and
+<command>getContextAttributes()</command> to provide standard minimal,
+driver-neutral information.
+
</para>
<para><command>Implementation Status:</command>
+
+Currently we simply disable WebGL.
+
</para>
</listitem>
</orderedlist>
@@ -1017,8 +1172,19 @@ In order to avoid long-term linkability, we provide a "New Identity" context
menu option in Torbutton.
</para>
-<!-- XXX: Note tag? -->
- <para> <command>Implementation Status:</command> First, Torbutton disables
+ <sect3>
+ <title>Design Goal:</title>
+ <blockquote>
+
+All linkable identifiers and browser state should be cleared by this feature.
+
+ </blockquote>
+ </sect3>
+
+ <sect3>
+ <title>Implementation Status:</title>
+ <blockquote>
+ First, Torbutton disables
all open tabs and windows via nsIContentPolicy blocking, and then closes each
tab and window. The extra step for blocking tabs is done as a precaution to
ensure that any asynchornous Javascript is in fact properly disabled. After
@@ -1029,8 +1195,9 @@ geolocation token (if exists), HTTP auth, SSL Session IDs, and the last opened U
field (via the pref general.open_location.last_url). After clearing the
browser state, we then send the NEWNYM signal to the Tor control port to cause
a new circuit to be created.
+ </blockquote>
+ </sect3>
- </para>
<para>
XXX: Cookie protections..
<!-- XXX: Missing pieces:
@@ -1059,16 +1226,18 @@ audio and video objects.
<para>
The set of patches we have against Firefox can be found in the <ulink
url="https://gitweb.torproject.org/torbrowser.git/tree/refs/heads/maint-2.2:/src…">current-patches
-directory of the torbrowser git repository</ulink>
+directory of the torbrowser git repository</ulink>. They are:
</para>
<orderedlist>
<listitem>Block Components.interfaces and Components.lookupMethod
<para>
In order to reduce fingerprinting, we block access to these two interfaces
-from content script. Components.lookupMethod can undo our javascript hooks,
-and Components.interfaces is useful for fingerprinting the platform, OS, and
-Firebox version.
+from content script. Components.lookupMethod can undo our <ulink
+url="https://gitweb.torproject.org/torbutton.git/blob/HEAD:/src/chrome/content/j…">Javascript
+hooks</ulink>,
+and Components.interfaces can be used for fingerprinting the platform, OS, and
+Firebox version, but not much else.
</para>
</listitem>
@@ -1085,7 +1254,7 @@ does not need to be set in prefs.js, and can be handled by Torbutton.
</para>
<para><command>Design Goal:</command>
-As an additional design goal, we would like to later this patch to allow this
+As an additional design goal, we would like to later alter this patch to allow this
information to be cleared from memory. The implementation does not currently
allow this.
@@ -1095,7 +1264,7 @@ allow this.
<para>
The intermediate certificate store holds information about SSL certificates
-that may only be used by a limited number of domains. in some cases
+that may only be used by a limited number of domains. In some cases
effectively recording on disk the fact that a website owned by a certain
organization was viewed.
@@ -1103,7 +1272,7 @@ organization was viewed.
<!-- FIXME: Should this be a <note> tag too? -->
<para><command>Design Goal:</command>
-As an additional design goal, we would like to later this patch to allow this
+As an additional design goal, we would like to later alter this patch to allow this
information to be cleared from memory. The implementation does not currently
allow this.
@@ -1146,9 +1315,9 @@ pipeline, as well as their order.
</listitem>
<listitem>Block all plugins except flash
<para>
-<!-- XXX: Why allow flash at all?? Justify w/ a design goal describing a
-happy, safe-flash future... But here, or in some other section?? -->
-We cannot use the @mozilla.org/extensions/blocklist;1 service, because we
+We cannot use the <ulink
+url="http://www.oxymoronical.com/experiments/xpcomref/applications/Firefox/3.5/c…">
+(a)mozilla.org/extensions/blocklist;1</ulink> service, because we
actually want to stop plugins from ever entering the browser's process space
and/or executing code (for example, AV plugins that collect statistics/analyse
urls, magical toolbars that phone home or "help" the user, skype buttons that
1
0
commit e7d6b7f360e5f56d68f9368b01fd7235a689844c
Author: Mike Perry <mikeperry-git(a)fscked.org>
Date: Sun Sep 25 17:45:22 2011 -0700
Add philosophy outline.
Also clean up some more prose.
---
docs/design/design.xml | 189 ++++++++++++++++++++++++++++++++++++++----------
1 file changed, 150 insertions(+), 39 deletions(-)
diff --git a/docs/design/design.xml b/docs/design/design.xml
index 0030fa5..2b493d2 100644
--- a/docs/design/design.xml
+++ b/docs/design/design.xml
@@ -4,7 +4,7 @@
<article id="design">
<articleinfo>
- <title>The Design and Implementation of the Tor Browser</title>
+ <title>The Design and Implementation of the Tor Browser [DRAFT]</title>
<author>
<firstname>Mike</firstname><surname>Perry</surname>
<affiliation>
@@ -220,10 +220,11 @@ attacks</ulink>.
<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>.
+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>. In addition, the ad networks of course perform tracking
+with cookies as well.
</para>
</listitem>
@@ -234,7 +235,7 @@ 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.
+ad network-class adversaries.
</para>
</listitem>
@@ -247,6 +248,8 @@ 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
@@ -257,7 +260,6 @@ url="http://developer.mozilla.org/en/docs/DOM:window.screen">window.screen</ulin
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
@@ -273,11 +275,10 @@ for the title bar and 3 common sizes for browser GUI element fonts).
Multiply this all out, and you have (1280-640)*(1024-480)*5*5*8*9 ~=
2<superscript>29</superscript>, or a 29 bit identifier based on resolution
information alone. </para>
-
+-->
<para>
-Of course, this space is non-uniform in user density and prone to incremental
-changes. The <ulink
+The <ulink
url="https://wiki.mozilla.org/Fingerprinting#Data">Panopticlick study
done</ulink> by the EFF attempts to measure the actual entropy - the number of
identifying bits of information encoded in browser properties. Their result
@@ -288,6 +289,8 @@ they could from display information: they only use desktop resolution (which
Torbutton reports as the window resolution) and do not attempt to infer the
size of toolbars.
+<!-- XXX: Also, new browser features are added regularly. -->
+
</para>
<!--
FIXME: This is no longer true. Only certain addons are now discoverable, and
@@ -341,16 +344,17 @@ for completeness.
- Does not share state with other modes/browsers
- Easy to remove + wipe with external tools
- click-to-play for "troublesome" features
+ - Philosophy
- No filters
-->
-<sect1 id="Design">
- <title>Design and Philosophy</title>
+<sect1 id="DesignRequirements">
+ <title>Design Requirements and Philosophy</title>
<para>
The Tor Browser is meant to serve as a specification and a reference
implementation of a Private Browsing Mode that defends against both Network
-and Local adversaries.
+and Local Adversaries.
</para>
<para>
@@ -360,15 +364,21 @@ Privacy Requirements. Security Requirements are the minimum properties in
order for a web client platform to be able to support Tor. Privacy
requirements are the set of properties that cause us to prefer one platform
over another.
+ </para>
+ <para>
We will maintain an alternate distribution of the web client in order to
-maintain and/or restore privacy properties to our users.
+maintain and/or restore privacy properties to our users.
</para>
<sect2 id="security">
<title>Security Requirements</title>
<para>
+The security requirements are primarily concerned with ensuring the safe use
+of Tor. Violations in these properties typically result in serious risk for
+the user in terms of immediate deanonymization and/or observability.
+
</para>
<orderedlist>
@@ -377,9 +387,10 @@ maintain and/or restore privacy properties to our users.
MUST NOT bypass Tor proxy settings for any content.</para></listitem>
<listitem><command>State Separation</command>
+
<para>The browser MUST NOT provide any stored state to the content window
-from other browsing modes, including shared state from plugins, machine
-identifers, and TLS session state.
+from other browsers or other browsing modes, including shared state from
+plugins, machine identifers, and TLS session state.
</para></listitem>
<listitem><command>Disk Avoidance</command><para>The
@@ -388,7 +399,7 @@ in memory beyond the duration of one Tor session, unless the user has
explicitly opted to store their browsing history information to
disk.</para></listitem>
- <listitem><command>Disk Isolation</command><para>The Tor
+ <listitem><command>Application Data Isolation</command><para>The Tor
components of the browser MUST NOT write or cause the Operating System to
write <emphasis>any information</emphasis> to disk outside of the application
directory. All exceptions and shortcomings due to Operating System behavior
@@ -399,10 +410,14 @@ MUST BE documented.
</orderedlist>
</sect2>
- <sect2 id="Privacy">
+ <sect2 id="privacy">
<title>Privacy Requirements</title>
<para>
+The privacy requirements are primarily concerned with reducing linkability:
+the ability for a user's actvitity on one site to be linked with their
+activity on another site without their knowledge or explicit consent.
+
</para>
<orderedlist>
@@ -412,7 +427,8 @@ MUST BE documented.
User activity on one url bar domain MUST NOT be linkable to their activity in
any other domain by any third party. This property specifically applies to
linkability from stored browser identifiers, authentication tokens, and shared
-state.
+state. This functionality SHOULD NOT interfere with federated login in a
+substantial way.
</para>
</listitem>
@@ -425,6 +441,57 @@ linkability from fingerprinting browser behavior.
</para>
</listitem>
+ <listitem><command>Long-Term Unlinkability</command>
+ <para>
+
+Users SHOULD have an obvious, easy way to remove all of their authentication
+tokens and browser state and obtain a fresh identity. Additionally, this
+should happen by default automatically upon browser restart.
+
+ </para>
+ </listitem>
+</orderedlist>
+
+ </sect2>
+ <sect2 id="philosophy">
+ <title>Philosophy</title>
+ <para>
+
+In addition to the above design requirements, the technology decisions about
+Tor Browser are also guided by some philosophical positions about technology.
+
+ </para>
+ <orderedlist>
+ <listitem>Preserve existing user model
+ <para>
+
+The existing way that the user expects to use a browser must be preserved. If
+the user has to maintain a different mental model of how the sites they are
+using behave depending on tab, browser state, or anything else that would not
+normally be what they experience in their default browser, the user will
+inevitably be confused. They will become confused, make mistakes, and reduce
+their privacy as a result. Worse, they may just stop using the browser,
+assuming it is broken.
+
+ </para>
+ <para>
+
+User model breakage was one of the failures of Torbutton: Even if users
+managed to install everything properly, the toggle model was too hard for the
+average user to understand, especially in the face of accumulating tabs from
+multiple states crossed with the current tor-state of the browser.
+
+ </para>
+ </listitem>
+ <listitem>Minimal breakage to support requirements
+ <para>
+
+Minimal
+
+
+ </para>
+ </listitem>
+ <listitem>Plugins must be restricted
<!--
<listitem id="click-to-play"><command>Click-to-play for plugins and invasive content</command>
<para>
@@ -442,10 +509,22 @@ sites, to reduce linkability.
</para>
</listitem>
-->
-</orderedlist>
+ <para>
+ </para>
+ </listitem>
+ <listitem>No filters</listitem>
+ <para>
+ </para>
+ <listitem>Stay Current</listitem>
+ <para>
+We believe that if we do not stay current with the support of new web
+technologies, we cannot hope to substantially influence or be involved in
+their proper deployment or realization. However, we will likely disable
+certain new features (where possible) pending analysis and audit.
+ </para>
+ </orderedlist>
</sect2>
-
</sect1>
<!--
@@ -547,6 +626,7 @@ For now, Tor Browser blocks write access to the disk through Torbutton
using several Firefox preferences.
<!-- XXX: http auth on disk??? -->
+<!-- XXX: can general.open_location.last_url hit disk??? -->
The set of prefs is:
<command>dom.storage.enabled</command>,
@@ -580,8 +660,8 @@ Firefox Patches section</link>.
</para>
</sect2>
- <sect2 id="disk-isolation">
- <title>Disk Isolation</title>
+ <sect2 id="app-data-isolation">
+ <title>Application Data Isolation</title>
<para>
Tor Browser Bundle MUST NOT cause any information to be written outside of the
@@ -602,6 +682,7 @@ and/or what additional work or auditing needs to be done.
</sect2>
<sect2 id="identifier-linkability">
<title>Cross-Domain Identifier Unlinkability</title>
+ <!-- XXX: Mention web-send?? -->
<para>
The Tor Browser MUST prevent a user's activity on one site from being linked
@@ -609,7 +690,11 @@ to their activity on another site. When this goal cannot yet be met with an
existing web technology, that technology or functionality is disabled. Our
design goal is to ultimately eliminate the need to disable arbitrary
technologies, and instead simply alter them in ways that allows them to
-function in a backwards-compatible way while avoiding linkability.
+function in a backwards-compatible way while avoiding linkability. Users
+should be able to use federated login of various kinds to explicitly inform
+sites who they are, but that information should not transparently allow a
+third party to record their activity from site to site without their prior
+consent.
</para>
<para>
@@ -755,24 +840,49 @@ functionality.
<title>Cross-Domain Fingerprinting Unlinkability</title>
<para>
</para>
+ <!-- XXX: Panopticlick set + others -->
+ <orderedlist>
+ <listitem>Desktop resolution
+ <para>
+ </para>
+ </listitem>
+ <listitem>Timezone and clock offset
+ <para>
+ </para>
+ </listitem>
+ <listitem>WebGL
+ <para>
+ </para>
+ </listitem>
+ <listitem>Fonts
+ <para>
+ </para>
+ </listitem>
+ </orderedlist>
</sect2>
<sect2 id="new-identity">
- <title>Provide "New Identity" button to purge all state</title>
+ <title>Long-Term Unlinkability via "New Identity" button</title>
+ <para>
+In order to avoid long-term linkability, we provide a "New Identity" context
+menu option in Torbutton.
+ </para>
+
+ <para> <command>Implementation Status:</command> First, Torbutton disables
+all open tabs and windows via nsIContentPolicy blocking, and then closes each
+tab and window. The extra step for blocking tabs is done as a precaution to
+ensure that any asynchornous Javascript is in fact properly disabled. After
+closing all of the windows, we then clear the following state: OCSP (by
+toggling security.OCSP.enabled), cache, site-specific zoom and content
+preferences, Cookies, DOM storage, safe browsing key, the google wifi
+geolocation token (if exists), HTTP auth, SSL Session IDs, and the last opened URL
+field (via the pref general.open_location.last_url). After clearing the
+browser state, we then send the NEWNYM signal to the Tor control port to cause
+a new circuit to be created.
+
+ </para>
<para>
-XXX: make this prettier
- 0. Disables all open tabs and windows.
- 1. Closes all tabs and windows
- 2. Clears state:
- a. OCSP
- b. Cache
- c. Site-specific zoom
- d. Cookies+DOM Storage+safe browsing key
- e. google wifi geolocation token
- f. http auth
- g. SSL Session IDs
- h. last open location url
- i. clear content prefs
- 3. Sends tor the NEWNYM signal to get a new circuit
+XXX: Cookie protections..
+XXX: Missing pieces: DOM Storage?
</para>
</sect2>
<sect2 id="click-to-play">
@@ -938,6 +1048,7 @@ other site prefs?).
</sect3>
<sect3>
<title>Excluded Addons</title>
+ <!-- XXX: Adblock, RequestPolicy, ShareMeNot, priv3 -->
</sect3>
<sect3>
<title>Dangerous Addons</title>
1
0
commit 17bbe6aaf956a2075dd6e3747eb59a2c64cb7a61
Author: Mike Perry <mikeperry-git(a)fscked.org>
Date: Thu Sep 29 17:39:31 2011 -0700
Speel check.
---
docs/design/design.xml | 42 +++++++++++++++++++++---------------------
1 file changed, 21 insertions(+), 21 deletions(-)
diff --git a/docs/design/design.xml b/docs/design/design.xml
index 0c9b052..cc2b27b 100644
--- a/docs/design/design.xml
+++ b/docs/design/design.xml
@@ -383,7 +383,7 @@ MUST NOT bypass Tor proxy settings for any content.</para></listitem>
<para>The browser MUST NOT provide any stored state to the content window
from other browsers or other browsing modes, including shared state from
-plugins, machine identifers, and TLS session state.
+plugins, machine identifiers, and TLS session state.
</para></listitem>
<listitem><command>Disk Avoidance</command><para>The
@@ -408,7 +408,7 @@ MUST BE documented.
<para>
The privacy requirements are primarily concerned with reducing linkability:
-the ability for a user's actvitity on one site to be linked with their
+the ability for a user's activity on one site to be linked with their
activity on another site without their knowledge or explicit consent.
</para>
@@ -491,7 +491,7 @@ site breakage, though this is not always possible.
Even if plugins always properly used the browser proxy settings (which none of
them do) and could not be induced to bypass them (which all of them can), the
-activies of closed-source plugins are very difficult to audit and control.
+activities of closed-source plugins are very difficult to audit and control.
They can obtain and transmit all manner of system information to websites,
often have their own identifier storage for tracking users, and also
contribute to fingerprinting.
@@ -525,7 +525,7 @@ Instead of global browser privacy options, privacy decisions should be made
<ulink
url="https://wiki.mozilla.org/Privacy/Features/Site-based_data_management_UI">per
top-level url-bar domain</ulink> to eliminate the possibility of linkability
-between domains. For example, when a plugin object (or a JavaScript access of
+between domains. For example, when a plugin object (or a Javascript access of
window.plugins) is present in a page, the user should be given the choice of
allowing that plugin object for that top-level url-bar domain only. The same
goes for exemptions to third party cookie policy, geo-location, and any other
@@ -559,7 +559,7 @@ Furthermore, we are generally opposed to shipping an always-on Ad blocker with
Tor Browser. We feel that this would damage our credibility in terms of
demonstrating that we are providing privacy through a sound design alone, as
well as damage the acceptance of Tor users by sites who support themselves
-through advertizing revenue.
+through advertising revenue.
</para>
<para>
Users are free to install these addons if they wish, but doing
@@ -705,7 +705,7 @@ url="https://gitweb.torproject.org/torbrowser.git/blob/refs/heads/maint-2.2:/src
the permissions manager from recording HTTPS STS state</ulink>,
<ulink
url="https://gitweb.torproject.org/torbrowser.git/blob/refs/heads/maint-2.2:/src…">prevent
-intermediate SSL certficates from being recorded</ulink>, and
+intermediate SSL certificates from being recorded</ulink>, and
<ulink
url="https://gitweb.torproject.org/torbrowser.git/blob/refs/heads/maint-2.2:/src…">prevent
the content preferences service from recording site zoom</ulink>.
@@ -784,7 +784,7 @@ apply to modern Firefoxes.
As a stopgap to satisfy our design requirement of unlinkability, we currently
entirely disable 3rd party cookies by setting
<command>network.cookie.cookieBehavior</command> to 1. We would prefer that
-third party content continue to funtion , but we believe the requirement for
+third party content continue to function , but we believe the requirement for
unlinkability trumps that desire.
</para>
@@ -812,16 +812,16 @@ url bar domain as input to this field.
<!-- FIXME: This could use a few more specifics.. Maybe. The Chrome folks
won't care, but the Mozilla folks might. -->
-Furthermore, we chose a different isolation scheme than the stanford
-implemention. First, we decoupled the cache isolation from the third party
-cookie attribute. Second, we use several machanisms to attempt to determine
+Furthermore, we chose a different isolation scheme than the Stanford
+implementation. First, we decoupled the cache isolation from the third party
+cookie attribute. Second, we use several mechanisms to attempt to determine
the actual location attribute of the top-level window (the url bar domain)
used to load the page, as opposed to relying solely on the referer property.
</para>
<para>
Therefore, <ulink
url="http://crypto.stanford.edu/sameorigin/safecachetest.html">the original
-stanford test
+Stanford test
cases</ulink> are expected to fail. Functionality can still be verified by
navigating to <ulink url="about:cache">about:cache</ulink> and viewing the key
used for each cache entry. Each third party element should have an additional
@@ -947,7 +947,7 @@ should be repeated to include them.
<para>
On the other hand, to avoid an infinite sinkhole, we reduce the efforts for
-fingerprinting resistence by only concerning ourselves with reducing the
+fingerprinting resistance by only concerning ourselves with reducing the
fingerprintable differences <emphasis>among</emphasis> Tor Browser users. We
do not believe it is productive to concern ourselves with cross-browser
fingerprinting issues, at least not at this stage.
@@ -987,7 +987,7 @@ features that likely bypass proxy settings.
<para>
According to the Panopticlick study, fonts provide the most linkability when
-they are provided as an enumeratable list in filesystem order, via either the
+they are provided as an enumerable list in filesystem order, via either the
Flash or Java plugins. However, it is still possible to use CSS and/or
Javascript to query for the existence of specific fonts. With a large enough
pre-built list to query, a large amount of fingerprintable information may
@@ -1005,7 +1005,7 @@ remote fonts once the limit is reached.
<para><command>Implementation Status:</command>
Aside from disabling plugins to prevent enumeration, we have not yet
-implmented any defense against CSS or Javascript fonts.
+implemented any defense against CSS or Javascript fonts.
</para>
</listitem>
@@ -1107,7 +1107,7 @@ url="http://w2spconf.com/2011/papers/jspriv.pdf">Mowery et al</ulink> found that
even with the default precision in most browsers, they required up to 120
seconds of amortization and repeated trials to get stable results from their
feature set. We intend to work with the research community to establish the
-optimum tradeoff between quantization+jitter and amoritization time.
+optimum tradeoff between quantization+jitter and amortization time.
</para>
@@ -1147,7 +1147,7 @@ fingerprinting.
Because of the large amount of potential fingerprinting vectors, we intend to
deploy a similar strategy against WebGL as for plugins. First, WebGL canvases
will have click-to-play placeholders, and will not run until authorized by the
-user. Second, we indend to <ulink
+user. Second, we intend to <ulink
url="https://trac.torproject.org/projects/tor/ticket/3323">obfuscate driver
information</ulink> by hooking
<command>getParameter()</command>,
@@ -1187,10 +1187,10 @@ All linkable identifiers and browser state should be cleared by this feature.
First, Torbutton disables
all open tabs and windows via nsIContentPolicy blocking, and then closes each
tab and window. The extra step for blocking tabs is done as a precaution to
-ensure that any asynchornous Javascript is in fact properly disabled. After
+ensure that any asynchronous Javascript is in fact properly disabled. After
closing all of the windows, we then clear the following state: OCSP (by
toggling security.OCSP.enabled), cache, site-specific zoom and content
-preferences, Cookies, DOM storage, safe browsing key, the google wifi
+preferences, Cookies, DOM storage, safe browsing key, the Google wifi
geolocation token (if exists), HTTP auth, SSL Session IDs, and the last opened URL
field (via the pref general.open_location.last_url). After clearing the
browser state, we then send the NEWNYM signal to the Tor control port to cause
@@ -1319,14 +1319,14 @@ We cannot use the <ulink
url="http://www.oxymoronical.com/experiments/xpcomref/applications/Firefox/3.5/c…">
@mozilla.org/extensions/blocklist;1</ulink> service, because we
actually want to stop plugins from ever entering the browser's process space
-and/or executing code (for example, AV plugins that collect statistics/analyse
-urls, magical toolbars that phone home or "help" the user, skype buttons that
+and/or executing code (for example, AV plugins that collect statistics/analyze
+URLs, magical toolbars that phone home or "help" the user, skype buttons that
ruin our day, and censorship filters). Hence we rolled our own.
</para>
</listitem>
<listitem>Make content-prefs service memory only
<para>
-This patch prevents random urls from being inserted into content-prefs.sqllite in
+This patch prevents random URLs from being inserted into content-prefs.sqllite in
the profile directory as content prefs change (includes site-zoom and perhaps
other site prefs?).
</para>
1
0

28 Apr '14
commit 65eea97d5006c0daaa68266e47c92821aa7109fc
Author: Mike Perry <mikeperry-git(a)fscked.org>
Date: Thu Sep 29 18:37:51 2011 -0700
Add cookie managers graphic.
---
docs/design/CookieManagers.png | Bin 0 -> 121020 bytes
docs/design/design.xml | 66 +++++++++++++++++++++++++---------------
2 files changed, 42 insertions(+), 24 deletions(-)
diff --git a/docs/design/CookieManagers.png b/docs/design/CookieManagers.png
new file mode 100644
index 0000000..b979f30
Binary files /dev/null and b/docs/design/CookieManagers.png differ
diff --git a/docs/design/design.xml b/docs/design/design.xml
index cc2b27b..2c87e74 100644
--- a/docs/design/design.xml
+++ b/docs/design/design.xml
@@ -540,26 +540,29 @@ permissions can be written to disk. Otherwise, they should remain memory-only.
<para>
Filter-based addons such as <ulink
-url="https://addons.mozilla.org/en-US/firefox/addon/adblock-plus/">AdBlock Plus</ulink>, <ulink
-url="">Request Policy</ulink>, <ulink url="http://priv3.icsi.berkeley.edu/">Priv3</ulink>, and <ulink
+url="https://addons.mozilla.org/en-US/firefox/addon/adblock-plus/">AdBlock
+Plus</ulink>, <ulink url="">Request Policy</ulink>, <ulink
+url="http://priv3.icsi.berkeley.edu/">Priv3</ulink>, and <ulink
url="http://sharemenot.cs.washington.edu/">Sharemenot</ulink> are to be
-avoided. We believe
-that these addons do not add any real privacy to a proper <link
-linkend="Implementation">implementation</link> of
-the above <link linkend="privacy">privacy requirements</link>, as all third parties are prevented from
-tracking users between sites by the implementation. Furthermore, filter-based
-addons can introduce strange breakage and cause usability nightmares, and will also
-fail to do their job if an adversary simply registers a new domain or creates
-a new url path.
-
-<!-- XXX: Don't forget: Filters are also crazy fingerprintable -->
+avoided. We believe that these addons do not add any real privacy to a proper
+<link linkend="Implementation">implementation</link> of the above <link
+linkend="privacy">privacy requirements</link>, as all third parties are
+prevented from tracking users between sites by the implementation.
+Filter-based addons can also introduce strange breakage and cause usability
+nightmares, and will also fail to do their job if an adversary simply
+registers a new domain or creates a new url path. Worse still, the unique
+filter sets that each user is liable to create/install likely provide a wealth
+of fingerprinting targets.
+
</para>
<para>
-Furthermore, we are generally opposed to shipping an always-on Ad blocker with
-Tor Browser. We feel that this would damage our credibility in terms of
-demonstrating that we are providing privacy through a sound design alone, as
-well as damage the acceptance of Tor users by sites who support themselves
-through advertising revenue.
+
+As a general matter, we are also generally opposed to shipping an always-on Ad
+blocker with Tor Browser. We feel that this would damage our credibility in
+terms of demonstrating that we are providing privacy through a sound design
+alone, as well as damage the acceptance of Tor users by sites who support
+themselves through advertising revenue.
+
</para>
<para>
Users are free to install these addons if they wish, but doing
@@ -739,7 +742,7 @@ XXX: Write me..
-->
<sect2 id="identifier-linkability">
<title>Cross-Domain Identifier Unlinkability</title>
- <!-- XXX: Mention web-send?? -->
+ <!-- FIXME: Mention web-send?? -->
<para>
The Tor Browser MUST prevent a user's activity on one site from being linked
@@ -763,11 +766,28 @@ six or seven different pieces of privacy UI governing these identifiers and
permissions can become just one piece of UI. For instance, a window that lists
the top-level url bar domains for which browser state exists with the ability
to clear and/or block them, possibly with a context-menu option to drill down
-into specific types of state.
-
-<!-- XXX: Include graphic as a 'Design Goal' -->
+into specific types of state. An exmaple of this simplifcation can be seen in
+Figure 1.
</para>
+ <figure><title>Improving the Privacy UI</title>
+ <mediaobject>
+ <imageobject>
+ <imagedata align="center" fileref="CookieManagers.png"/>
+ </imageobject>
+ </mediaobject>
+ <caption> <para/>
+
+On the left is the standard Firefox cookie manager. On the right is a mock-up
+of how isolating identifiers to the URL bar domain might simplify the privacy
+UI for all data - not just cookies. Both windows represent the set of
+Cookies accomulated after visiting just five sites, but the window on the
+right has the option of also representing history, DOM Storage, HTTP Auth,
+search form history, login values, and so on within a context menu for each
+site.
+
+</caption>
+ </figure>
<orderedlist>
<listitem>Cookies
<para><command>Design Goal:</command>
@@ -1198,13 +1218,11 @@ a new circuit to be created.
</blockquote>
</sect3>
- <para>
-XXX: Cookie protections..
<!-- XXX: Missing pieces:
1. DOM Storage? IIRC, it is cleared, but also disabled anyway.
2. Do we kill keep-alive connections properly?
+XXX: Cookie protections..
-->
- </para>
</sect2>
<sect2 id="click-to-play">
<title>Click-to-play for plugins and invasive content</title>
1
0

[tor-browser-spec/master] Add intro + fill in fingerprinting section a bit.
by mikeperry@torproject.org 28 Apr '14
by mikeperry@torproject.org 28 Apr '14
28 Apr '14
commit 2f46060e4832e714676a33c404cfe1505070b685
Author: Mike Perry <mikeperry-git(a)fscked.org>
Date: Tue Sep 27 00:25:21 2011 -0700
Add intro + fill in fingerprinting section a bit.
Also random cleanups.
---
docs/design/design.xml | 225 +++++++++++++++++++++++++++++++++++++-----------
1 file changed, 173 insertions(+), 52 deletions(-)
diff --git a/docs/design/design.xml b/docs/design/design.xml
index 2fd3dc0..e3870e6 100644
--- a/docs/design/design.xml
+++ b/docs/design/design.xml
@@ -35,10 +35,19 @@
<title>Introduction</title>
<para>
-<!-- XXX: intro + version
-This document describes the goals, operation, and testing procedures of the
-Torbutton Firefox extension. It is current as of Tor Browser 2.2.32-4.
--->
+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.32-4.
+
+ </para>
+ <para>
+
+This document is also meant to serve as a set of design requirements and to
+describe a reference implementation of a Private Browsing Mode that defends
+against both local and network adversaries.
</para>
<sect2 id="adversary">
@@ -47,7 +56,7 @@ Torbutton Firefox extension. It is current as of Tor Browser 2.2.32-4.
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.
+Tor Browser. Let's start with the goals.
</para>
<sect3 id="adversarygoals">
@@ -296,12 +305,16 @@ size of toolbars.
<listitem><command>Remotely or locally exploit browser and/or
OS</command>
<para>
-Last, but definitely not least, the adversary can exploit either general
+
+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.
+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>
@@ -331,18 +344,19 @@ for completeness.
<title>Design Requirements and Philosophy</title>
<para>
-The Tor Browser is meant to serve as a specification and a reference
-implementation of a Private Browsing Mode that defends against both Network
-and Local Adversaries.
+The Tor Browser Design Requirements are meant to describe the properties of a
+Private Browsing Mode that defends against both network and local adversaries.
</para>
<para>
-There are two main categories of requirements: Security Requirements, and
-Privacy Requirements. Security Requirements are the minimum properties in
-order for a web client platform to be able to support Tor. Privacy
-requirements are the set of properties that cause us to prefer one platform
-over another.
+There are two main categories of requirements: <link
+linkend="security">Security Requirements</link>, and <link
+linkend="privacy">Privacy Requirements</link>. Security Requirements are the
+minimum properties in order for a web client platform to be able to support
+Tor. Privacy requirements are the set of properties that cause us to prefer
+one platform over another.
+
</para>
<para>
@@ -378,10 +392,10 @@ in memory beyond the duration of one Tor session, unless the user has
explicitly opted to store their browsing history information to
disk.</para></listitem>
- <listitem><command>Application Data Isolation</command><para>The Tor
-components of the browser MUST NOT write or cause the Operating System to
+ <listitem><command>Application Data Isolation</command><para>The browser
+MUST NOT write or cause the operating system to
write <emphasis>any information</emphasis> to disk outside of the application
-directory. All exceptions and shortcomings due to Operating System behavior
+directory. All exceptions and shortcomings due to operating system behavior
MUST BE documented.
</para></listitem>
@@ -423,7 +437,7 @@ linkability from fingerprinting browser behavior.
<listitem><command>Long-Term Unlinkability</command>
<para>
-Users SHOULD have an obvious, easy way to remove all of their authentication
+The browser SHOULD provide an obvious, easy way to remove all of their authentication
tokens and browser state and obtain a fresh identity. Additionally, this
should happen by default automatically upon browser restart.
@@ -463,7 +477,8 @@ tor-state of the browser.
</para>
</listitem>
- <listitem><command>Minimal breakage to support requirements</command>
+ <listitem><command>Favor the implementation mechanism least likely to
+break sites</command>
<para>
In general, we try to find solutions to privacy issues that will not induce
@@ -473,19 +488,23 @@ site breakage, though this is not always possible.
</listitem>
<listitem><command>Plugins must be restricted</command>
<para>
+
Even if plugins always properly used the browser proxy settings (which none of
-them do) and can't be induced to bypass them (which all of them can), the
+them do) and could not be induced to bypass them (which all of them can), the
activies of closed-source plugins are very difficult to audit and control.
-They can obtain and transmit all manner of system information to websites, and
-often have their own identifier storage for tracking users.
+They can obtain and transmit all manner of system information to websites,
+often have their own identifier storage for tracking users, and also
+contribute to fingerprinting.
+
</para>
<para>
Therefore, if plugins are to be enabled in private browsing modes, they must
be restricted from running automatically on every page (via click-to-play
placeholders), and/or be sandboxed to restrict the types of system calls they
-can execute. If the user decides to craft an exemption, it MUST ONLY apply to
-the top level urlbar domain, and not to all sites, to reduce linkability.
+can execute. If the user decides to craft an exemption to allow a plugin to be
+used, it MUST ONLY apply to the top level urlbar domain, and not to all sites,
+to reduce linkability.
</para>
</listitem>
@@ -494,11 +513,11 @@ the top level urlbar domain, and not to all sites, to reduce linkability.
<ulink url="https://trac.torproject.org/projects/tor/ticket/3100">Another
failure of Torbutton</ulink> was (and still is) the options panel. Each option
-that detectably alters browser behavior can be used as a fingerprinting tool
-on the part of ad networks. Similarly, all extensions <ulink
+that detectably alters browser behavior can be used as a fingerprinting tool.
+Similarly, all extensions <ulink
url="http://blog.chromium.org/2010/06/extensions-in-incognito.html">should be
disabled in the mode</ulink> except as an opt-in basis. We should not load
-system addons or plugins.
+system-wide addons or plugins.
</para>
<para>
@@ -516,24 +535,41 @@ privacy permissions.
If the user has indicated they do not care about local history storage, these
permissions can be written to disk. Otherwise, they should remain memory-only.
</para>
- </para>
- </listitem>
- <para>
- </para>
</listitem>
<listitem><command>No filters</command>
<para>
-<!-- XXX: Might want to briefly explain why -->
-We don't need no stinking filters.
+Filter-based addons such as <ulink
+url="https://addons.mozilla.org/en-US/firefox/addon/adblock-plus/">AdBlock Plus</ulink>, <ulink
+url="">Request Policy</ulink>, <ulink url="http://priv3.icsi.berkeley.edu/">Priv3</ulink>, and <ulink
+url="http://sharemenot.cs.washington.edu/">Sharemenot</ulink> are to be
+avoided. We believe
+that these addons do not add any real privacy to a proper <link
+linkend="Implementation">implementation</link> of
+the above <link linkend="privacy">privacy requirements</link>, as all third parties are prevented from
+tracking users between sites by the implementation. Furthermore, filter-based
+addons can introduce strange breakage and cause usability nightmares, and will also
+fail to do their job if an adversary simply registers a new domain or creates
+a new url path.
</para>
+ <para>
+Furthermore, we are generally opposed to shipping an always-on Ad blocker with
+Tor Browser. We feel that this would damage our credibility in terms of
+demonstrating that we are providing privacy through a sound design alone, as
+well as damage the acceptance of Tor users by sites who support themselves
+through advertizing revenue.
+ </para>
+ <para>
+Users are free to install these addons if they wish, but doing
+so is not recommended, as it will alter the browser request fingerprint.
+ </para>
</listitem>
<listitem><command>Stay Current</command>
<para>
We believe that if we do not stay current with the support of new web
technologies, we cannot hope to substantially influence or be involved in
-their proper deployment or realization. However, we will likely disable
+their proper deployment or privacy realization. However, we will likely disable
certain new features (where possible) pending analysis and audit.
</para>
</listitem>
@@ -627,18 +663,18 @@ Flash cookies from leaking from a pre-existing Flash directory.
<title>Disk Avoidance</title>
<sect3>
<title>Design Goal:</title>
- <para>
+ <blockquote>
Tor Browser should optionally prevent all disk records of browser activity.
The user should be able to optionally enable URL history and other history
features if they so desire. Once we <ulink
url="https://trac.torproject.org/projects/tor/ticket/3100">simplify the
preferences interface</ulink>, we will likely just enable Private Browsing
mode by default to handle this goal.
- </para>
+ </blockquote>
</sect3>
<sect3>
<title>Implementation Status:</title>
- <para>
+ <blockquote>
For now, Tor Browser blocks write access to the disk through Torbutton
using several Firefox preferences.
@@ -655,9 +691,9 @@ The set of prefs is:
<command>places.history.enabled</command>,
<command>browser.formfill.enable</command>,
<command>signon.rememberSignons</command>,
-<command>browser.download.manager.retention <!-- XXX: needs patch --></command>,
+<command>browser.download.manager.retention</command>,
and <command>network.cookie.lifetimePolicy</command>.
- </para>
+ </blockquote>
</sect3>
<para>
In addition, three Firefox patches are needed to prevent disk writes, even if
@@ -696,6 +732,7 @@ and/or what additional work or auditing needs to be done.
<title>Update Safety</title>
<para>
<!-- XXX: Design goal vs implementation status -->
+XXX: Write me..
</para>
</sect2>
<sect2 id="identifier-linkability">
@@ -706,7 +743,7 @@ and/or what additional work or auditing needs to be done.
The Tor Browser MUST prevent a user's activity on one site from being linked
to their activity on another site. When this goal cannot yet be met with an
existing web technology, that technology or functionality is disabled. Our
-design goal is to ultimately eliminate the need to disable arbitrary
+<link linkend="privacy">design goal</link> is to ultimately eliminate the need to disable arbitrary
technologies, and instead simply alter them in ways that allows them to
function in a backwards-compatible way while avoiding linkability. Users
should be able to use federated login of various kinds to explicitly inform
@@ -813,6 +850,26 @@ domain, we entirely disable DOM storage as a stopgap to ensure unlinkability.
</para>
</listitem>
+ <listitem>TLS session resumption and HTTP Keep-Alive
+ <para>
+TLS session resumption and HTTP Keep-Alive must not allow third party origins
+to track users via either TLS session IDs, or the fact that different requests
+arrive on the same TCP connection.
+ </para>
+ <para><command>Design Goal:</command>
+
+TLS session resumption IDs must be limited to the top-level url bar domain.
+HTTP Keep-Alive connections from a third party in one top-level domain must
+not be reused for that same third party in another top-level domain.
+
+ </para>
+ <para><command>Implementation Status:</command>
+
+We <ulink url="https://trac.torproject.org/projects/tor/ticket/4099">plan to
+disable</ulink> TLS session resumption, and limit HTTP Keep-alive duration.
+
+ </para>
+ </listitem>
<listitem>window.name
<para>
@@ -857,23 +914,84 @@ functionality.
<sect2 id="fingerprinting-linkability">
<title>Cross-Domain Fingerprinting Unlinkability</title>
<para>
+
+In order to properly address the network adversary on a technical level, we
+need a metric to measure linkability of the various browser properties that
+extend beyond any stored origin-related state. <ulink
+url="https://panopticlick.eff.org/about.php">The Panopticlick Project</ulink>
+by the EFF provides us with exactly this metric. The researchers conducted a
+survey of volunteers who were asked to visit an experiment page that harvested
+many of the above compo- nents. They then computed the Shannon Entropy of the
+resulting distribution of each of several key attributes to determine how many
+bits of identifying information each attribute provided.
+
+ </para>
+ <para>
+
+The study is not exhaustive, though. In particular, the test does not take in
+all aspects of resolution information. It did not calculate the size of
+widgets, window decoration, or toolbar size. We believe this may add high
+amounts of entropy to the screen field. It also did not measure clock offset
+and other time-based fingerprints. Furthermore, as new browser features are
+added, this experiment should be repeated to include them.
+
+ </para>
+ <para>
+
+On the other hand, to avoid an infinite sinkhole, we reduce the efforts for
+fingerprinting resistence by only concerning ourselves with reducing the
+fingerprintable differences <emphasis>among</emphasis> Tor Browser users. We
+do not believe it is productive to concern ourselves with cross-browser
+fingerprinting issues, at least not at this stage.
+
</para>
- <!-- XXX: Panopticlick set + others -->
<orderedlist>
- <listitem>Desktop resolution
- <para>
+ <listitem>Plugins
+ <para><command>Design Goal:</command>
+ </para>
+ <para><command>Implementation Status:</command>
+ </para>
+ </listitem>
+ <listitem>Fonts
+ <para><command>Design Goal:</command>
+ </para>
+ <para><command>Implementation Status:</command>
+ </para>
+ </listitem>
+ <listitem>User Agent and HTTP Headers
+ <para><command>Design Goal:</command>
+ </para>
+ <para><command>Implementation Status:</command>
+ </para>
+ </listitem>
+ <listitem>Desktop resolution and CSS Media Queries
+ <para><command>Design Goal:</command>
+ </para>
+ <para><command>Implementation Status:</command>
</para>
</listitem>
<listitem>Timezone and clock offset
- <para>
+ <para><command>Design Goal:</command>
+ </para>
+ <para><command>Implementation Status:</command>
</para>
</listitem>
- <listitem>WebGL
- <para>
+ <listitem>Javascript performance fingerprinting
+ <para><command>Design Goal:</command>
+ </para>
+ <para><command>Implementation Status:</command>
</para>
</listitem>
- <listitem>Fonts
- <para>
+ <listitem>Keystroke fingerprinting
+ <para><command>Design Goal:</command>
+ </para>
+ <para><command>Implementation Status:</command>
+ </para>
+ </listitem>
+ <listitem>WebGL
+ <para><command>Design Goal:</command>
+ </para>
+ <para><command>Implementation Status:</command>
</para>
</listitem>
</orderedlist>
@@ -901,7 +1019,10 @@ a new circuit to be created.
</para>
<para>
XXX: Cookie protections..
-XXX: Missing pieces: DOM Storage?
+<!-- XXX: Missing pieces:
+ 1. DOM Storage? IIRC, it is cleared, but also disabled anyway.
+ 2. Do we kill keep-alive connections properly?
+ -->
</para>
</sect2>
<sect2 id="click-to-play">
@@ -1082,7 +1203,7 @@ other site prefs?).
</sect2>
</sect1>
-<sect1 id="TestPlan">
+<sect1 id="Testing">
<title>Testing</title>
<para>
1
0

28 Apr '14
commit 3d2fcc35500e7663263c3eec4716e13abb144b57
Author: Mike Perry <mikeperry-git(a)fscked.org>
Date: Fri Sep 30 13:12:28 2011 -0700
Fix a typo and some links.
---
docs/design/design.xml | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/docs/design/design.xml b/docs/design/design.xml
index 2c87e74..089cd26 100644
--- a/docs/design/design.xml
+++ b/docs/design/design.xml
@@ -551,7 +551,7 @@ prevented from tracking users between sites by the implementation.
Filter-based addons can also introduce strange breakage and cause usability
nightmares, and will also fail to do their job if an adversary simply
registers a new domain or creates a new url path. Worse still, the unique
-filter sets that each user is liable to create/install likely provide a wealth
+filter sets that each user creates or installs will provide a wealth
of fingerprinting targets.
</para>
@@ -637,7 +637,7 @@ supported mime types for all currently installed plugins.
<para>
In addition, to prevent any unproxied activity by plugins at load time, we
also patch the Firefox source code to <ulink
-linkend="https://gitweb.torproject.org/torbrowser.git/blob/refs/heads/maint-2.2:/src…">prevent the load of any plugins except
+url="https://gitweb.torproject.org/torbrowser.git/blob/refs/heads/maint-2.2:/src…">prevent the load of any plugins except
for Flash and Gnash</ulink>.
</para>
@@ -648,7 +648,7 @@ External apps, if launched automatically, can be induced to load files that
perform network activity. In order to prevent this, Torbutton installs a
component to
<ulink
-linkend="https://gitweb.torproject.org/torbutton.git/blob_plain/HEAD:/src/components…">
+url="https://gitweb.torproject.org/torbutton.git/blob_plain/HEAD:/src/components…">
provide the user with a popup</ulink> whenever the browser attempts to
launch a helper app.
</para>
@@ -794,7 +794,7 @@ site.
All cookies should be double-keyed to the top-level domain. There exists a
<ulink
-linkend="https://bugzilla.mozilla.org/show_bug.cgi?id=565965">Mozilla
+url="https://bugzilla.mozilla.org/show_bug.cgi?id=565965">Mozilla
bug</ulink> that contains a prototype patch, but it lacks UI, and does not
apply to modern Firefoxes.
1
0

[tor-browser-spec/master] Address comments from Georg Koppen of JonDos.
by mikeperry@torproject.org 28 Apr '14
by mikeperry@torproject.org 28 Apr '14
28 Apr '14
commit d8457b1822deba73b3f0c5e16666e664623b640b
Author: Mike Perry <mikeperry-git(a)fscked.org>
Date: Tue Oct 4 20:04:43 2011 -0700
Address comments from Georg Koppen of JonDos.
---
docs/design/design.xml | 232 +++++++++++++++++++++++++++++-------------------
1 file changed, 142 insertions(+), 90 deletions(-)
diff --git a/docs/design/design.xml b/docs/design/design.xml
index 52e0999..9edea7e 100644
--- a/docs/design/design.xml
+++ b/docs/design/design.xml
@@ -14,16 +14,16 @@
<author>
<firstname>Erinn</firstname><surname>Clark</surname>
<affiliation>
- <address><email>erinn_torproject\org</email></address>
+ <address><email>erinn#torproject org</email></address>
</affiliation>
</author>
<author>
<firstname>Steven</firstname><surname>Murdoch</surname>
<affiliation>
- <address><email>sjmurdoch#torproject\org</email></address>
+ <address><email>sjmurdoch#torproject org</email></address>
</affiliation>
</author>
- <pubdate>Sep 29 2011</pubdate>
+ <pubdate>Oct 4 2011</pubdate>
</articleinfo>
<!--
@@ -40,14 +40,15 @@ This document describes the <link linkend="adversary">adversary model</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.32-4.
+current as of Tor Browser 2.2.33-3.
</para>
<para>
This document is also meant to serve as a set of design requirements and to
describe a reference implementation of a Private Browsing Mode that defends
-against both local and network adversaries.
+against active network adversaries, in addition to the passive forensic local
+adversary currently addressed by the major browsers.
</para>
<sect2 id="adversary">
@@ -340,12 +341,13 @@ adversary.
- No filters
-->
+
<sect1 id="DesignRequirements">
<title>Design Requirements and Philosophy</title>
<para>
The Tor Browser Design Requirements are meant to describe the properties of a
-Private Browsing Mode that defends against both network and local adversaries.
+Private Browsing Mode that defends against both network and forensic adversaries.
</para>
<para>
@@ -353,17 +355,27 @@ Private Browsing Mode that defends against both network and local adversaries.
There are two main categories of requirements: <link
linkend="security">Security Requirements</link>, and <link
linkend="privacy">Privacy Requirements</link>. Security Requirements are the
-minimum properties in order for a web client platform to be able to support
-Tor. Privacy requirements are the set of properties that cause us to prefer
-one platform over another.
+minimum properties in order for a browser to be able to support Tor and
+similar privacy proxies safely. Privacy requirements are the set of properties
+that cause us to prefer one browser platform over another.
+
+ </para>
+ <para>
+
+While we will endorse the use of browsers that meet the security requirements,
+it is primarily the privacy requirements that cause us to maintain our own
+browser distribution.
</para>
<para>
-We will maintain an alternate distribution of the web client in order to
-maintain and/or restore privacy properties to our users.
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
+ NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
+ "OPTIONAL" in this document are to be interpreted as described in
+ <ulink url="https://www.ietf.org/rfc/rfc2119.txt">RFC 2119</ulink>.
</para>
+
<sect2 id="security">
<title>Security Requirements</title>
<para>
@@ -388,17 +400,25 @@ from other browsers or other browsing modes, including shared state from
plugins, machine identifiers, and TLS session state.
</para></listitem>
- <listitem><command>Disk Avoidance</command><para>The
-browser SHOULD NOT write any browsing history information to disk, or store it
-in memory beyond the duration of one Tor session, unless the user has
-explicitly opted to store their browsing history information to
-disk.</para></listitem>
+ <listitem><command>Disk Avoidance</command><para>
- <listitem><command>Application Data Isolation</command><para>The browser
-MUST NOT write or cause the operating system to
-write <emphasis>any information</emphasis> to disk outside of the application
-directory. All exceptions and shortcomings due to operating system behavior
-MUST BE documented.
+The browser MUST NOT write any information that is derived from or that
+reveals browsing activity to the disk, or store it in memory beyond the
+duration of one browsing session, unless the user has explicitly opted to
+store their browsing history information to disk.
+
+</para></listitem>
+
+ <listitem><command>Application Data Isolation</command><para>
+
+The components involved in providing private browsing MUST BE self-contained,
+or MUST provide a mechanism for rapid, complete removal of all evidence of the
+use of the mode. In other words, the browser MUST NOT write or cause the
+operating system to write <emphasis>any information</emphasis> about the use
+of private browsing to disk outside of the application's control. The user
+must be able to ensure that secure removal of the software is sufficient to
+remove evidence of the use of the software. All exceptions and shortcomings
+due to operating system behavior MUST BE wiped by an uninstaller.
</para></listitem>
<listitem><command>Update Safety</command><para>The browser SHOULD NOT perform unsafe updates or upgrades.</para></listitem>
@@ -417,12 +437,23 @@ to prefer one platform over another.
</para>
+ <para>
+
+For the purposes of the unlinkability requirements of this section as well as
+the descriptions in the <link linkend="Implementation">implementation
+section</link>, a <command>url bar origin</command> means at least the
+second-level DNS name. For example, for mail.google.com, the origin would be
+google.com. Implementations MAY, at their option, restrict the url bar origin
+to be the entire fully qualified domain name
+
+ </para>
+
<orderedlist>
<listitem><command>Cross-Domain Identifier Unlinkability</command>
<para>
-User activity on one url bar domain MUST NOT be linkable to their activity in
-any other domain by any third party. This property specifically applies to
+User activity on one url bar origin MUST NOT be linkable to their activity in
+any other url bar origin by any third party. This property specifically applies to
linkability from stored browser identifiers, authentication tokens, and shared
state. This functionality SHOULD NOT interfere with federated login in a
substantial way.
@@ -432,8 +463,8 @@ substantial way.
<listitem><command>Cross-Domain Fingerprinting Unlinkability</command>
<para>
-User activity on one url bar domain MUST NOT be linkable to their activity in
-any other domain by any third party. This property specifically applies to
+User activity on one url bar origin MUST NOT be linkable to their activity in
+any other url bar origin by any third party. This property specifically applies to
linkability from fingerprinting browser behavior.
</para>
@@ -441,9 +472,10 @@ linkability from fingerprinting browser behavior.
<listitem><command>Long-Term Unlinkability</command>
<para>
-The browser SHOULD provide an obvious, easy way to remove all of their authentication
-tokens and browser state and obtain a fresh identity. Additionally, this
-should happen by default automatically upon browser restart.
+The browser SHOULD provide an obvious, easy way to remove all of their
+authentication tokens and browser state and obtain a fresh identity.
+Additionally, the browser SHOULD clear linkable state by default automatically
+upon browser restart, except at user option.
</para>
</listitem>
@@ -528,10 +560,10 @@ system-wide addons or plugins.
Instead of global browser privacy options, privacy decisions should be made
<ulink
url="https://wiki.mozilla.org/Privacy/Features/Site-based_data_management_UI">per
-top-level url-bar domain</ulink> to eliminate the possibility of linkability
+url bar origin</ulink> to eliminate the possibility of linkability
between domains. For example, when a plugin object (or a Javascript access of
window.plugins) is present in a page, the user should be given the choice of
-allowing that plugin object for that top-level url-bar domain only. The same
+allowing that plugin object for that url bar origin only. The same
goes for exemptions to third party cookie policy, geo-location, and any other
privacy permissions.
</para>
@@ -732,15 +764,14 @@ safely remove the bundle without leaving other traces of Tor usage on their
computer.
</para>
- <para>XXX: sjmurdoch, Erinn: explain what magic we do to satisfy this,
+ <para>FIXME: sjmurdoch, Erinn: explain what magic we do to satisfy this,
and/or what additional work or auditing needs to be done.
</para>
</sect2>
-<!-- XXX: Write me...
+<!-- FIXME: Write me...
<sect2 id="update-safety">
<title>Update Safety</title>
- <para>
-XXX: Write me..
+ <para>FIXME: Write me..
</para>
</sect2>
-->
@@ -765,13 +796,12 @@ consent.
The benefit of this approach comes not only in the form of reduced
linkability, but also in terms of simplified privacy UI. If all stored browser
-state and permissions become associated with the top-level url-bar domain, the
-six or seven different pieces of privacy UI governing these identifiers and
+state and permissions become associated with the url bar origin, the six or
+seven different pieces of privacy UI governing these identifiers and
permissions can become just one piece of UI. For instance, a window that lists
-the top-level url bar domains for which browser state exists with the ability
-to clear and/or block them, possibly with a context-menu option to drill down
-into specific types of state. An exmaple of this simplifcation can be seen in
-Figure 1.
+the url bar origin for which browser state exists, possibly with a
+context-menu option to drill down into specific types of state or permissions.
+An example of this simplifcation can be seen in Figure 1.
</para>
<figure><title>Improving the Privacy UI</title>
@@ -783,7 +813,7 @@ Figure 1.
<caption> <para/>
On the left is the standard Firefox cookie manager. On the right is a mock-up
-of how isolating identifiers to the URL bar domain might simplify the privacy
+of how isolating identifiers to the URL bar origin might simplify the privacy
UI for all data - not just cookies. Both windows represent the set of
Cookies accomulated after visiting just five sites, but the window on the
right has the option of also representing history, DOM Storage, HTTP Auth,
@@ -796,11 +826,11 @@ site.
<listitem>Cookies
<para><command>Design Goal:</command>
-All cookies should be double-keyed to the top-level domain. There exists a
-<ulink
-url="https://bugzilla.mozilla.org/show_bug.cgi?id=565965">Mozilla
-bug</ulink> that contains a prototype patch, but it lacks UI, and does not
-apply to modern Firefoxes.
+All cookies should be double-keyed to the url bar origin and third-party
+origin. There exists a <ulink
+url="https://bugzilla.mozilla.org/show_bug.cgi?id=565965">Mozilla bug</ulink>
+that contains a prototype patch, but it lacks UI, and does not apply to modern
+Firefoxes.
</para>
<para><command>Implementation Status:</command>
@@ -815,42 +845,50 @@ unlinkability trumps that desire.
</listitem>
<listitem>Cache
<para>
-Cache is isolated to the top-level url bar domain by using a technique
-pioneered by Colin Jackson et al, via their work on <ulink
+
+Cache is isolated to the url bar origin by using a technique pioneered by
+Colin Jackson et al, via their work on <ulink
url="http://www.safecache.com/">SafeCache</ulink>. The technique re-uses the
<ulink
url="https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsICachingChannel">nsICachingChannel.cacheKey</ulink>
-attribute that Firefox uses internally to prevent improper caching of HTTP POST data.
+attribute that Firefox uses internally to prevent improper caching and reuse
+of HTTP POST data.
+
</para>
<para>
+
However, to <ulink
url="https://trac.torproject.org/projects/tor/ticket/3666">increase the
security of the isolation</ulink> and to <ulink
-url="https://trac.torproject.org/projects/tor/ticket/3754">solve strange and
-unknown conflicts with OCSP</ulink>, we had to <ulink
+url="https://trac.torproject.org/projects/tor/ticket/3754">solve conflicts
+with OCSP relying the cacheKey property for reuse of POST requests</ulink>, we
+had to <ulink
url="https://gitweb.torproject.org/torbrowser.git/blob/refs/heads/maint-2.2:/src…">patch
-Firefox to provide a cacheDomain cache attribute</ulink>. We use the full
-url bar domain as input to this field.
+Firefox to provide a cacheDomain cache attribute</ulink>. We use the fully
+qualified url bar domain as input to this field.
+
</para>
<para>
<!-- FIXME: This could use a few more specifics.. Maybe. The Chrome folks
-won't care, but the Mozilla folks might. -->
-Furthermore, we chose a different isolation scheme than the Stanford
-implementation. First, we decoupled the cache isolation from the third party
-cookie attribute. Second, we use several mechanisms to attempt to determine
-the actual location attribute of the top-level window (the url bar domain)
-used to load the page, as opposed to relying solely on the referer property.
+won't care, but the Mozilla folks might. --> Furthermore, we chose a different
+isolation scheme than the Stanford implementation. First, we decoupled the
+cache isolation from the third party cookie attribute. Second, we use several
+mechanisms to attempt to determine the actual location attribute of the
+top-level window (to obtain the url bar FQDN) used to load the page, as
+opposed to relying solely on the referer property.
+
</para>
<para>
+
Therefore, <ulink
url="http://crypto.stanford.edu/sameorigin/safecachetest.html">the original
-Stanford test
-cases</ulink> are expected to fail. Functionality can still be verified by
-navigating to <ulink url="about:cache">about:cache</ulink> and viewing the key
-used for each cache entry. Each third party element should have an additional
-"domain=string" property prepended, which will list the top-level urlbar
-domain that was used to source the third party element.
+Stanford test cases</ulink> are expected to fail. Functionality can still be
+verified by navigating to <ulink url="about:cache">about:cache</ulink> and
+viewing the key used for each cache entry. Each third party element should
+have an additional "domain=string" property prepended, which will list the
+FQDN that was used to source the third party element.
+
</para>
</listitem>
<listitem>HTTP Auth
@@ -871,14 +909,14 @@ observer to modify it.
<listitem>DOM Storage
<para><command>Design Goal:</command>
-DOM storage for third party domains MUST BE isolated to the url bar domain,
+DOM storage for third party domains MUST BE isolated to the url bar origin,
to prevent linkability between sites.
</para>
<para><command>Implementation Status:</command>
Because it is isolated to third party domain as opposed to top level url bar
-domain, we entirely disable DOM storage as a stopgap to ensure unlinkability.
+origin, we entirely disable DOM storage as a stopgap to ensure unlinkability.
</para>
</listitem>
@@ -890,9 +928,9 @@ arrive on the same TCP connection.
</para>
<para><command>Design Goal:</command>
-TLS session resumption IDs must be limited to the top-level url bar domain.
-HTTP Keep-Alive connections from a third party in one top-level domain must
-not be reused for that same third party in another top-level domain.
+TLS session resumption IDs must be limited to the url bar origin.
+HTTP Keep-Alive connections from a third party in one url bar origin must
+not be reused for that same third party in another url bar origin.
</para>
<para><command>Implementation Status:</command>
@@ -902,7 +940,28 @@ disable</ulink> TLS session resumption, and limit HTTP Keep-alive duration.
</para>
</listitem>
- <listitem>window.name
+
+ <listitem>User Confirmation for cross-domain redirects
+ <para>
+
+ <!--
+
+XXX: Cross-domain redirects should prompt.
+https://trac.torproject.org/projects/tor/ticket/3600
+
+XXX:
+
+Not concerned with explicit user interaction because it is assumed that
+private browsing sessions will be relatively short-lived with frequent use of
+the "New Identity" button.
+
+-->
+ </para>
+ <para><command>Design Goal:</command>
+ </para>
+ <para><command>Implementation Status:</command>
+ </para>
+ <listitem>window.name
<para>
<ulink
@@ -949,7 +1008,7 @@ functionality.
In order to properly address the fingerprinting adversary on a technical
level, we need a metric to measure linkability of the various browser
-properties that extend beyond any stored origin-related state. <ulink
+properties beyond any stored origin-related state. <ulink
url="https://panopticlick.eff.org/about.php">The Panopticlick Project</ulink>
by the EFF provides us with exactly this metric. The researchers conducted a
survey of volunteers who were asked to visit an experiment page that harvested
@@ -1274,21 +1333,15 @@ The pref does successfully clear the permissions manager memory if toggled. It
does not need to be set in prefs.js, and can be handled by Torbutton.
</para>
- <para><command>Design Goal:</command>
-
-As an additional design goal, we would like to later alter this patch to allow this
-information to be cleared from memory. The implementation does not currently
-allow this.
-
- </para>
</listitem>
<listitem>Make Intermediate Cert Store memory-only
<para>
-The intermediate certificate store holds information about SSL certificates
-that may only be used by a limited number of domains. In some cases
-effectively recording on disk the fact that a website owned by a certain
-organization was viewed.
+The intermediate certificate store records the intermediate SSL certificates
+the browser has seen to date. Because these intermediate certificates are used
+by a limited number of domains (and in some cases, only a single domain),
+the intermediate certificate store can serve as a low-resolution record of
+browsing history.
</para>
<!-- FIXME: Should this be a <note> tag too? -->
@@ -1320,8 +1373,8 @@ security of cache isolation</ulink> and to <ulink
url="https://trac.torproject.org/projects/tor/ticket/3754">solve strange and
unknown conflicts with OCSP</ulink>, we had to <ulink
url="https://gitweb.torproject.org/torbrowser.git/blob/refs/heads/maint-2.2:/src…">patch
-Firefox to provide a cacheDomain cache attribute</ulink>. We use the full
-url bar domain as input to this field.
+Firefox to provide a cacheDomain cache attribute</ulink>. We use the url bar
+FQDN as input to this field.
</para>
</listitem>
@@ -1392,7 +1445,7 @@ other site prefs?).
</sect3>
<sect3>
<title>Excluded Addons</title>
- <!-- XXX: Adblock, RequestPolicy, ShareMeNot, priv3 -->
+ <!-- FIXME: Adblock, RequestPolicy, ShareMeNot, priv3 -->
</sect3>
<sect3>
<title>Dangerous Addons</title>
@@ -1434,7 +1487,6 @@ individually. They are provided here for reference and future regression
testing, and also in the hope that some brave soul will one day decide to
combine them into a comprehensive automated test suite.
- <!-- XXX: ip-check.info? -->
<orderedlist>
<listitem><ulink url="http://decloak.net/">Decloak.net</ulink>
<para>
@@ -1456,11 +1508,11 @@ and <ulink url="http://www.januspa.com/">JanusPA</ulink>.
</para>
</listitem>
- <listitem><ulink url="https://www.jondos.de/en/anontest">JonDos
+ <listitem><ulink url="https://ip-check.info">JonDos
AnonTest</ulink>
<para>
-The <ulink url="https://www.jondos.de">JonDos people</ulink> also provide an
+The <ulink url="https://anonymous-proxy-servers.net/">JonDos people</ulink> also provide an
anonymity tester. It is more focused on HTTP headers than plugin bypass, and
points out a couple of headers Torbutton could do a better job with
obfuscating.
@@ -1482,7 +1534,7 @@ Analyzer</ulink>
<para>
The Privacy Analyzer provides a dump of all sorts of browser attributes and
-settings that it detects, including some information on your origin IP
+settings that it detects, including some information on your original IP
address. Its page layout and lack of good vs bad test result feedback makes it
not as useful as a user-facing testing tool, but it does provide some
interesting checks in a single page.
1
0

[tor-browser-spec/master] Address redirect comments from pde and Sid Stamm
by mikeperry@torproject.org 28 Apr '14
by mikeperry@torproject.org 28 Apr '14
28 Apr '14
commit d9c1cf8e4ed8787c337dd3d952590a3586cf0c9d
Author: Mike Perry <mikeperry-git(a)fscked.org>
Date: Tue Oct 4 20:59:30 2011 -0700
Address redirect comments from pde and Sid Stamm
Also clean up some more things Georg brought up.
---
docs/design/design.xml | 76 ++++++++++++++++++++++++++----------------------
1 file changed, 42 insertions(+), 34 deletions(-)
diff --git a/docs/design/design.xml b/docs/design/design.xml
index 9edea7e..8930820 100644
--- a/docs/design/design.xml
+++ b/docs/design/design.xml
@@ -226,6 +226,7 @@ url="http://ha.ckers.org/weird/CSS-history.cgi">CSS-only history disclosure
attacks</ulink>.
</para>
</listitem>
+ <!-- XXX: Generalize to just identifiers -->
<listitem><command>Read and insert cookies</command>
<para>
@@ -449,7 +450,7 @@ to be the entire fully qualified domain name
</para>
<orderedlist>
- <listitem><command>Cross-Domain Identifier Unlinkability</command>
+ <listitem><command>Cross-Origin Identifier Unlinkability</command>
<para>
User activity on one url bar origin MUST NOT be linkable to their activity in
@@ -460,7 +461,7 @@ substantial way.
</para>
</listitem>
- <listitem><command>Cross-Domain Fingerprinting Unlinkability</command>
+ <listitem><command>Cross-Origin Fingerprinting Unlinkability</command>
<para>
User activity on one url bar origin MUST NOT be linkable to their activity in
@@ -551,13 +552,13 @@ to reduce linkability.
failure of Torbutton</ulink> was (and still is) the options panel. Each option
that detectably alters browser behavior can be used as a fingerprinting tool.
Similarly, all extensions <ulink
-url="http://blog.chromium.org/2010/06/extensions-in-incognito.html">should be
+url="http://blog.chromium.org/2010/06/extensions-in-incognito.html">SHOULD be
disabled in the mode</ulink> except as an opt-in basis. We should not load
system-wide addons or plugins.
</para>
<para>
-Instead of global browser privacy options, privacy decisions should be made
+Instead of global browser privacy options, privacy decisions SHOULD be made
<ulink
url="https://wiki.mozilla.org/Privacy/Features/Site-based_data_management_UI">per
url bar origin</ulink> to eliminate the possibility of linkability
@@ -704,7 +705,7 @@ Flash cookies from leaking from a pre-existing Flash directory.
<sect3>
<title>Design Goal:</title>
<blockquote>
-Tor Browser should optionally prevent all disk records of browser activity.
+Tor Browser MUST (at user option) prevent all disk records of browser activity.
The user should be able to optionally enable URL history and other history
features if they so desire. Once we <ulink
url="https://trac.torproject.org/projects/tor/ticket/3100">simplify the
@@ -776,7 +777,7 @@ and/or what additional work or auditing needs to be done.
</sect2>
-->
<sect2 id="identifier-linkability">
- <title>Cross-Domain Identifier Unlinkability</title>
+ <title>Cross-Origin Identifier Unlinkability</title>
<!-- FIXME: Mention web-send?? -->
<para>
@@ -826,7 +827,7 @@ site.
<listitem>Cookies
<para><command>Design Goal:</command>
-All cookies should be double-keyed to the url bar origin and third-party
+All cookies MUST be double-keyed to the url bar origin and third-party
origin. There exists a <ulink
url="https://bugzilla.mozilla.org/show_bug.cgi?id=565965">Mozilla bug</ulink>
that contains a prototype patch, but it lacks UI, and does not apply to modern
@@ -922,13 +923,13 @@ origin, we entirely disable DOM storage as a stopgap to ensure unlinkability.
</listitem>
<listitem>TLS session resumption and HTTP Keep-Alive
<para>
-TLS session resumption and HTTP Keep-Alive must not allow third party origins
+TLS session resumption and HTTP Keep-Alive MUST NOT allow third party origins
to track users via either TLS session IDs, or the fact that different requests
arrive on the same TCP connection.
</para>
<para><command>Design Goal:</command>
-TLS session resumption IDs must be limited to the url bar origin.
+TLS session resumption IDs MUST be limited to the url bar origin.
HTTP Keep-Alive connections from a third party in one url bar origin must
not be reused for that same third party in another url bar origin.
@@ -941,26 +942,33 @@ disable</ulink> TLS session resumption, and limit HTTP Keep-alive duration.
</para>
</listitem>
- <listitem>User Confirmation for cross-domain redirects
- <para>
-
- <!--
+ <listitem>User confirmation for cross-origin redirects
+ <para><command>Design Goal:</command>
-XXX: Cross-domain redirects should prompt.
-https://trac.torproject.org/projects/tor/ticket/3600
+To prevent attacks aimed at subverting the Cross-Origin Identifier
+Unlinkability <link linkend="privacy">privacy requirement</link>, the browser
+MUST prompt users before following redirects that would cause the user to
+automatically navigate between two different url bar origins.
-XXX:
+ </para>
+ <para><command>Implementation status:</command>
-Not concerned with explicit user interaction because it is assumed that
-private browsing sessions will be relatively short-lived with frequent use of
-the "New Identity" button.
+There are numerous ways for the user to be redirected, and the Firefox API
+suport to detect each of them is poor. We have a <ulink
+url="https://trac.torproject.org/projects/tor/ticket/3600">trac bug
+open</ulink> to implement what we can.
--->
</para>
- <para><command>Design Goal:</command>
- </para>
- <para><command>Implementation Status:</command>
+ <para>
+
+We are not concerned with linkability due to explicit user action (either by
+accepting cross-origin redirects, or by clicking normal links) because it is
+assumed that private browsing sessions will be relatively short-lived,
+especially with frequent use of the <link linkend="new-identity">New
+Identity</link> button.
+
</para>
+ </listitem>
<listitem>window.name
<para>
@@ -1003,7 +1011,7 @@ functionality.
</orderedlist>
</sect2>
<sect2 id="fingerprinting-linkability">
- <title>Cross-Domain Fingerprinting Unlinkability</title>
+ <title>Cross-Origin Fingerprinting Unlinkability</title>
<para>
In order to properly address the fingerprinting adversary on a technical
@@ -1046,7 +1054,7 @@ window.navigator.plugins, as well as their internal functionality.
</para>
<para><command>Design Goal:</command>
-All plugins that have not been specifically audited or sandboxed must be
+All plugins that have not been specifically audited or sandboxed MUST be
disabled. To reduce linkability potential, even sandboxed plugins should not
be allowed to load objects until the user has clicked through a click-to-play
barrier. Additionally, version information should be reduced or obfuscated
@@ -1095,7 +1103,7 @@ implemented any defense against CSS or Javascript fonts.
<listitem>User Agent and HTTP Headers
<para><command>Design Goal:</command>
-All Tor Browser users should provide websites with an identical user agent and
+All Tor Browser users MUST provide websites with an identical user agent and
HTTP header set for a given request type. We omit the Firefox minor revision,
and report a popular Windows platform. If the software is kept up to date,
these headers should remain identical across the population even when updated.
@@ -1149,13 +1157,13 @@ to be dealt with</ulink>.
<listitem>Timezone and clock offset
<para><command>Design Goal:</command>
-All Tor Browser users should report the same timezone to websites. Currently,
-we choose UTC for this purpose, although an equally valid argument could be
-made for EDT/EST due to the large English-speaking population density.
-Additionally, the Tor software should detect if the users clock is
-significantly divergent from the clocks of the relays that it connects to, and
-use this to reset the clock values used in Tor Browser to something reasonably
-accurate.
+All Tor Browser users MUST report the same timezone to websites. Currently, we
+choose UTC for this purpose, although an equally valid argument could be made
+for EDT/EST due to the large English-speaking population density (coupled with
+the fact that we spoof a US English user agent). Additionally, the Tor
+software should detect if the users clock is significantly divergent from the
+clocks of the relays that it connects to, and use this to reset the clock
+values used in Tor Browser to something reasonably accurate.
</para>
<para><command>Implementation Status:</command>
@@ -1259,7 +1267,7 @@ menu option in Torbutton.
<title>Design Goal:</title>
<blockquote>
-All linkable identifiers and browser state should be cleared by this feature.
+All linkable identifiers and browser state MUST be cleared by this feature.
</blockquote>
</sect3>
1
0

[tor-browser-spec/master] Attempt to clarify to browser makers why we split the requirements.
by mikeperry@torproject.org 28 Apr '14
by mikeperry@torproject.org 28 Apr '14
28 Apr '14
commit d3227737fd866d02d5fd45516b9aeb0271cb7bda
Author: Mike Perry <mikeperry-git(a)fscked.org>
Date: Fri Sep 30 15:22:59 2011 -0700
Attempt to clarify to browser makers why we split the requirements.
---
docs/design/design.xml | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/docs/design/design.xml b/docs/design/design.xml
index 089cd26..52e0999 100644
--- a/docs/design/design.xml
+++ b/docs/design/design.xml
@@ -370,7 +370,9 @@ maintain and/or restore privacy properties to our users.
The security requirements are primarily concerned with ensuring the safe use
of Tor. Violations in these properties typically result in serious risk for
-the user in terms of immediate deanonymization and/or observability.
+the user in terms of immediate deanonymization and/or observability. With
+respect to platform support, security requirements are the minimum properties
+in order for Tor to support the use of a web client platform.
</para>
@@ -408,8 +410,10 @@ MUST BE documented.
<para>
The privacy requirements are primarily concerned with reducing linkability:
-the ability for a user's activity on one site to be linked with their
-activity on another site without their knowledge or explicit consent.
+the ability for a user's activity on one site to be linked with their activity
+on another site without their knowledge or explicit consent. With respect to
+platform support, privacy requirements are the set of properties that cause us
+to prefer one platform over another.
</para>
1
0

[tor-browser-spec/master] Describe our efforts against flash cookies.
by mikeperry@torproject.org 28 Apr '14
by mikeperry@torproject.org 28 Apr '14
28 Apr '14
commit e0ba697476b6a8f8a67e72737a0e0fe23211c654
Author: Mike Perry <mikeperry-git(a)fscked.org>
Date: Tue Oct 4 23:23:18 2011 -0700
Describe our efforts against flash cookies.
---
docs/design/design.xml | 20 +++++++++++++++++++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/docs/design/design.xml b/docs/design/design.xml
index 244c9ab..2145751 100644
--- a/docs/design/design.xml
+++ b/docs/design/design.xml
@@ -912,6 +912,25 @@ origin, we entirely disable DOM storage as a stopgap to ensure unlinkability.
</para>
</listitem>
+ <listitem>Flash cookies
+ <para><command>Design Goal:</command>
+
+Users should be able to click-to-play flash objects from trusted sites. To
+make this behavior unlinkable, we wish to include a settings file for all platforms that disables flash
+cookies using the <ulink
+url="http://www.macromedia.com/support/documentation/en/flashplayer/help/setting…">Flash
+settings manager</ulink>.
+
+ </para>
+ <para><command>Implementation Status:</command>
+
+We are currently <ulink
+url="https://trac.torproject.org/projects/tor/ticket/3974">having
+difficulties</ulink> causing Flash player to use this settings
+file on Windows.
+
+ </para>
+ </listitem>
<listitem>TLS session resumption and HTTP Keep-Alive
<para>
TLS session resumption and HTTP Keep-Alive MUST NOT allow third party origins
@@ -932,7 +951,6 @@ disable</ulink> TLS session resumption, and limit HTTP Keep-alive duration.
</para>
</listitem>
-
<listitem>User confirmation for cross-origin redirects
<para><command>Design Goal:</command>
1
0