[tor-bugs] #2372 [BridgeDB]: Export BridgeDB's pool assignments

[Tor Bug Tracker & Wiki]

#2372: Export BridgeDB's pool assignments
-------------------------+--------------------------------------------------
 Reporter:  karsten      |       Owner:     
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:     
Component:  BridgeDB     |     Version:     
 Keywords:               |      Parent:     
-------------------------+--------------------------------------------------
 Following the (actually newly introduced) tradition of summarizing IRC
 discussions in Trac or email, here's what Roger and I discussed today:

 I'm interested in learning whether keeping a certain fraction of bridges
 unassigned, that is not distributing them via email or HTTP, is a good
 idea.  AIUI, the idea was to have a small set of fresh bridges in case we
 come up with a new distribution channel or want to give out fresh bridges
 manually.  This idea might fail if people who run a bridge that ends up in
 the unallocated pool decide that their bridge is not being useful.  They
 might turn off their bridge or delete their keys in order to get a new
 fingerprint and end up in another pool.  If many people do so, we might
 better allocate all bridges to pools directly and start a new pool
 whenever there's a new distribution channel.  Given the high churn of
 bridges, we might have a sufficient set of fresh bridges in that pool very
 soon.  Also, if we want to give out bridges manually, we might give out
 bridges from the other pools which may have higher uptime than bridges in
 the unallocated pool.  Allocating all bridges also means we don't have to
 explain to bridge operators why their bridge is also useful even if it
 doesn't have any users right now.

 So, we need to export pool assignments from BridgeDB somehow.  Currently,
 we have log files of the following format:

 {{{
 Jan 10 01:41:14 [DEBUG] Leaving bridge 1.2.3.4:443
 dddddddddddddddddddddddddddddddddddddddd unallocated
 Jan 10 01:41:14 [DEBUG] Adding bridge 2.3.4.5:443
 eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee to IP ring 1 (port-443 subring)
 Jan 10 01:41:14 [DEBUG] Adding bridge 2.3.4.5:443
 eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee to IP ring 1 (stable subring)
 Jan 10 01:41:14 [DEBUG] Adding bridge 2.3.4.5:443
 eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee to IP ring 1
 }}}

 If we want to analyze bridge pool assignments we need a better data format
 than this log format.  Here's a proposed data format for bridge pool
 assignments (with sanitized IP addresses and fingerprints):

 {{{
 bridge-pool-assignment 2011-01-10 01:41:14
 b 127.0.0.1:443 abcdef0123456789abcdef0123456789abcdef01
 b 127.0.0.1:443 0123456789abcdef0123456789abcdef01234567
 s IP ring 1 (port-443 subring)
 s IP ring 1 (stable subring)
 s IP ring 1
 }}}

 The timestamp in the bridge-pool-assignment line is the time when the
 assignment is written to disk (twice an hour).  Lines starting with b
 contain IP address, port, and fingerprint of a bridge.  For sanitizing
 purposes, I replaced bridge IP addresses with 127.0.0.1 and bridge
 identities with their SHA-1 hashes.  That's the same approach that we take
 for sanitizing bridge descriptors.  Lines starting with s contain the
 rings or subrings that a bridge is allocated to.

 Possible questions that I'm trying to answer with these data are:

  1. Do bridges ever switch pools?

  2. Is bridge uptime affected by the pool assignment?

 Are there reasons not to publish the sanitized versions of these bridge
 pool assignments?  Are any sensitive data left that we need to remove?

 Can we change the BridgeDB code to export its pool assignment in this
 format (without the sanitizing which I would do on a metrics machine)?

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