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

Hi,

anonym wrote (16 Jun 2015 13:11:47 GMT) :
> 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 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?

In practice, I doubt we manage to express this question in a way that
empowers most users to make a reasonable security decision.

I won't repeat the discussion and proposed mitigations that are
already on the blueprint about this topic, but I'm still very much
opposed to querying the user, and instead they should think about it
and make the decision *once*, when deciding whether they want
a persistent Tor state or not, instead of every time they come back to
some place where they have been in the past.

Cheers!
--
intrigeri