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

["Tor Bug Tracker & Wiki" <torproject-admin@xxxxxxxxxxxxxx>]

#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 karsten):

 Replying to [comment:1 aagbsn]:
 > Some options:
 >
 > 1. Do not sanitize the nicknames
 >   - counting Tor Cloud bridges would be easy
 >   - might reveal bridges whose nicknames correlate with public relays
 >   - reveals approximate network location (AWS)
 >
 > More than half of all bridges have a unique nickname. How do we estimate
 the risk of not sanitizing nicknames?

 The typical approach in the past was to describe the suggested change on
 tor-dev, ask people if they think it's a bad idea and why, and if nobody
 objects, make the new data available one or two weeks later.  If there are
 no general concerns about the idea, I'll move the discussion to tor-dev.

 > 2. Mention Tor Cloud in the extra-info 'platform' string
 >   - counting Tor Cloud bridges would be easy
 >   - could indicate approximate network location (AWS)
 >   - Tor Cloud image would need to be updated and re-deployed
 >
 > Is this possible? How does Tor decide what to put in the platform
 string?

 Yes, this is possible by doing what Robert suggests.  And it's probably
 even the cleaner approach to encode this information in the platform
 string instead of the nickname.  Drawbacks are that we won't learn about
 previously deployed EC2 bridges, and that status websites like Atlas
 wouldn't benefit from this solution.  Maybe we should do both.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/5684#comment:3>
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