[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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



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

 (I'll post more later, but for now...)

 After reading rBridge, Proximax, Kaleidoscope, Tor's blocking resistance
 paper:

 some thoughts on a future system:

 - 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
 - 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
 - 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)?
 - 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?
 - Low plausible deniability that you don't have credentials if you use Tor

 Isis has several really good ideas too (Persona was one of them, now that
 I think about it).

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