[or-cvs] r20013: {projects} mark a few todo items done (projects/todo)

[arma at seul.org]

Author: arma
Date: 2009-07-14 13:54:51 -0400 (Tue, 14 Jul 2009)
New Revision: 20013

Modified:
   projects/todo/TODO.external
Log:
mark a few todo items done


Modified: projects/todo/TODO.external
===================================================================
--- projects/todo/TODO.external	2009-07-14 17:07:16 UTC (rev 20012)
+++ projects/todo/TODO.external	2009-07-14 17:54:51 UTC (rev 20013)
@@ -61,7 +61,7 @@
 
 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   - 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
@@ -75,17 +75,19 @@
       - 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     . 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
+    - 4.1, balance traffic better
+      o 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
+        Answer: go with Mike's active testing plan, since it seems more
+        robust to our ignorance about why Tor is slow.
+      o 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,
@@ -93,8 +95,9 @@
         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.
+      - Get three authorities running the scanners in reality.
+    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.
@@ -182,8 +185,8 @@
     - nick hopper's latency measurement attack
     - columbia bandwidth measurement attack
     - christian grothoff's long-circuit attack
-S - client attacks
-    - website fingerprinting
+S d client attacks
+    d website fingerprinting
 
 7.1, Tor VM Research, analysis, and prototyping
 C . Get a working package out, meaning other people are testing it.
@@ -191,6 +194,6 @@
 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 o Make sure it's easy to un-brand TBB in case Firefox asks us to
 I - Evaluate CCC's Freedom Stick