[tor-commits] [tor-browser-spec/master] Misc cleanups.
mikeperry at torproject.org
mikeperry at torproject.org
Mon Apr 28 15:18:48 UTC 2014
commit 88ef6838588102f002edcb0486f6f995b2e83c85
Author: Mike Perry <mikeperry-git at fscked.org>
Date: Wed Feb 20 19:32:23 2013 -0800
Misc cleanups.
---
docs/design/design.xml | 146 +++++++++++++++++++++++++-----------------------
1 file changed, 77 insertions(+), 69 deletions(-)
diff --git a/docs/design/design.xml b/docs/design/design.xml
index 254726f..ff2580e 100644
--- a/docs/design/design.xml
+++ b/docs/design/design.xml
@@ -36,11 +36,11 @@
<para>
This document describes the <link linkend="adversary">adversary model</link>,
-<link linkend="DesignRequirements">design requirements</link>,
-<link linkend="Implementation">implementation</link>, <!-- <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. <!-- XXX: It is
-current as of Tor Browser 2.3.35-1 and Torbutton 1.4.5. -->
+procedures</link> of the Tor Browser. It is current as of Tor Browser 2.3.25-4
+and Torbutton 1.5.0.
</para>
<para>
@@ -325,7 +325,7 @@ 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 to allow a plugin to be
used, it MUST only apply to the top level url bar domain, and not to all sites,
-to reduce linkability.
+to reduce cross-origin fingerprinting linkability.
</para>
</listitem>
@@ -401,16 +401,25 @@ their proper deployment or privacy realization. However, we will likely disable
high-risk features pending analysis, audit, and mitigation.
</para>
</listitem>
- <listitem><command>Strive for Linkability Transparency</command>
+ <listitem><command>Transparency in Navigation Tracking</command>
<para>
-Our long term goal is to reduce all linkability to mechanisms that are
-detectable by experts and attentive users, so they can alert the general
-public about places where it occurs. To this end, we maintain a <link
-linkend="deprecate">Deprecation Wishlist</link> 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.
+While we believe it is possible to restrict third party tracking with only
+minimal site breakage, it is our long-term goal to further reduce cross-origin
+click navigation tracking to mechanisms that are detectable by experts and
+attentive users, so they can alert the general public if cross-origin
+click navigation tracking is happening where it should not be.
+
+ </para>
+ <para>
+
+However, the entrenched nature of certain archaic web features make it
+impossible for us to achieve this wider goal by ourselves without substantial
+site breakage. So, instead we maintain a <link linkend="deprecate">Deprecation
+Wishlist</link> of archaic web technologies that are currently being (ab)used
+to facilitate federated login and other legitimate click-driven cross-domain
+activity but that can one day be replaced with more privacy friendly,
+auditable alternatives.
</para>
</listitem>
@@ -999,11 +1008,11 @@ An example of this simplification can be seen in Figure 1.
</mediaobject>
<caption> <para/>
-This UI is a mock-up of how isolating identifiers to the URL bar origin might
-simplify the privacy UI for all data - not just cookies. Once browser
-identifiers and site permissions operate on a url bar basis, the same privacy
-window can represent browsing history, DOM Storage, HTTP Auth, search form
-history, login values, and so on within a context menu for each site.
+This example UI is a mock-up of how isolating identifiers to the URL bar
+origin can simplify the privacy UI for all data - not just cookies. Once
+browser identifiers and site permissions operate on a url bar basis, the same
+privacy window can represent browsing history, DOM Storage, HTTP Auth, search
+form history, login values, and so on within a context menu for each site.
</caption>
</figure>
@@ -1452,7 +1461,7 @@ instead of any of the named local fonts.
<listitem>Desktop resolution, CSS Media Queries, and System Colors
<para>
-Both CSS and Javascript have a lot of irrelevant information about the screen
+Both CSS and Javascript have access to a lot of information about the screen
resolution, usable desktop size, OS widget size, toolbar size, title bar size,
system theme colors, and other desktop features that are not at all relevant
to rendering and serve only to provide information for fingerprinting.
@@ -1466,7 +1475,7 @@ 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
+their content windows are one of a few fixed sizes based on the user's
desktop resolution.
</para>
@@ -1487,13 +1496,6 @@ url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-pa
a fixed set of system colors to content window CSS</ulink>.
</para>
- <para>
-
-As far as we know, this fully satisfies our design goals for desktop
-resolution information.
-
- </para>
-
</listitem>
<listitem>User Agent and HTTP Headers
<para><command>Design Goal:</command>
@@ -2291,11 +2293,11 @@ javascript into the chrome (and thus gain complete control of the browser).
-->
</sect1>
<appendix id="Transparency">
-<title>Towards Linkability Transparency</title>
+<title>Towards Transparency in Navigation Tracking</title>
<para>
The <link linkend="privacy">privacy properties</link> of Tor Browser are
-based upon the assumption that link click navigation indicates user
+based upon the assumption that link-click navigation indicates user
consent to tracking between the linking site and the destination site. This
definition of consent is primarily pragmatic: It is simply not possible to
entirely prevent the ability of a destination site to collaberate with a source
@@ -2305,23 +2307,21 @@ several other vectors, both explicit and implicit).
</para>
<para>
-However, with a few changes to web standards, it is possible to make it
-evident to experts and attentive users when such collaboration is occurring
-before they actually click on a link. In an ideal world, if a user clicks on a
-link that leads to another url bar origin, the mechanisms of tracking during
-that link click would be limited to the contents of URL parameters that are
-fully visible to the user <emphasis>before</emphasis> they click. This section
-serves to enumerate web technologies that create other link-click side
-channels that hinder user awareness of navigation tracking.
+However, in an ideal world, the mechanisms of tracking that can be employed by
+a link would be limited to the contents of URL parameters and other properties
+that are fully visible to the user before they click. This section serves to
+enumerate web technologies that create other link-click side channels that
+serve to hinder user awareness of such navigation tracking.
</para>
<para>
Because the total elimination of side channels during cross-origin navigation
-will undoubtably break federated login, we also list promising web draft
-standards that would restore this functionality while still preserving
-unlinkability.
+will undoubtably break federated login as well as destroy ad revenue, we
+also describe auditable alternatives and promising web draft standards that would
+preserve this functionality while still providing transparency when tracking is
+occurring.
</para>
@@ -2334,29 +2334,32 @@ unlinkability.
We haven't disabled or restricted the referer ourselves because of the
non-trivial number of sites that rely on the referer header to "authenticate"
image requests and deep-link navigation on their sites. Furthermore, there
-seems to be no real privacy benefit to taking this action in a vaccuum,
-because many sites have begun encoding referer URL information into GET
-parameters when they need it to cross http to https scheme transitions.
-Google+'s +1 buttons are the best example of this activity.
+seems to be no real privacy benefit to taking this action by itself in a
+vaccuum, because many sites have begun encoding referer URL information into
+GET parameters when they need it to cross http to https scheme transitions.
+Google's +1 buttons are the best example of this activity.
</para>
<para>
-Because of the availability of other explicit vectors, the main risk of the
-referer header is through inadvertant and/or covert data leakage. In fact,
-<ulink url="http://www2.research.att.com/~bala/papers/wosn09.pdf">a great deal
-of personal data</ulink> is inadvertantly leaked to third parties through the
+Because of the availability of these other explicit vectors, we believe the
+main risk of the referer header is through inadvertant and/or covert data
+leakage. In fact, <ulink
+url="http://www2.research.att.com/~bala/papers/wosn09.pdf">a great deal of
+personal data</ulink> is inadvertantly leaked to third parties through the
source URL parameters.
</para>
<para>
-We believe the Referer header should be either eliminated or made explicit. If
-a site wishes to transmit its URL to third parties or during link-click, it
-should have to specify this as a property of its HTML. With an explicit property, it
-would then be possible for the user agent to inform the user if they are about to
-click on a link that will either transmit referer information or specified a
-<ulink
+We believe the Referer header should be made explicit. If a site wishes to
+transmit its URL to third party content elements during load or during
+link-click, it should have to specify this as a property of the associated
+HTML tag. With an explicit property, it would then be possible for the user
+agent to inform the user if they are about to click on a link that will
+transmit referer information (perhaps through something as subtle as a
+different color for the destination URL). This same UI notification can also
+be used for links with the <ulink
url="https://developer.mozilla.org/en-US/docs/HTML/Element/a#Attributes">"ping"</ulink>
attribute.
@@ -2369,7 +2372,7 @@ url="https://developer.mozilla.org/En/DOM/Window.name">window.name</ulink> is
a DOM property that for some reason is allowed to retain a persistent value
for the lifespan of a browser tab. It is possible to utilize this property for
<ulink url="http://www.thomasfrank.se/sessionvars.html">identifier
-storage</ulink> during click navigation. It is sometimes used for additional
+storage</ulink> during click navigation. This is sometimes used for additional
XSRF protection and federated login.
</para>
<para>
@@ -2383,18 +2386,22 @@ cross-origin navigation, but doing so may break federated login for some sites.
<para>
In general, it should not be possible for onclick handlers to alter the
-navigation destination of 'a' tags, transform them into POST requests, or
-otherwise create situations where a user believes they are clicking on a link
-leading to one URL and end up on another. This functionality is deceptive and
-is frequently a vector for malware and phishing attacks.
+navigation destination of 'a' tags, silently transform them into POST
+requests, or otherwise create situations where a user believes they are
+clicking on a link leading to one URL that ends up on another. This
+functionality is deceptive and is frequently a vector for malware and phishing
+attacks. Unfortunately, many legitimate sites also employ such transparent
+link rewriting, and blanket disabling this functionality ourselves will simply
+cause Tor Browser to fail to navigate properly on these sites.
</para>
<para>
Automated cross-origin redirects are one form of this behavior that is
-possible for us to address ourselves. We are still working on finding the best
-way to handle <ulink
-url="https://trac.torproject.org/projects/tor/ticket/3600">that issue</ulink>.
+possible for us to <ulink
+url="https://trac.torproject.org/projects/tor/ticket/3600">address
+ourselves</ulink>, as they are comparatively rare and can be handled with site
+permissions.
</para>
</listitem>
@@ -2406,11 +2413,11 @@ url="https://trac.torproject.org/projects/tor/ticket/3600">that issue</ulink>.
<listitem><ulink url="http://web-send.org">Web-Send Introducer</ulink>
<para>
-Web-Send is a browser-based link sharing (aka Like button) and federated login
-widget that is designed to operate without relying on third-party linkability
-or abusing other cross-origin link-click side channels. It has a compelling
-list of <ulink url="http://web-send.org/features.html">privacy and security
-features</ulink>, as well.
+Web-Send is a browser-based link sharing and federated login widget that is
+designed to operate without relying on third-party tracking or abusing other
+cross-origin link-click side channels. It has a compelling list of <ulink
+url="http://web-send.org/features.html">privacy and security features</ulink>,
+especially if used as a "Like button" replacement.
</para>
</listitem>
@@ -2419,9 +2426,10 @@ features</ulink>, as well.
Mozilla's Persona is designed to provide decentralized, cryptographically
authenticated federated login in a way that does not expose the user to third
-party linkability or require browser redirects or side channels. While it does
+party tracking or require browser redirects or side channels. While it does
not directly provide the link sharing capabilities that Web-Send does, it is a
-better solution to the federated login problem.
+better solution to the privacy issues associated with federated login than
+Web-Send is.
</para>
</listitem>
More information about the tor-commits
mailing list