anonym wrote:
> Hi!
>
> 28/05/13 20:47, winterfairy@??? wrote:
>> The following patches introduce support for persisting /var/lib/tor. The
>> primary benefit of this is the improved security/anonymity by keeping
>> ones
>> Tor entry guards. But there is bootstrap and circuit speed benefits too.
>
> [...]
>
> Second, your patches does not deal with the issues that's listed on the
> ticket [1].
>
> [1] https://tails.boum.org/todo/persistence_preset_-_tor/
Sorry, I missed that page. None of my search words matched that title :(
However, I hoped the solution would be something simple as I did. After
reading this page that appears not to be the case, so I am not going to
tackle this issue further.
> [...]
>
> Also, "better anonymity" isn't
> as clear-cut as we may wish it to be due to the physical location
> tracking issue. It all depends on the user's threat model, and we have
> to guide them so they can make an intelligent decision.
>
> What about:
>
> Tor data directory
>
> Tor performance and anonymity benefits at the cost of
> geographical tracking
>
> As always, reading the docs will give the full information, and
> hopefully the "geographical tracking" part of the description will make
> users that haven't read the docs think twice.
"geographical tracking" sounds too scary IMO, for users who will never
bother with the documentation (90%+ of users).
>
>> + options => [ 'source=tor-state' ],
>
> For consistency with how we (and torrc and Tor's man page) refer to this
> directory, and to prevent confusion with `/var/lib/tor/state`, I'd
> prefer `source=tor-data`.
Agree.
>> 0001-Fix-ownership-of-var-lib-tor-after-login-before-Tor-.patch
>
> I think I'd prefer not to bloat Tails Greeter further whenever it's
> possible and makes sense. In this case that code can be put in Tor's
> NetworkManager hook [6], before it starts Tor. I can't see any reason
> why not to, but I may have overlooked something (?).
That is probably possible to do, I didn't think about that. Makes sense.
