[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-commits] [tor-browser-spec/master] Misc cleanups.
commit ea5f34a032323821f408413447a45fe7679f5976
Author: Mike Perry <mikeperry-git@xxxxxxxxxx>
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>
_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits