[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