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

Tor Bug Tracker & Wiki blackhole at torproject.org
Tue Jun 11 11:33:19 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 asn):

 Replying to [comment:10 sysrqb]:
 > (I'll post more later, but for now...)
 >
 > After reading rBridge, Proximax, Kaleidoscope, Tor's blocking resistance
 paper:
 >
 > some thoughts on a future system:

 I also agree that cherry-picking features we like from all these schemes,
 might be a good way to design a decent future BridgeDB. Adding some notes
 on my own:

 >
 > - We will want multiple pools (possibly three, to start off: Automated
 distribution, manual distribution, reserve)
 > - Use of a credential system that awards users via allocation of credits
 seems like a good idea
 > - Awarding credits based on a bridges user-hours value seems like a good
 idea

 You mean based on bridge uptime (like the rBridge paper)? I also like this
 idea.

 > - We should try to add the "intrinsic risk" of a bridge into the
 reputation calculations
 > - Without the use of NIPK and OT, the BridgeDB operators MUST be trusted

 Yeah, the threat model of BridgeDB will have to remain the same on this
 matter.
 I'd also like BridgeDB to have all those fancy rBridge cryptowan^Wfeatures
 (ZKP/OT/etc.), but I really doubt we can implement them
 efficiently/securely/in the next 5 years. I don't know a single widely
 used application with oblivious transfer capabilities.

 BTW, as far as the BridgeDB threat model goes, note that all these
 reputation-based systems probably require BridgeDB to keep accounting logs
 for users ("user X got bridges at TIMESTAMP", "user X invited user Y",
 etc.). This is not the case with the current BridgeDB.

 > - Reputation should not only be based on a social tree
 > - We can use the bridge's geoip stats to *help* determine when the
 bridge has been blocked within a zone
 > - Bridges can be selected based on the user's identity rather than
 location. (Really, how bad is random selection?)
 > - Do we want to maintain an ID system (ex. Persona)?

 By ID system, you mean some kind of identifier per user other than an IP
 address? I guess we will need such a system, if we want to build the whole
 invitation/credential-based idea.

 Will the bridge selection happen based on the ID of the user, or the IP
 address of the user? For example, Persona is based on a single email
 address; will a user who creates multiple Persona IDs be able to get more
 than a single bunch of bridges?

 > - We need reachability testing...yesterday
 > - When we determine (within a reasonably high probability) that a user
 is a censor and/or in cohorts with one, only supply blocked bridges
 > - GEO IP tracking by a bridge needs to distinguish between direct
 connections and connections via PT
 > - Can we use standalone PT nodes within a censored zone to obscure a
 connection between a PT client and bridge?
 > - How do we prevent sybils when we have registered users?
 > - If we don't track the social graph, can we somehow factor it into our
 calculations? (assuming a registered users may distribute her bridges to
 friends)
 > - Is the use of FQDN as bad an idea as I think it is?

 FQDN? What do you mean?

 > - Low plausible deniability that you don't have credentials if you use
 Tor
 >

 What do you mean on this one?

 Thanks for looking into this! I like where it's going.

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


More information about the tor-bugs mailing list