[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