[tor-bugs] #13504 [Tor Browser]: Bridges in Tor Browser Bundles should be public so that we have metrics on them

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#13504: Bridges in Tor Browser Bundles should be public so that we have metrics on
them
--------------------------------------------------+----------------------
 Reporter:  isis                                  |          Owner:  isis
     Type:  defect                                |         Status:  new
 Priority:  normal                                |      Milestone:
Component:  Tor Browser                           |        Version:
 Keywords:  tbb-bridges, tbb-pref, bridgedb-dist  |  Actual Points:
Parent ID:                                        |         Points:
--------------------------------------------------+----------------------
 In [https://lists.torproject.org/pipermail/tor-
 dev/2014-October/007617.html a conversation] on the tor-
 dev@xxxxxxxxxxxxxxxxxxxx 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:

   1. Create a `torbrowser` bridge 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.

   2. Add a torrc option, `BridgeDistribution [https|email|any|none]`,
 [https://lists.torproject.org/pipermail/tor-dev/2014-October/007614.html
 as described on the mailing list] and BridgeDB patches to disable
 distribution for bridges whose descriptors say `BridgeDistribution none`.

      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.

      Using `BridgeDistribution [https|email]` would allow a bridge
 operator to override BridgeDB's decision.

      Using `BridgeDistribution none` would 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.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/13504>
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