[or-cvs] [tor/master] move the todo.external file into svn projects

arma at seul.org arma at seul.org
Wed Jul 15 03:36:17 UTC 2009


Author: Roger Dingledine <arma at torproject.org>
Date: Tue, 14 Jul 2009 23:35:34 -0400
Subject: move the todo.external file into svn projects
Commit: 72c5a46b43c6d89c773a99240a95301b91b1f269

---
 doc/TODO          |    4 +-
 doc/TODO.external |  188 +----------------------------------------------------
 2 files changed, 4 insertions(+), 188 deletions(-)

diff --git a/doc/TODO b/doc/TODO
index fd023c8..194d650 100644
--- a/doc/TODO
+++ b/doc/TODO
@@ -4,8 +4,8 @@ We've split out our TODO into three files:
 TODO.02x is the list of items we're planning to get done in the next
 stable release.
 
-TODO.external is the list of external constraints and deliverables that
-we all need to keep in mind.
+TODO.external lives in svn under /projects/todo/. It's the list of
+external constraints and deliverables that we all need to keep in mind.
 
 TODO.future is the list of other items we plan to get to in later releases.
 
diff --git a/doc/TODO.external b/doc/TODO.external
index 12048fa..2e7e536 100644
--- a/doc/TODO.external
+++ b/doc/TODO.external
@@ -1,188 +1,4 @@
-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.
-      - Implement Proposal 160
-    o 4.5, Older entry guards are overloaded
-      o 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
+[This file moved to svn in /projects/todo/. More people can edit
+it more easily there. -RD]
 
-- 
1.5.6.5



More information about the tor-commits mailing list