[tor-dev] #3600 tech doc

[Georg Koppen]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20190111/a5dab7c1/attachment.sig>