[tor-bugs] #7520 [BridgeDB]: Design and implement a social distributor for BridgeDB

Tor Bug Tracker & Wiki blackhole at torproject.org
Tue Jun 11 05:55:42 UTC 2013


#7520: Design and implement a social distributor for BridgeDB
-------------------------+--------------------------------------------------
 Reporter:  aagbsn       |          Owner:     
     Type:  enhancement  |         Status:  new
 Priority:  normal       |      Milestone:     
Component:  BridgeDB     |        Version:     
 Keywords:  SponsorZ     |         Parent:     
   Points:               |   Actualpoints:     
-------------------------+--------------------------------------------------

Comment(by sysrqb):

 Replying to [comment:5 aagbsn]:
 > BridgeDB already obtains the extra-info field bridge-ips for each
 bridge, which consists of approximate user-counts per country.
 >

 I wonder if this will be "good enough" until we implement a better
 solution. Initially I didn't think this was a good idea, but if the value
 that we extract from this is "From which country do we no longer see
 users", then I think this should work.

 > Alternately, we could extract yield entirely from the bridge-ips line by
 tracking users seen over time. This could be manipulated by a dishonest
 bridge operator, or an attacker who generates traffic to known bridges to
 boost their ranking and obtain more trust in this system.
 >

 I think this value is difficult to determine. Maybe (initially) user-
 feedback is "good enough" in this situation?

 Four scenarios we need to take into account:
   1) benevolent bridge with no connection to censor
 When censor blocks bridge, geoip stats accurately reflect this. user-hours
 can be calculated with sufficient accuracy.

   2) benevolent bridge with connection to censor
 When censor blocks bridge, geoip stats *may* accurately reflect this.
 Unknown if user-hours can be calculated accurately.

   3) malicious bridge with no connection to censor
 When censor blocks bridge, geoip stats are not reliable and *may not*
 reflect this. The bridge may have artificially inflated or deflated the
 stats it reported throughout its operation. User-hours calculation should
 be assumed to be inaccurate.

   4) malicious bridge with connection to (or is) censor
 When censor blocks bridge, geoip stats are not reliable and likely *do
 not* reflect this blocking. Stats probably will report artificially
 inflated usages from the censored zone, thus reducing the probability it
 is removed from the distributor. This also shrinks the number of new
 bridges a user can obtain.

 If we appropriately handle 1 and 4, this should include adequate
 countermeasures for 2 and 3.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/7520#comment:11>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list