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 For June/July:
  29 NR  - Work more on Paul's NRL research problem.
  30
  31 For March 22:
  32 I   * Email auto-responder
  33       * teach gettor how to ask for (and attach) split files.
  34
  35 K   . Metrics.
  36       . With Mike's help, use Torflow to start doing monthly rudimentary
  37         performance evaluations:
  38         . Circuit throughput and latency
  39         - Measure via Broadband and dialup
  40       . Publish a report addressing key long-term metrics questions:
  41         . What metrics should we present?
  42         . What data are available for these metrics?
  43         . What data are missing, and can collect them safely? Can we
  44           publish them safely?
  45         . What systems are available to present this data?
  46
  47 E   . Vidalia improvements
  48       o Vidalia displays by-country user summary for bridge operators
  49 ?       - write a help page for vidalia, "what is this"
  50
  51 For mid August:
  52
  53 Section 0, items that didn't make it into the original roadmap:
  54
  55 0.1, installers and packaging
  56 C . i18n for the msi bundle files
  57 P . more consistent TBB builds
  58 IC- get a buildbot up again. Have Linux and BSD build machines.
  59     (Windows would be nice but realistically will come later.)
  60 E - Get Tor to work properly on the iPhone.
  61
  62 3.1, performance work. [Section numbers in here are from performance.pdf]
  63   - High-priority items from performance.pdf
  64 RS  - 1.2, new circuit window sizes. make the default package window lower.
  65 R+  - 2.1, squeeze loud circuits
  66       - Evaluate the code to see what stats we can keep about circuit use.
  67       - Write proposals for various meddling. Look at the research papers
  68         that Juliusz pointed us to. Ask our systems friends. Plan to put
  69         a lot of the parameters in the consensus, so we can tune it with
  70         short turnaround times.
  71 E+  - 2.5, Change Vidalia's default exit policy to not click "other
  72       protocols". Or choose not to. Think this through first.
  73 R+  - 2.6, Tell users not to file-share.
  74       - Put statement on the Tor front page
  75       - Put statement on the download pages too
  76       - And the FAQ
  77     - 3.1.2, Tor weather
  78 I     - Implement time-to-notification (immediate, a day, a week)
  79 I     - Get a relay operator mailing list going, with a plan and supporting
  80         scripts and so on.
  81 R     - Link to them from the Tor relay page
  82 R     - and the torrc.sample?
  83 SM  - 4.1, balance traffic better
  84       - Steven and Mike should decide if we should do Steven's plan
  85         (rejigger the bandwidth numbers at the authorities based on
  86         Steven's algorithm), or Mike's plan (relay scanning to identify
  87         the unbalanced relays and fix them on the fly), or both.
  88       - Figure out how to actually modify bandwidths in the consensus. We
  89         may need to change the consensus voting algorithm to decide what
  90         bandwidth to advertise based on something other than median:
  91         if 7 authorities provide bandwidths, and 2 are doing scanning,
  92         then the 5 that aren't scanning will outvote any changes. Should
  93         all 7 scan? Should only some vote? Extra points if it doesn't
  94         change all the numbers every new consensus, so consensus diffing
  95         is still practical.
  96 ?   - 4.5, Older entry guards are overloaded
  97       - Pick a conservative timeout like a month, and implement.
  98 M   - 5.2, better timeouts for giving up on circuits/streams
  99       - clients gather data about circuit timeouts, and then abandon
 100         circuits that take more than a std dev above that.
 101
 102 4.1, IOCP / libevent / windows / tor
 103 N - get it working for nick
 104 N - put out a release so other people can start testing it.
 105 N - both the libevent buffer abstraction, and the
 106     tor-uses-libevent-buffer-abstraction. Unless we think that's
 107     unreachable for this milestone?
 108
 109 4.2.1, risks from becoming a relay
 110 S - Have a clear plan for how users who become relays will be safe,
 111     and be confident that we can build this plan.
 112     - evaluate all the various attacks that are made possible by relaying.
 113       specifically, see "relaying-traffic attacks" in 6.6.
 114     - identify and evaluate ways to make them not a big deal
 115       - setting a low RelayBandwidth
 116       - Nick Hopper's FC08 paper suggesting that we should do a modified
 117         round-robin so we leak less about other circuits
 118       - instructing clients to disable pings in their firewall, etc
 119     - pick the promising ones, improve them so they're even better, and
 120       spec them out so we know how to build them and how much effort is
 121       involved in building them.
 122
 123 4.5, clients download less directory info
 124 N * deploy proposal 158.
 125 N - decide whether to do proposal 140. if so, construct an implementation
 126     plan for how we'll do it. if not, explain why not.
 127
 128 5.1, Normalize TLS fingerprint
 129 N o write a draft list of possible attacks for this section, with
 130     estimates about difficulty of attack, difficulty of solution, etc
 131 N - revisit the list and revise our plans as needed
 132 NR- put up a blog post about the two contradictory conclusions: we can
 133     discuss the theory of arms races, and our quandry, without revealing
 134     any specific vulnerabilities. (or decide not to put up a blog post,
 135     and explain why not.)
 136
 137 5.5, email autoresponder
 138 I . maintenance and keeping it running
 139
 140 5.7.2, metrics
 141
 142 XXX.
 143
 144 6.2, Vidalia work
 145 E - add breakpad support or similar for windows debugging
 146 E o let vidalia change languages without needing a restart
 147 E - Implement the status warning event interface started for the
 148     phase one deliverables.
 149 E - Work with Steve Tyree on building a Vidalia plugin API to enable
 150     building Herdict and TBB plugins.
 151
 152 6.3, Node scanning
 153 M - Steps toward automation
 154     - Set up email list for results
 155     - Map failure types to potential BadExit lines
 156 M - Improve the ability of SoaT to mimic various real web browsers
 157     - randomizing user agents and locale strings
 158     - caching, XMLHTTPRequest, form posting, content sniffing
 159     - Investigate ideas like running Chrome/xulrunner in parallel
 160 M - Other protocols
 161     - SSH, IMAPS, POPS, SMTPS
 162 M - Add ability to geolocalize exit selection based on scanner location
 163     - Use this to rescan dynamic urls filtered by the URL filter
 164
 165 6.4, Torbutton development
 166 M - Resolve extension conflicts and other high priority bugs
 167 M - Fix or hack around ugly firefox bugs, especially Timezone issue.
 168     Definitely leaning towards "hack around" unless we see some
 169     level of love from Mozilla.
 170 M - Vidalia New Nym Integration
 171     - Implement for Torbutton to pick up on Vidalia's NEWNYM and clear
 172       cookies based on FoeBud's source
 173     - Do this in such a way that we could adapt polipo to purge cache
 174       if we were so inclined
 175 M - Write up a summary of our options for dealing with the google
 176     you-must-solve-a-captcha-to-search problem, and pick one as our
 177     favorite option.
 178
 179 6.6, Evaluate new anonymity attacks
 180 S - relaying-traffic attacks
 181     - original murdoch-danezis attack
 182     - nick hopper's latency measurement attack
 183     - columbia bandwidth measurement attack
 184     - christian grothoff's long-circuit attack
 185 S - client attacks
 186     - website fingerprinting
 187
 188 7.1, Tor VM Research, analysis, and prototyping
 189 C . Get a working package out, meaning other people are testing it.
 190
 191 7.2, Tor Browser Bundle
 192 I - Port to one of OS X or Linux, and start the port to the other.
 193 I . Make it the recommended Tor download on Windows
 194 I - Make sure it's easy to un-brand TBB in case Firefox asks us to
 195 I - Evaluate CCC's Freedom Stick
 196