doc/TODO.external

   1 $Id$
   2 Legend:
   3 SPEC!!  - Not specified
   4 SPEC    - Spec not finalized
   5 N       - nick claims
   6 R       - arma claims
   7 P       - phobos claims
   8 S       - Steven claims
   9 E       - Matt claims
  10 M       - Mike claims
  11 J       - Jeff claims
  12 I       - ioerror claims
  13 W       - weasel claims
  14 K       - Karsten claims
  15 C       - coderman claims
  16         - Not done
  17         * Top priority
  18         . Partially done
  19         o Done
  20         d Deferrable
  21         D Deferred
  22         X Abandoned
  23
  24 =======================================================================
  25
  26 External constraints:
  27
  28   - mid January
  29 W   - Finish testing, debugging, unit testing, etc the directory overhead
  30       changes. Have it in the development version and in use.
  31       o Roger writes a proposal unifying the or-dev discussions
  32 ?     * Somebody implements the proposal. Who?
  33 E   - Implement KDE Marble into Vidalia.  In order to improve the user
  34       interface for easier understanding of circuits and where traffic
  35       travels, replacing the current Vidalia map with KDE's Marble
  36       is desired.  KDE's Marble widget gives a better quality map and
  37       enables improved interactivity.  This is the first step in allowing
  38       users to choose an exit country, or being able to interact with
  39       Tor circuits in new ways.
  40
  41   - end of January
  42     - Write first draft of research study for Paul's research problem.
  43 R     - Get the stuff in the wiki into a "report" we can show some
  44         bureaucrat, for phase one.
  45 I   - Periodic summaries of localization progress: both pootle and wml.
  46
  47   - mid February
  48 S   * Examine current load balancing issues and evaluate trade-offs
  49       associated with other methods.
  50       - For each potential routing improvement strategy...
  51         - Explain method, calculate theoretical impact, estimate likely
  52           impact, prioritize
  53         - Establish implementation work plan
  54         - Document strategy for metrics and evaluation
  55       - Highlight which items on your list are doable in 2009.
  56
  57 N   - Write a summary of progress toward Overlapped I/O on Windows.
  58
  59 S   - Write a summary of progress toward understanding risks to relays
  60       (and thus bridges) from letting attackers route traffic through
  61       them. Eg, if relays have 100KB/s but set relaybandwidthrate to
  62       10KB/s, do your interference attacks still work?
  63
  64 W   - Download fewer descriptors
  65       - Summarize progress so far, on all the different approaches to
  66         reducing directory download overhead.
  67         - Measure/estimate impact of each improvement.
  68       - Build a plan and timeline for implementing the rest.
  69
  70 N   - TLS arms race: Produce a list of likely avenues for blocking,
  71       and for each avenue summarize a plan for how we should respond to
  72       get Tor unblocked again.
  73
  74 I   * Email auto-responder
  75       - Document the design and spec.
  76         - Describe auto-responder "commands"
  77         - Describe DKIM requirement (and alternatives)
  78         - Describe how we're going to localize the text
  79       - Describe the workflow for a user that wants to know she's got
  80         the right file. Digitally signed installer? Feed it to the
  81         updater that recognizes signatures? Other options?
  82       * How do we better support users with limited email
  83         bandwidth? Multi-part download? Teach them how to reconnect
  84         their gmail? Does downloading your gmail work when your network
  85         keeps dying?
  86
  87 K   - Metrics.
  88       * Gather and document monthly usage metrics, by country
  89         - Using Roger's old method of counting users
  90         - Using Nick's new method of counting users
  91         - Start playing around with figuring out which one is more
  92           accurate, or how to combine them to get better guesses,
  93           or something.
  94       * Automatically collect and document or publish other monthly
  95         statistics
  96         - Total data over time
  97         - Number, availability and performance of relays
  98         - Advertised capacity
  99       - With Mike's help, use Torflow to start doing monthly rudimentary
 100         performance evaluations:
 101         - Circuit throughput and latency
 102         - Measure via Broadband and dialup
 103       - Make a few graphs of the most interesting public data
 104       - Publish a report addressing key long-term metrics questions:
 105         - What metrics should we present?
 106         - What data are available for these metrics?
 107         - What data are missing, and can collect them safely? Can we
 108           publish them safely?
 109         - What systems are available to present this data?
 110
 111 E   - Vidalia improvements
 112       - Implement Vidalia presentation of plaintext port warnings
 113       - Figure out a plan for presenting other Tor status warning events.
 114       - Move Polipo into the main Vidalia -dev bundle.
 115       - Vidalia displays by-country user summary for bridge operators
 116       - Get the onion icons back into vidalia svn
 117         - Find an OS X user who can do design who thinks the OS X onion
 118           icons are crappy and need fixing
 119
 120 M   - Network scanning and network health
 121       - Implement some initial automated scans.
 122       - Describe a roadmap for how to get from here to plausible,
 123         long-term security scanning tests for Tor network
 124       - Document a strategy for incorporating results into directory
 125         consensus documents. At what phases will we be ready to automate
 126         which parts? How will we recognize when we are ready?
 127
 128 M   - Torbutton development
 129       - Keep up with our bugfixes -- build a plan for (or resolve)
 130         every item in Flyspray, and other known issues like the Google
 131         captcha issue.
 132       - Build a strategy for how Torbutton and Vidalia can
 133         communicate. E.g., what do we do with the 'new identity' button
 134         in Vidalia?
 135       * Make Torbutton happy on FF3, especially so TBB can drop FF2.
 136
 137 C   - Transparent interception of connections on Windows
 138       - Produce prototype, with screenshots for how to install and test.
 139       - Document open issues, future work, things users need to be aware
 140         of, etc.
 141
 142 S   - Tor Browser bundle work
 143       - Use native Vidalia (non-PortableFirefox) launcher for browser
 144       - Close Browser on clean Vidalia exit
 145       - Establish feasibility of simultaneous Firefox usage (also
 146         considering implications for (OpenVPN-style or other) system-wide
 147         Tor interception)
 148       - Switch Tor Browser Bundle to Firefox 3, once Torbutton is ready.
 149       - Decide whether TBB should use Torbutton's "lock" feature.
 150         http://archives.seul.org/or/cvs/Jun-2008/msg00186.html
 151 I     . Jake learns how to build the TBB and takes over doing new
 152         releases.
 153
 154 S   - Continue analyzing "traces" left on host machine by use of
 155       Tor Browser, especially once we have our new launcher and have moved
 156       to FF3. Write a summary of current progress, and what remains. Try
 157       to solve some of the low-hanging fruit.
 158
 159 I   - Periodic summaries of localization progress: both pootle and wml.
 160 I   - Collecting user stories
 161 I   - Revise the 'Tor mirror page' so it doesn't list obsolete-looking
 162       timestamps. Just have two tables, "new enough" and "not new enough".
 163 I   * Get Tor Weather up, stable, and in use by some relay operators.
 164 I   d Get a relay operator mailing list going, with a plan and supporting
 165       scripts and so on.
 166