-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
For background: Currently with first-party isolation enabled if foo.com embeds
content from bar.com the cookies we would send to bar.com would come from the
foo.com|bar.com double-keyed bucket, whereas if we were to visit bar.com
directly the cookies used would just come from the bar.com bucket. This way
embedded bar.com content requests don't get correlated with first-party bar.com
sessions (and vice-versa).
So the idea behind the proposed 'Expand First Party Double-Keying Scheme to
Redirect Content' is that we treat redirected content the same as we currently
treat embedded content now by double-keying. If foo.com redirects to bar.com, we
treat the originating foo.com as the first-party domain and subsequent cookies
saved by/sent to bar.com would use the foo.com|bar.com bucket, as if bar.com was
embedded content in foo.co
Con 1 outlines the common scenario where websites will squat on similar or old
domains that redirect to the correct one (ie gogle.com -> google.com or
wachovia.com -> wellsfargo.com). So, suppose foo.com redirects to bar.com and
the user then logs in to their bar.com account. Due to the redirect, your
session cookie bar.com directs you to store after a successful login will be
saved in the double-keyed foo.com|bar.com bucket. This is fine so long as the
user always gets to bar.com via the redirect, but if the user learns the new url
and now navigates to bar.com directly (rather than from the foo.com redirect),
they would be pulling cookies from the bar.com bucket directly since there was
no redirect and bar.com would be the first-party. Thus, you would have two
concurrent session cookies, one in the bar.com bucket and one in the
foo.com|bar.com bucket. If the user is trying to juggle multiple identities,
then accidental use of the wrong account is one typo away.
The Double-Keyed Redirect Cookies + 'Domain Promotion' tries to fix this
multiple/hidden session problem by promoting the cookies of double-keyed
websites to first-party status in the case where the originating domain is
positively identified as solely a redirect. In the gogle.com -> google.com
scenario, if Tor Browser could identify that gogle.com is used solely to
redirect to google.com, then we could take the double-keyed gogle.com|google.com
cookies and move them into the google.com bucket and eliminate the double
session.
I hope that clears things up.
best,
- -Richard
On 1/11/19 9:05 AM, Georg Koppen wrote:
> Richard Pospesel:
>> And here's a link that actually works:
>> https://storm.torproject.org/shared/Kw99Ow0ExZFFC6FKD5CeryfVFAoAL9Z_iEVlflI0fiL
>
> Thanks for collecting and sharing all the possible ideas here. Some
> comments come to mind after thinking a bit about it.
>
> 1) We probably won't get that feature right in our first attempt (let's
> assume there is something like "right" here at all), so I would not want
> to spend too much time trying to fix all the rabbit holes we find while
> thinking about and implementing fixes. In particular, I'd suggest we try
> to ignore the scenario that identifiers, cookies etc. get somehow passed
> on in the URL bar over redirects for now. Dealing with tracking
> information in URLs is a tricky topic of its own and somewhat orthogonal
> to redirects.
>
> 2) For Tor Browser I think I am currently most interested in the "Expand
> First Party Double-Keying Scheme to Redirected Content" scenario, thus
> I'd like to look a bit closer at it. Looking over the Cons I don't see
> OAuth and similar authentication mechanisms being broken, is that
> correct? If so, great, and certainly a plus.
>
> I think I don't understand the scenario in Con 1, that is how a user can
> effectively end up with two simultaneous identities depending on whether
> they came from https://gogle.com/ or https://google.com/. For instance,
> if I enter https://gogle.com, why should I end up with a different
> identity than coming from https://google.com? https://gogle.com is not
> even settings cookies, but even if it were the final response from
> google.com is a 200 with a Set-Cookie header (among other things). That
> cookie would I sent back regardless once I decide I want to log in. The
> same happens in the scenario where I already had been logged into Google
> before I think.
>
> 3) I am not sure about Con 2 yet, but another thing we can keep in mind
> is that we have the New Identity feature against powerful
> trackers/longterm tracking. If we don't find a solution to Con 2 I think
> pointing to that defense as a stop gap is not the worst idea. At any
> rate I feel not having a solution right now to that one should not stop
> us from experimenting.
>
> Georg
>
>
> ___
> tor-dev mailing list
> tor-dev@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
-BEGIN PGP SIGNATURE-
iQIzBAEBCgAdFiEEvnyRTMkiztnZPSO33kc2A2PzSywFAlxCPj4ACgkQ3kc2A2Pz
