[tor-commits] [tor-browser-spec/master] Redirects really should not be allowed to store identifiers.
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: Fri Dec 16 19:35:04 2011 -0800
Redirects really should not be allowed to store identifiers.
Not that it really matters at this point. Detecting redirects is a nightmare..
docs/design/design.xml | 35 +++++++++--------------------------
1 file changed, 9 insertions(+), 26 deletions(-)
diff --git a/docs/design/design.xml b/docs/design/design.xml
index d8b62e2..f034fb5 100644
@@ -1038,39 +1038,22 @@ from the last packet read on the connection) using the Firefox preference
- <listitem>User confirmation for cross-origin redirects
+ <listitem>Automated cross-origin redirects MUST NOT store identifiers
To prevent attacks aimed at subverting the Cross-Origin Identifier
Unlinkability <link linkend="privacy">privacy requirement</link>, the browser
-MUST prompt the user before following redirects that would cause the user to
-automatically navigate between two different url bar origins. The prompt
-SHOULD inform the user about the ability to use <link
-linkend="new-identity">New Identity</link> to clear the linked identifiers
-created by the redirect.
-XXX: Should redirects be allowed to set cookies? The *redirecting* domain
-probably shouldn't, but the destination domain should.
-To reduce the occurrence of warning fatigue, these warning messages MAY be limited
-to automated redirect cycles only. For example, the automated redirect
-sequence <command>User Click -> t.co -> bit.ly -> cnn.com</command> can be
-assumed to be benign, but the redirect sequence <command>User Click -> t.co ->
-bit.ly -> cnn.com -> 2o7.net -> scorecardresearch.net -> cnn.com</command> is
-clearly due to tracking. Non-automated redirect cycles that require
-user input at some step (such as federated login systems) need not be
-interrupted by the UI, and SHOULD still allow identifiers to persist.
+MUST NOT store any identifiers (cookies, cache, DOM storage, HTTP auth, etc)
+for cross-origin redirect intermediaries that do not prompt for user input.
+For example, if a user clicks on a bit.ly url that redirects to a
+doubleclick.net url that finally redirects to a cnn.com url, only cookies from
+cnn.com should be retained after the redirect chain completes.
-We are not concerned with linkability due to explicit user action (either by
-accepting cross-origin redirects, or by clicking normal links) because it is
-assumed that private browsing sessions will be relatively short-lived,
-especially with frequent use of the <link linkend="new-identity">New
+Non-automated redirect chains that require user input at some step (such as
+federated login systems) SHOULD still allow identifiers to persist.
More information about the tor-commits