Bridges in Tor Browser Bundles should be public so that we have metrics on them
In a conversation on the firstname.lastname@example.org mailing list, Karsten successfully convinced me that all bridges included in the default bridge list in Tor Browser builds should be public bridges (i.e. the bridges should be submitting their descriptors to the BridgeAuthority and to BridgeDB, so that those descriptors go into Metrics).
The primary reason for this is to have more accurate metrics on bridge use, which would make it easier for people like me to get funders to sponsor my work. As such, I'm particularly interested in seeing this get done, and willing to take on the responsibility of checking that bundled bridges are public (and otherwise shaking down the bridge operators who aren't providing descriptors yet).
Any potential security/privacy benefits achieved by keeping a bridge private are nullified for bundled bridges, since their addresses are trivially, publicly accessible by grepping our source code. Obviously, an adversary enumerating BridgeDB bridges is significantly less probable than gaining the same information by grepping public data, so keeping the bundled bridges private doesn't provide any feasible security/privacy benefits.
Additionally, if bridge operators wish to give us metrics but are firmly against their bridges being distributed by BridgeDB, I can either:
torbrowserbridge pool in BridgeDB, which is never distributed.
This would only be a short-term doesn't-require-little-t-tor-patches hack. I don't really want to do this. However, if the bridge operators for Tor Browser bundle bridges ''really'' don't want to be distributed by BridgeDB, I am willing to do it.
Add a torrc option,
BridgeDistribution [https|email|any|none], as described on the mailing list and BridgeDB patches to disable distribution for bridges whose descriptors say
This would allow bridge operators to provide metrics without being publicly distributed by BridgeDB, and would likely only effect bridges running tor-0.2.6.x.
The default would be
BridgeDistribution any, which would allow BridgeDB to choose how your bridge is distributed.
BridgeDistribution [https|email]would allow a bridge operator to override BridgeDB's decision.
BridgeDistribution nonewould instruct BridgeDB to either toss out your bridge's descriptor rather than putting them into the databases (or adding them to the
'unallocated'pool, depending on how we wish to implement this).
Either of the above, if desired, would need separate tickets.