Re: [tor-bugs] #4957 [Metrics Data Processor]: Decide how to sanitize pluggable transport lines in bridge descriptors

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

#4957: Decide how to sanitize pluggable transport lines in bridge descriptors
------------------------------------+---------------------------------------
 Reporter:  karsten                 |          Owner:  karsten
     Type:  task                    |         Status:  new    
 Priority:  normal                  |      Milestone:         
Component:  Metrics Data Processor  |        Version:         
 Keywords:                          |         Parent:         
   Points:                          |   Actualpoints:         
------------------------------------+---------------------------------------
Changes (by asn):

 * cc: aagbsn (added)
  * status:  needs_information => new


Comment:

 Transport lines will look like this:
 {{{
 transport SP <methodname> SP <address:port> [SP arglist] NL
 }}}
 and there is also an optional field for supplemental data:
 {{{
 transport-info SP <methodname> [SP arglist] NL
 }}}
 I think you can ignore `transport-info` for now since it's not implemented
 and there are no transports that need it yet.

 As far as sanitization is concerned, I'm not sure which approach is
 better. I'm also not completely sure how bridge descriptors are used; I
 assume they are used when analyzing bridge stats, and when a user wants to
 look at the descriptor of her bridge in atlas. Are there other use cases?

 Some sanitization approaches:

 a) No sanitization. Pluggable transports and their ports are dislosed to
 people who know a bridge.

 b) Sanitization. Only display whether the bridge supports pluggable
 transports or not. Or maybe the number of transports it supports. Or maybe
 something else.

 c) Paranoia. '''Don't''' display any pluggable transport-related
 information.

 If I were to select one I would probably go with a). It's good both for
 analysis and for users who want to know more about their bridges.

 I'm also not sold by the use case of a bridge operator who supports
 multiple transports, has a public bridge, and wants to hide some of her
 transports from her users. However, Tor users have many different use
 cases and I only know of a few, so if others think that b) or c) (or d))
 are more reasonable (or support a larger range of use cases) I'm OK with
 it.

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