[tor-dev] Can we stop sanitizing nicknames in bridge descriptors?
Sebastian G. <bastik.tor>
bastik.tor at googlemail.com
Fri May 4 13:52:21 UTC 2012
Karsten Loesing, 04.05.2012 12:31:
> On 5/3/12 7:22 PM, Sebastian G. <bastik.tor> wrote:
>> The safest way is to ensure that bridge and relay operators are aware of
>> the fact that their naming scheme should avoid correlations, wherever
>> both are actually located. The question here is on how to ensure it?!
> This is a usability question. Telling bridge operators that they should
> use a very different nickname for their bridge than what they used for
> their relays could be useful. But it's yet one more thing to tell them.
> We should also tell them not to run their bridge on the same IP address
> where they ran a relay before. Or they shouldn't re-use their relay
> identity key for running a bridge. And we could even test these cases
> automatically. But my sense is that we'd only confuse potential bridge
> operators, either by telling them these things in a howto or by
> notifying them when they do one of these things. We'd probably overload
> poor Runa who has to answer the support questions coming out of this.
> Probably not worth it.
I agree, that it's already enough information an operator would have to
>> All I could do is look through the list manually and compare them with
>> the list of relays. I don't think I'm going to do this as I don't
>> believe that I'm going to find anything.
> Sounds like a fine approach. Want to do it (when the 2008 tarball is
> available)? It would be interesting to see a) what fraction of bridges
> you think you can derive IP addresses for and b) how accurate your
> guesses are.
Since it will be released in two weeks and the next wave is released in
two weeks after that I think there's enough time in which I can do that.
When you think it's useful I'm at least going to try. We should take
this "off list" and then can post the results on it.
I encourage anyone to try the same. It might be interesting to see
different results (What's similar). In the case that's useful.
More information about the tor-dev