[tor-commits] [tor-browser-spec/master] Misc cleanups.

[mikeperry at torproject.org]

commit ea5f34a032323821f408413447a45fe7679f5976
Author: Mike Perry <mikeperry-git at fscked.org>
Date:   Wed Feb 20 18:26:51 2013 -0800

    Misc cleanups.
---
 docs/design/design.xml |   45 +++++++++++++++++++++++----------------------
 1 file changed, 23 insertions(+), 22 deletions(-)

diff --git a/docs/design/design.xml b/docs/design/design.xml
index 223ca0c..254726f 100644
--- a/docs/design/design.xml
+++ b/docs/design/design.xml
@@ -2294,9 +2294,9 @@ javascript into the chrome (and thus gain complete control of the browser).
 <title>Towards Linkability Transparency</title>
 <para>
 
-The <link linkend="privacy">privacy properties</link> in Tor Browser are
-designed around a model that assumes that link click navigation indicates user
-consent for tracking between the linking site and the destination site. This
+The <link linkend="privacy">privacy properties</link> of Tor Browser are
+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
 site during link-click nagivation (due to GET parameters, POST parameters, and
@@ -2305,13 +2305,14 @@ several other vectors, both explicit and implicit).
 </para>
 <para>
 
-However, with a few changes to web standards, it is at least possible to make
-it evident to experts and attentive users when such collaboration is occurring
+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 vector of tracking possible
-during that link click would be limited to the contents of the URL parameters
-itself. This section serves to enumerate web technologies that create other
-link-click side channels that hinder user awareness of link-click tracking.
+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.
 
 </para>
 
@@ -2324,7 +2325,7 @@ unlinkability.
 
 </para>
 
-<sect1 id="deprecate">
+<sect2 id="deprecate">
  <title>Deprecation Wishlist</title>
  <orderedlist>
   <listitem>The Referer Header
@@ -2352,8 +2353,8 @@ source URL parameters.
 
 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 specify this as a property of its HTML. With an explicit property, it
-would be possible for the user agent to inform the user if they are about to
+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
 url="https://developer.mozilla.org/en-US/docs/HTML/Element/a#Attributes">"ping"</ulink>
@@ -2374,7 +2375,7 @@ XSRF protection and federated login.
    <para>
 
 It's our opinion that the contents of window.name should not be preserved for
-cross-origin navigation, but doing so may break federated login.
+cross-origin navigation, but doing so may break federated login for some sites.
 
    </para>
   </listitem>
@@ -2385,21 +2386,21 @@ 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.
+is frequently a vector for malware and phishing attacks.
 
    </para>
    <para>
 
-Automated cross-origin redirects are one form of behavior that it 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>.
+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>.
 
    </para>
   </listitem>
  </orderedlist>
-</sect1>
-<sect1>
+</sect2>
+<sect2>
  <title>Promising Standards</title>
  <orderedlist>
   <listitem><ulink url="http://web-send.org">Web-Send Introducer</ulink>
@@ -2413,7 +2414,7 @@ features</ulink>, as well.
 
    </para>
   </listitem>
-  <listitem><ulink url="https://developer.mozilla.org/en-US/docs/Persona">Mozilla Persona</ulink> (formerly BrowserID)
+  <listitem><ulink url="https://developer.mozilla.org/en-US/docs/Persona">Mozilla Persona</ulink>
    <para>
 
 Mozilla's Persona is designed to provide decentralized, cryptographically
@@ -2425,6 +2426,6 @@ better solution to the federated login problem.
    </para>
   </listitem>
  </orderedlist>
-</sect1>
+</sect2>
 </appendix>
 </article>