[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
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
@@ -23,7 +23,7 @@
- <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
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.
-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
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.
-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.
-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.
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
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>
+<!-- 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.
More information about the tor-commits