[tor-bugs] #12029 [BridgeDB]: Redesign BridgeDB's class inheritance to make designing new distributors easier

Tor Bug Tracker & Wiki blackhole at torproject.org
Tue Jul 8 15:01:11 UTC 2014


#12029: Redesign BridgeDB's class inheritance to make designing new distributors
easier
--------------------------+-------------------------------------------
     Reporter:  isis      |      Owner:  isis
         Type:  defect    |     Status:  accepted
     Priority:  major     |  Milestone:
    Component:  BridgeDB  |    Version:
   Resolution:            |   Keywords:  bridgedb-dist, bridgedb-0.2.x
Actual Points:            |  Parent ID:
       Points:            |
--------------------------+-------------------------------------------
Changes (by isis):

 * cc: mikeperry, gk (added)
 * status:  needs_information => accepted


Comment:

 Replying to [comment:1 isis]:
 > I have a design question for BridgeDB that I've been thinking about for
 a couple weeks, and I can't decide which is the more secure/better thing
 to do.
 >
 > I want there to be a separation between the actual databases, and the
 bridge Distributors. Hopefully, it can be in a way, such that the bridge
 Distributors could be run on separate machines (as has been discussed
 plenty before in #tor-dev on IRC).
 >
 > In my head, I had this idea that there would be a DatabaseManager that
 the Distributors could talk to, either locally, or through an API where
 they send it some simply-formatted (probably JSON) requests for bridges
 from the databases.
 >
 > Currently, a Distributor is the one who "owns" and accesses its own
 hashring. This has been this way for years (it is because the
 `bridgedb.Dist.Distributor` classes actually inherits from
 `bridgedb.Bridges.BridgeHolder`, the later of which is the base class for
 all hashrings), this choice was made because the threat model specifies
 that the compromise of one hashring shouldn't effect another distributor.
 This requires the Distributor to hold its hashring in memory (it can be
 substantially large), and (unless each Distributor is going to run its own
 Redis instance) this is much slower (in terms of CPU/memory overhead).
 >
 > So the design question is this: who "owns" the hashrings with bridges in
 them? the DatabaseManager? or the Distributor?
 >
 > Here is the layout of the Pros and Cons of each design (at least those
 I've been able to think of so far):
 >
 >  1. The DatabaseManager "owns" a Distributor's hashring.
 >
 >     '''Pros'''
 >      - Enables less complication for people implementing new
 Distributors. (Implementers wouldn't need to deal with hashrings at all;
 they'd just need to have a way to authenticate to and ask the
 DatabaseManager for bridges.)
 >      - Requires substantially less CPU and memory for a new Distributor,
 whether it's on the same machine as the databases or otherwise.
 >
 >     '''Cons'''
 >      - Requires potentially significantly more network overhead.
 >      - If the Distributor is run remotely, we still can't reliably
 determine if the Distributor was compromised, and so we should still cling
 to the threat model that a compromised Distributor may obtain/hand out all
 bridges under its control.
 >
 >  2. A Distributor owns its own hashring.
 >
 >     '''Pros'''
 >      - No additional network overhead each time the Distributor wants to
 hand out bridges.
 >
 >     '''Cons'''
 >      - There is still the network overhead of receiving the bridges from
 the DatabaseManager in the first place.
 >      - Requires large CPU/memory requirements for each new Distributor.
 >      - Implementers of new Distributors will potentially have additional
 complication, due to needing to deal with hashrings and storing their own
 bridges. (Though this might be simplified by hiding the functionality in a
 "private" methods in the parent class.)
 >
 > Feel free to add Pros/Cons or argue for whichever design, or propose
 another one, because I'm not sure what to do yet.

 This was discussed in the "Bridging the Gap" breakout session at the
 Summer 2014 Tor Developer Meeting in Paris, between myself, wfn,
 mikeperry, gk, and some others.

 We decided that, in order for future client-side distributor mechanisms to
 easily integrate with Tor Browser, it is '''necessary to implement case
 !#1''' described above, such that the Distributor API  can be reused in a
 language-agnostic manner. I'm going to proceed with implementing !#1.

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


More information about the tor-bugs mailing list