intrigeri:
> anonym and I have made great progress on this front, and we would like
> feedback from you folks regarding the state of our current reasoning
> and preferred design:
>
> https://labs.riseup.net/code/issues/5462
> https://tails.boum.org/blueprint/persistent_Tor_state/
>
> In particular, the "Drawbacks of persistent Tor state" section is
> important, and because of it the proposed design will require some
> project-wide decision:
>
> https://tails.boum.org/blueprint/persistent_Tor_state/#drawbacks
Hi,
I'm getting back on this to pick up your brain regarding how this might
interact with a future persistent Tor configuration (#5461). This should
probably be rather addressed while working on persistent Tor
configuration, but I want to make sure that we are not blocking any
possible solution for this while working on persistent Tor state or
favor solutions that would make persistent Tor configuration easier. For
the time being I don't think there's nothing to fix in your RFC
regarding that.
The thing is that people might need different Tor configuration
depending on the place they connect from. You can do this manually
already by setting up different bridges at different places. This might
be needed to get connected to Tor (depending on where you are only
certain bridges might be an option). You might also prefer not to use
your secret private bridges when you are traveling not to provide
confirmation options for your adversaries to track you.
So in the end, it might be useful to provide persistent Tor
configuration depending on your Tor state number, or to allow enabling
your persistent Tor configuration only for some of them, etc. In the
end, it feels like having the kind of Tor state number that you are
proposing opens up for stronger and better possibilities for persistent
Tor configuration. So, if anything, working on persistent Tor state
first, and then on persistent Tor configuration seems to make sense.
My 2 cents,
