[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #5684 [Metrics Data Processor]: Should we stop sanitizing nicknames in bridge descriptors?



#5684: Should we stop sanitizing nicknames in bridge descriptors?
------------------------------------+---------------------------------------
 Reporter:  karsten                 |          Owner:     
     Type:  enhancement             |         Status:  new
 Priority:  normal                  |      Milestone:     
Component:  Metrics Data Processor  |        Version:     
 Keywords:                          |         Parent:     
   Points:                          |   Actualpoints:     
------------------------------------+---------------------------------------

Comment(by bastik):

 Replying to [comment:7 karsten]:
 > Replying to [comment:6 bastik]:
 > > Replying to [comment:5 karsten]:
 > > > How can a user decide if a dev cannot?
 > >
 > > They would know if relay and bridge name share a naming scheme.
 >
 > In order to make this decision, operators would have to understand that
 they should use a different scheme for naming their bridges than for their
 relays.  As I said on tor-dev, that's yet one more thing to tell them, and
 it's likely going to generate support requests for no good reason.

 True.

 > > > I'd guess that 95% of bridge operators would never see this option
 and the remaining 5% wouldn't know how to set it right. That would make
 the data almost unusable for counting EC2 bridges and for Atlas, and we'd
 generate support requests for no good reason.
 >
 > This is the case for newly created EC2 images.  It doesn't apply to
 existing EC2 images which are not updated.  We'd also not learn about past
 statistics, and this wouldn't help Atlas at all.  All in all, this config
 option is a usability nightmare that leaves us with mostly useless
 statistics.

 I hadn't thought about that. I agree about the usability. Sure statistics
 would be mostly useless.

 > > > No, we should decide whether we can safely include all original
 nicknames, and if not, we should keep sanitizing all of them.
 > >
 > > For my understanding you, the Tor people, can't do that. Names can be
 changed. How to define safe?
 >
 > I think this is something developers ''have'' to decide, not users.
 Note that this isn't about a single bridge that can be located via
 nickname similarity.  It's about not letting the attack become successful
 enough to make it attractive.  If the adversary could locate 1% of bridges
 via nickname similarity, they probably wouldn't care.  Also, if we can
 double the number of bridges by getting more funding for EC2 bridges and
 making it easier for operators to check how their bridge is doing via
 Atlas, that's a win.

 I agree that only the devs can make the decision. It has to be a
 "global"/general decision. I should have been more verbose. My point was
 (and I should have made that clear) that an adversary may learn about
 bridge locations via nickname similarity. That couldn't be called safe,
 but is has to be set into relation to other things an adversary can do.
 Might be safe enough. So I agree with the adversary thing.

 > > Please don't feel "forced" to reply. I really don't want to start a
 discussion here.
 >
 > Oh, discussion is good.  Please feel free to post any thoughts you have
 either here or on tor-dev.  I'm not at all trying to kill the discussion.
 I agree here as well. I picked this "channel" because it creates less
 noise.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/5684#comment:8>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs