[or-cvs] r20011: {} put the TODO.external file somewhere we can edit it (in projects: . todo)

arma at seul.org arma at seul.org
Tue Jul 14 17:06:00 UTC 2009


Author: arma
Date: 2009-07-14 13:05:59 -0400 (Tue, 14 Jul 2009)
New Revision: 20011

Added:
   projects/todo/
   projects/todo/TODO.external
Log:
put the TODO.external file somewhere we can edit it


Copied: projects/todo/TODO.external (from rev 20010, tor/trunk/doc/TODO.external)
===================================================================
--- projects/todo/TODO.external	                        (rev 0)
+++ projects/todo/TODO.external	2009-07-14 17:05:59 UTC (rev 20011)
@@ -0,0 +1,196 @@
+$Id$
+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
+



More information about the tor-commits mailing list