[tor-commits] [tor-browser-spec/master] Redirects really should not be allowed to store identifiers.

[mikeperry at torproject.org]

commit e0cd4019b2bc971b4d7564d11341a3edf6ef6b7b
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
--- a/docs/design/design.xml
+++ b/docs/design/design.xml
@@ -1038,39 +1038,22 @@ from the last packet read on the connection) using the Firefox preference
 
      </para>
     </listitem>
-    <listitem>User confirmation for cross-origin redirects
+    <listitem>Automated cross-origin redirects MUST NOT store identifiers
     <para><command>Design Goal:</command>
 
 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. 
-
-</para>
-XXX: Should redirects be allowed to set cookies? The *redirecting* domain
-probably shouldn't, but the destination domain should.
-<para>
-
-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.
 
     </para>
-     <para>
+    <para>
 
-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
-Identity</link> button.
+Non-automated redirect chains that require user input at some step (such as
+federated login systems) SHOULD still allow identifiers to persist.
 
     </para>
     <para><command>Implementation status:</command>