Make entry guard persistent across reboot
Tor uses entry guards  to make some deanonymization attacks harder. We currently don’t have this in Tails, because it would allow location tracking of Tails users by observing which guard nodes are used, which would be a severe regression and render the MAC randomization feature useless.
See  for thoughts on the location tracking problem and an attempt to find a compromise between protecting against location tracking and deanonymization attacks.
#2 Updated by segfault 2016-11-05 00:16:46
This is especially important for Tails Server, because Onion Service deanonymization is trivial when the attacker controls the entry guard.
Maybe we could use a separate Tor process with persistent entry guards for Tails Server? And add a warning about location tracking when using Tails Server in different locations.
#3 Updated by segfault 2016-11-05 00:23:12
Note that the current plan is to enforce client authentication in Tails Server, which protects from the deanonymazation by the entry guard. But this limits the use cases for Tails Server a lot (it requires all users to either use Tails, which would come with a Tails Server client app, or enter the authentication cookie in the torrc themselves via the command line).
#4 Updated by intrigeri 2016-11-05 09:20:49
> Maybe we could use a separate Tor process with persistent entry guards for Tails Server?
I don’t have this part of our codebase fully in mind, and I may very well be wrong, but I suspect that synchronizing the config to that new Tor service instance, and adjusting the semantics of “Tor is ready” to take it into account, will be a big burden and will make an already insanely complex setup even harder to wrap one’s mind around and debug. So I’d rather see other solutions looked into first, personally.