Persistence preset: Tor state
See the blueprint.
Team: segfault, anonym (reviewer), sycamoreone
Only the part about Entry Guards is on our 2018 roadmap.
#28 Updated by intrigeri about 2 years ago
NetworkManager folks are designing something similar to solve a similar problem: https://blogs.gnome.org/lkundrak/2015/12/03/networkmanager-and-privacy-in-the-ipv6-internet/
#33 Updated by cypherpunks about 1 year ago
Wouldn't a temporary solution be to let users have a persistent Tor state if they have Persistence enabled?
What do you mean exactly with "persistent Tor state"? Which files do you have in mind?
As a temporary solution, there could be an option in "Configure persistent volume" to "save" Tor "settings". Upon reboot Tails could take note of the guards in use and save them in Peristent. At the next boot, Tor would pull the guards from Persistent and use them instead whatever it was going to use.
This is roughly what I had in mind. I don't know how viable this would be as I'm only a Tails user.
#36 Updated by cypherpunks 5 months ago
I consider Tails picking a new set of guards each time it boots to be a feature. This is not the same as saying "UseGuards 0", which picks a new first hop for each circuit - that would be crazy!
But using the same guards on different tails sessions is not actually something I want to do. If I'm at home, and then at work, and then at a cafe, I don't want to be connecting to the same guards in each place. This makes it easy for a passive adversary at the local ISP to link all of my sessions together!
There is a years old Tor Trac ticket about this problem which I just re-opened: https://trac.torproject.org/projects/tor/ticket/10969
It links to two different projects meant to mitigate this issue by having different state files for different locations. But the easiest way to avoid this linkability problem today is to simply use tails - unless this ticket is implemented! So, please reconsider. Thanks!