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 October
  29 W   - Finish implementation of directory overhead changes: have a set
  30       of patches that you think work.
  31
  32   - end of October
  33     - Auto update
  34 C     * Get the MSI working and stable for Windows Tor installer.
  35 N     o Come up with an interface to export the package/bundle gloss
  36         descriptions so Vidalia can display them.
  37         (Done; see thandy-client json2xml.  Matt was fine with this,
  38         last I heard.)
  39 E     * Vidalia calls Thandy, learns when to upgrade, requests the upgrade.
  40 ?     - Teach our OSX installer to register its version on install
  41
  42   - end of December
  43 I   - Periodic summaries of localization progress: both pootle and wml.
  44
  45   - mid January
  46 KS  . Finish testing, debugging, unit testing, etc the hidden service
  47       changes. Have it in the development version and in use.
  48 W   - Finish testing, debugging, unit testing, etc the directory overhead
  49       changes. Have it in the development version and in use.
  50 R     - Roger writes a proposal unifying the or-dev discussions
  51 ?     - Somebody implements the proposal. Who?
  52 E   - Implement KDE Marble into Vidalia.  In order to improve the user
  53       interface for easier understanding of circuits and where traffic
  54       travels, replacing the current Vidalia map with KDE's Marble
  55       is desired.  KDE's Marble widget gives a better quality map and
  56       enables improved interactivity.  This is the first step in allowing
  57       users to choose an exit country, or being able to interact with
  58       Tor circuits in new ways.
  59
  60   - end of January
  61 NSE - Write first draft of research study for Paul's research problem.
  62 I   - Periodic summaries of localization progress: both pootle and wml.
  63
  64   - mid February
  65 S   * Examine current load balancing issues and evaluate trade-offs
  66       associated with other methods.
  67       - For each potential routing improvement strategy...
  68         - Explain method, calculate theoretical impact, estimate likely
  69           impact, prioritize
  70         - Establish implementation work plan
  71         - Document strategy for metrics and evaluation
  72       - Highlight which items on your list are doable in 2009.
  73
  74 N   - Write a summary of progress toward Overlapped I/O on Windows.
  75
  76 S   - Write a summary of progress toward understanding risks to relays
  77       (and thus bridges) from letting attackers route traffic through
  78       them. Eg, if relays have 100KB/s but set relaybandwidthrate to
  79       10KB/s, do your interference attacks still work?
  80
  81 R   * Revise and publish incentive draft paper
  82       - Write an explanation for its current flaws
  83       - Gather comments, search for new designs
  84       - Write up a summary of recommendations and next steps
  85
  86 W   - Download fewer descriptors
  87       - Summarize progress so far, on all the different approaches to
  88         reducing directory download overhead.
  89         - Measure/estimate impact of each improvement.
  90       - Build a plan and timeline for implementing the rest.
  91
  92 N   - TLS arms race: Produce a list of likely avenues for blocking,
  93       and for each avenue summarize a plan for how we should respond to
  94       get Tor unblocked again.
  95
  96 I   * Email auto-responder
  97       - Document the design and spec.
  98         - Describe auto-responder "commands"
  99         - Describe DKIM requirement (and alternatives)
 100         - Describe how we're going to localize the text
 101       - Describe the workflow for a user that wants to know she's got
 102         the right file. Digitally signed installer? Feed it to the
 103         updater that recognizes signatures? Other options?
 104       * How do we better support users with limited email
 105         bandwidth? Multi-part download? Teach them how to reconnect
 106         their gmail? Does downloading your gmail work when your network
 107         keeps dying?
 108
 109 K   - Metrics.
 110       * Gather and document monthly usage metrics, by country
 111         - Using Roger's old method of counting users
 112         - Using Nick's new method of counting users
 113         - Start playing around with figuring out which one is more
 114           accurate, or how to combine them to get better guesses,
 115           or something.
 116 R       * Roger should walk Karsten through applying (and maybe
 117           updating) the patch for each method, and write a summary
 118           of what we have tried/guessed so far.
 119       * Automatically collect and document or publish other monthly
 120         statistics
 121         - Total data over time
 122         - Number, availability and performance of relays
 123         - Advertised capacity
 124       - With Mike's help, use Torflow to start doing monthly rudimentary
 125         performance evaluations:
 126         - Circuit throughput and latency
 127         - Measure via Broadband and dialup
 128       - Make a few graphs of the most interesting public data
 129       - Publish a report addressing key long-term metrics questions:
 130         - What metrics should we present?
 131         - What data are available for these metrics?
 132         - What data are missing, and can collect them safely? Can we
 133           publish them safely?
 134         - What systems are available to present this data?
 135
 136 E   - Vidalia improvements
 137       - Implement Vidalia presentation of plaintext port warnings
 138       - Figure out a plan for presenting other Tor status warning events.
 139       - Move Polipo into the main Vidalia -dev bundle.
 140       - Vidalia displays by-country user summary for bridge operators
 141         o Tor sends a status event or something so Vidalia knows what
 142           to display: "clients_seen"
 143
 144 M   - Network scanning and network health
 145       - Implement some initial automated scans.
 146       - Describe a roadmap for how to get from here to plausible,
 147         long-term security scanning tests for Tor network
 148       - Document a strategy for incorporating results into directory
 149         consensus documents. At what phases will we be ready to automate
 150         which parts? How will we recognize when we are ready?
 151
 152 M   - Torbutton development
 153       - Keep up with our bugfixes -- build a plan for (or resolve)
 154         every item in Flyspray, and other known issues like the Google
 155         captcha issue.
 156       - Build a strategy for how Torbutton and Vidalia can
 157         communicate. E.g., what do we do with the 'new identity' button
 158         in Vidalia?
 159       * Make Torbutton happy on FF3, especially so TBB can drop FF2.
 160
 161 C   - Transparent interception of connections on Windows
 162       - Produce prototype, with screenshots for how to install and test.
 163       - Document open issues, future work, things users need to be aware
 164         of, etc.
 165
 166 S   - Tor Browser bundle work
 167       - Use native Vidalia (non-PortableFirefox) launcher for browser
 168       - Close Browser on clean Vidalia exit
 169       - Establish feasibility of simultaneous Firefox usage (also
 170         considering implications for (OpenVPN-style or other) system-wide
 171         Tor interception)
 172       - Switch Tor Browser Bundle to Firefox 3, once Torbutton is ready.
 173       - Decide whether TBB should use Torbutton's "lock" feature.
 174         http://archives.seul.org/or/cvs/Jun-2008/msg00186.html
 175 I     . Jake learns how to build the TBB and takes over doing new
 176         releases.
 177
 178 S   - Continue analyzing "traces" left on host machine by use of
 179       Tor Browser, especially once we have our new launcher and have moved
 180       to FF3. Write a summary of current progress, and what remains. Try
 181       to solve some of the low-hanging fruit.
 182
 183 I   - Periodic summaries of localization progress: both pootle and wml.
 184 I   - Collecting user stories
 185 I   - Revise the 'Tor mirror page' so it doesn't list obsolete-looking
 186       timestamps. Just have two tables, "new enough" and "not new enough".
 187 I   * Get Tor Weather up, stable, and in use by some relay operators.
 188 I   - Get a relay operator mailing list going, with a plan and supporting
 189       scripts and so on.
 190