I mistyped. Here is the correct version.
day 1
1) Tails user regularly goes to physical place A that provide [free] WiFi.
2) The name of the wifi is FreeWifi832458252823523 with MAC address "A".
The user uses the regular way to set up a WiFi connection. Network
Manager etc.
3) Now, Tails would remember FreeWifi832458252823523 and assign entry
guard A.
day 2
3) Tails user goes to the same physical place A that provide [free] WiFi.
2) The name of the wifi has changed to FreeWifi358235892435 with mac
address "B". The user uses the regular way to set up a WiFi connection.
Network Manager etc.
3) Now, Tails would remember FreeWifi358235892435 and assign entry guard B.
intrigeri:
> Hi,
>
> Patrick Schleizer wrote (09 Feb 2016 23:42:22 GMT) :
>> intrigeri:
>>> [can you please decide what mailing-list this discussion should happen
>>> on, and then we can stop cross-posting over 4 mailing-list?]
>
> This still holds.
>
>>> I'm not sure I understand the problem you mean to raise, though.
>>> Can you please elaborate what problem you see if users do exactly this
>>> ("click through whatever hoops required to make the WiFi connect
>>> again", which I agree is very likely)?
>
>> day 1
>
>> 1) Tails user regularly goes to physical place A that provide [free] WiFi.
>> 2) The name of the wifi is FreeWifi832458252823523 with MAC address "A".
>> The user uses the regular way to set up a WiFi connection. Network
>> Manager etc.
>> 3) Now, Tails would remember FreeWifi832458252823523 and assign entry
>> guard A.
>
>> day 2
>
>> 3) Tails user goes to the same physical place A that provide [free] WiFi.
>> 2) The name of the wifi has changed to FreeWifi358235892435 with mac
>> address "B". The user uses the regular way to set up a WiFi connection.
>> Network Manager etc.
>> 3) Now, Tails would remember FreeWifi358235892435 and assign entry guard A.
>
> I don't understand why we would pick Entry Guard A in the last step on
> day 2, can you please explain?
I mistyped. Entry guard B.
>> This is the behavior I expect from most users. And this is what I meant
>> by 'users will click through whatever hoops required to make the WiFi
>> connect again'.
>
> Fully agreed!
>> The entry guard selection would now be influenced by by the provider of
>> the [free] WiFi. And I think such an adversary capability is something
>> as we agree that is to be avoided.
>
> Right, it's something we want to limit. anonym and I have been working
> a bit more on it, and have reverted the addition of the ESSID in the
> data we hash, found another attack, thought a bit about potential
> defenses, and discussed it a bit more. See the "First iteration"
> section on our blueprint for details:
>
> https://tails.boum.org/blueprint/persistent_Tor_state/
You quoted me! Glad that I was heard! :)
> In the current state of things we're undecided whether our current
> design is good enough to be worth shipping, or not. We'll probably ask
> someone (probably Isis) for help evaluating it and/or designing
> something better.
Or perhaps consider asking the tor-talk (-dev) mailing list in order to
get more input.
Cheers,
Patrick
