tor-parallel-relay-conn/doc/TODO.external

Legend:
SPEC!!  - Not specified
SPEC    - Spec not finalized
N       - nick claims
R       - arma claims
P       - phobos claims
S       - Steven claims
E       - Matt claims
M       - Mike claims
J       - Jeff claims
I       - ioerror claims
W       - weasel claims
K       - Karsten claims
C       - coderman claims
        - Not done
        * Top priority
        . Partially done
        o Done
        d Deferrable
        D Deferred
        X Abandoned

=======================================================================

External constraints:

For June/July:
NR  - Work more on Paul's NRL research problem.

For March 22:
I   * Email auto-responder
      * teach gettor how to ask for (and attach) split files.

K   . Metrics.
      . With Mike's help, use Torflow to start doing monthly rudimentary
        performance evaluations:
        . Circuit throughput and latency
        - Measure via Broadband and dialup
      . Publish a report addressing key long-term metrics questions:
        . What metrics should we present?
        . What data are available for these metrics?
        . What data are missing, and can collect them safely? Can we
          publish them safely?
        . What systems are available to present this data?

E   . Vidalia improvements
      o Vidalia displays by-country user summary for bridge operators
?       - write a help page for vidalia, "what is this"

For mid August:

Section 0, items that didn't make it into the original roadmap:

0.1, installers and packaging
C . i18n for the msi bundle files
P . more consistent TBB builds
IC- get a buildbot up again. Have Linux and BSD build machines.
    (Windows would be nice but realistically will come later.)
E - Get Tor to work properly on the iPhone.

3.1, performance work. [Section numbers in here are from performance.pdf]
  - High-priority items from performance.pdf
RS  - 1.2, new circuit window sizes. make the default package window lower.
R+  - 2.1, squeeze loud circuits
      - Evaluate the code to see what stats we can keep about circuit use.
      - Write proposals for various meddling. Look at the research papers
        that Juliusz pointed us to. Ask our systems friends. Plan to put
        a lot of the parameters in the consensus, so we can tune it with
        short turnaround times.
E+  - 2.5, Change Vidalia's default exit policy to not click "other
      protocols". Or choose not to. Think this through first.
R+  - 2.6, Tell users not to file-share.
      - Put statement on the Tor front page
      - Put statement on the download pages too
      - And the FAQ
    - 3.1.2, Tor weather
I     - Implement time-to-notification (immediate, a day, a week)
I     - Get a relay operator mailing list going, with a plan and supporting
        scripts and so on.
R     - Link to them from the Tor relay page
R     - and the torrc.sample?
SM  - 4.1, balance traffic better
      - Steven and Mike should decide if we should do Steven's plan
        (rejigger the bandwidth numbers at the authorities based on
        Steven's algorithm), or Mike's plan (relay scanning to identify
        the unbalanced relays and fix them on the fly), or both.
      - Figure out how to actually modify bandwidths in the consensus. We
        may need to change the consensus voting algorithm to decide what
        bandwidth to advertise based on something other than median:
        if 7 authorities provide bandwidths, and 2 are doing scanning,
        then the 5 that aren't scanning will outvote any changes. Should
        all 7 scan? Should only some vote? Extra points if it doesn't
        change all the numbers every new consensus, so consensus diffing
        is still practical.
?   - 4.5, Older entry guards are overloaded
      - Pick a conservative timeout like a month, and implement.
M   - 5.2, better timeouts for giving up on circuits/streams
      - clients gather data about circuit timeouts, and then abandon
        circuits that take more than a std dev above that.

4.1, IOCP / libevent / windows / tor
N - get it working for nick
N - put out a release so other people can start testing it.
N - both the libevent buffer abstraction, and the
    tor-uses-libevent-buffer-abstraction. Unless we think that's
    unreachable for this milestone?

4.2.1, risks from becoming a relay
S - Have a clear plan for how users who become relays will be safe,
    and be confident that we can build this plan.
    - evaluate all the various attacks that are made possible by relaying.
      specifically, see "relaying-traffic attacks" in 6.6.
    - identify and evaluate ways to make them not a big deal
      - setting a low RelayBandwidth
      - Nick Hopper's FC08 paper suggesting that we should do a modified
        round-robin so we leak less about other circuits
      - instructing clients to disable pings in their firewall, etc
    - pick the promising ones, improve them so they're even better, and
      spec them out so we know how to build them and how much effort is
      involved in building them.

4.5, clients download less directory info
N * deploy proposal 158.
N - decide whether to do proposal 140. if so, construct an implementation
    plan for how we'll do it. if not, explain why not.

5.1, Normalize TLS fingerprint
N o write a draft list of possible attacks for this section, with
    estimates about difficulty of attack, difficulty of solution, etc
N - revisit the list and revise our plans as needed
NR- put up a blog post about the two contradictory conclusions: we can
    discuss the theory of arms races, and our quandry, without revealing
    any specific vulnerabilities. (or decide not to put up a blog post,
    and explain why not.)

5.5, email autoresponder
I . maintenance and keeping it running

5.7.2, metrics

XXX.

6.2, Vidalia work
E - add breakpad support or similar for windows debugging
E o let vidalia change languages without needing a restart
E - Implement the status warning event interface started for the
    phase one deliverables.
E - Work with Steve Tyree on building a Vidalia plugin API to enable
    building Herdict and TBB plugins.

6.3, Node scanning
M - Steps toward automation
    - Set up email list for results
    - Map failure types to potential BadExit lines
M - Improve the ability of SoaT to mimic various real web browsers
    - randomizing user agents and locale strings
    - caching, XMLHTTPRequest, form posting, content sniffing
    - Investigate ideas like running Chrome/xulrunner in parallel
M - Other protocols
    - SSH, IMAPS, POPS, SMTPS
M - Add ability to geolocalize exit selection based on scanner location
    - Use this to rescan dynamic urls filtered by the URL filter

6.4, Torbutton development
M - Resolve extension conflicts and other high priority bugs
M - Fix or hack around ugly firefox bugs, especially Timezone issue.
    Definitely leaning towards "hack around" unless we see some
    level of love from Mozilla.
M - Vidalia New Nym Integration
    - Implement for Torbutton to pick up on Vidalia's NEWNYM and clear
      cookies based on FoeBud's source
    - Do this in such a way that we could adapt polipo to purge cache
      if we were so inclined
M - Write up a summary of our options for dealing with the google
    you-must-solve-a-captcha-to-search problem, and pick one as our
    favorite option.

6.6, Evaluate new anonymity attacks
S - relaying-traffic attacks
    - original murdoch-danezis attack
    - nick hopper's latency measurement attack
    - columbia bandwidth measurement attack
    - christian grothoff's long-circuit attack
S - client attacks
    - website fingerprinting

7.1, Tor VM Research, analysis, and prototyping
C . Get a working package out, meaning other people are testing it.

7.2, Tor Browser Bundle
I - Port to one of OS X or Linux, and start the port to the other.
I . Make it the recommended Tor download on Windows
I - Make sure it's easy to un-brand TBB in case Firefox asks us to
I - Evaluate CCC's Freedom Stick