Re: [Tails-dev] RFC: persistent Tor state

Delete this message

Reply to this message
Autor: anonym
Data:  
Para: The Tails public development discussion list
Assunto: Re: [Tails-dev] RFC: persistent Tor state
On 06/15/2015 07:09 PM, Alan wrote:
> The 1st drawback: "If the attacker records that someone has been
> using a given Entry Guard at a given location in the past, and then
> someone uses the same Entry Guard at the same location, then there are
> chances that it's the same person who is back to that location." looks
> quite concerning to me, as I believe this kind of data can easily be
> recorded automatically and used afterwards:
>
> - what about a delay after which not to reuse an old location? Would
> that be a major problem for mitigating the "attacks against anonymity
> via stable Entry Guard(s)"?


A lot of thought and research has gone into selecting the entry guard
lifetime. We're already gonna mess up all this quite a bit with the
location-aware guards, so I'm wary of messing with it even more.

> - what about prompting the user, when they reconnect to an old location
> after having connected to other, if they want to reuse the data or
> not?


Well, such prompts are not good UX, and since this will affect all users
of persistence whenever they reconnect at an old place it will happen a
lot and they will be trained to pick one of the options without thinking.

We also toyed a bit about having an option in the greeter, which would
merge this option with MAC spoofing (since both are about geotracking),
but I'm not sure that's better. Also, we have good reasons for spoofing
the MAC by default, and good reasons for using stable guards by default,
and these are conflicting for such a "merged" option. And having two
options about something that will have a similar high-level explanation
seems confusing.

So, perhaps a pop-up is the best we can do if we want to delegate the
decision to our users?

> It's not very clear to me the implications of not reusing these
> data however.


"not reusing" => no location tracking, but no benefit from having stable
guards. Of course, how to compare these two conflicting goals will be
very hard to explain to our users. Or did you think about something else?

Thanks for your input!

Cheers!