Design a new Bridge Distributor for Tor Browser
From recent discussions in developer meetings and on the mailing lists, it is planned that there should be some API/mechanism for Tor Browser to retrieve bridges from BridgeDB. , this will require a new Bridge Distributor.
Regardless of whether this mechanism is automated or interactive, if we follow BridgeDB's spec, and we allow wish for the logic controlling how Tor Browser users are handled to be separate (and thus more maintainable), then this will require a new Bridge Distributor, and we should probably start thinking about the threat model/security requirements, and behaviours, of the new Distributor. Some design questions we'll need to answer include:
-
Should all points on the Distributor's hashring be reachable at a given time (i.e., should there be some feasible way, at any given point in time, to receive any and every Bridge allocated to the Distributor)?
-
Or should the Distributor's hashring rotate per time period? Or should it have sub-hashrings which rotate in and out of commission?
-
Should it attempt to balance the distribution of clients to Bridges, so that a (few) Bridge(s) at a time aren't hit with tons of new clients?
-
Should it treat users coming from the domain front as separate from those coming from elsewhere? (Is is even possible for clients to come from elsewhere? Can clients use Tor to reach this distributor? Can Tor Browser connect directly to BridgeDB, not through the domain front? See #16650 (moved))
-
If we're going to do autoprobing, should it still give out a maximum of three Bridges per request? More? Less?