commit ea5f34a032323821f408413447a45fe7679f5976 Author: Mike Perry mikeperry-git@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%22%3Ethat 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>
tor-commits@lists.torproject.org