[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #12029 [BridgeDB]: Redesign BridgeDB's class inheritance to make designing new distributors easier
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs