-----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_iEVlflI0...
Thanks for collecting and sharing all the possible ideas here. Some comments come to mind after thinking a bit about it.
- 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.
- 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.
- 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