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

[Tor Bug Tracker & Wiki]

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

 * status:  new => needs_information


Comment:

 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.

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