[tor-commits] [tor-browser-spec/master] Improve intro + design requirements sections.

mikeperry at torproject.org mikeperry at torproject.org
Mon Apr 28 15:18:48 UTC 2014

commit e10aba4118506b52c65380d5af0997dbb76f8418
Author: Mike Perry <mikeperry-git at fscked.org>
Date:   Tue Feb 19 12:50:35 2013 -0800

    Improve intro + design requirements sections.
 docs/design/design.xml |   45 ++++++++++++++++++++++++++++++++-------------
 1 file changed, 32 insertions(+), 13 deletions(-)

diff --git a/docs/design/design.xml b/docs/design/design.xml
index 07db627..b7eb0a7 100644
--- a/docs/design/design.xml
+++ b/docs/design/design.xml
@@ -23,7 +23,7 @@
      <address><email>sjmurdoch#torproject org</email></address>
-   <pubdate>Dec 30 2012</pubdate>
+   <pubdate>Feb 19 2013</pubdate>
@@ -64,7 +64,7 @@ through the <ulink
 extension</ulink>, though we are in the process of moving this
 functionality into direct Firefox patches. We also <ulink
 a number of Firefox preferences</ulink> from their defaults.
@@ -74,7 +74,12 @@ To help protect against potential Tor Exit Node eavesdroppers, we include
 <ulink url="https://www.eff.org/https-everywhere">HTTPS-Everywhere</ulink>. To
 provide users with optional defense-in-depth against Javascript and other
 potential exploit vectors, we also include <ulink
+url="http://noscript.net/">NoScript</ulink>. To protect against
+PDF-based Tor proxy bypass and to improve usability, we include the <ulink
+extension. We also modify <ulink
+extension preferences</ulink> from their defaults.
@@ -233,7 +238,8 @@ interaction or approval. This requirement specifically applies to linkability
 from stored browser identifiers, authentication tokens, and shared state. The
 requirement does not apply to linkable information the user manually submits
 to sites, or due to information submitted during manual link traversal. This
-functionality SHOULD NOT interfere with federated login in a substantial way.
+functionality SHOULD NOT interfere with interactive, click-driven federated
+login in a substantial way.
@@ -327,12 +333,12 @@ 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
+failure of Torbutton</ulink> was 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
 disabled in the mode</ulink> except as an opt-in basis. We SHOULD NOT load
-system-wide addons or plugins.
+system-wide and/or Operating System provided addons or plugins.
@@ -347,14 +353,14 @@ goes for exemptions to third party cookie policy, geo-location, and any other
 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. 
+If the user has indicated they wish to record local history storage, these
+permissions can be written to disk. Otherwise, they MUST remain memory-only. 
      <listitem><command>No filters</command>
-Filter-based addons such as <ulink
+Site-specific or filter-based addons such as <ulink
 Plus</ulink>, <ulink url="http://requestpolicy.com/">Request Policy</ulink>,
 <ulink url="http://www.ghostery.com/about">Ghostery</ulink>, <ulink
@@ -362,21 +368,23 @@ 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.
+linkend="privacy">privacy requirements</link>, and that development efforts
+should be focused on general solutions that prevent tracking by all
+third parties, rather than a list of specific URLs or hosts.
+     </para>
+     <para>
 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 creates or installs will provide a wealth of
 fingerprinting targets.
 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
+alone, as well as damage the acceptance of Tor users by sites that support
 themselves through advertising revenue.
@@ -393,6 +401,17 @@ their proper deployment or privacy realization. However, we will likely disable
 high-risk features pending analysis, audit, and mitigation.
+     <listitem><command>Long Term Goal: Linkability Transparency</command>
+      <para>
+<!-- XXX: Link to Deprecation List once it exists -->
+Our long term goal is to reduce all linkability to mechanisms that are
+detectable by experts, so they can alert the general public about places
+where it occurs. To this end, we maintain a Deprecation List of archaic
+web technologies that are currently (ab)used to facilitate federated login
+and other legitimate click-driven cross-domain activity but that can
+be replaced with more privacy friendly, auditable alternatives.
+      </para>
+     </listitem>

More information about the tor-commits mailing list