aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorRoger Dingledine <arma@torproject.org>2008-12-07 18:49:28 +0000
committerRoger Dingledine <arma@torproject.org>2008-12-07 18:49:28 +0000
commit84581b47234838dc2b7fc70055f7ba09cd58a91c (patch)
treece81b5236cbcbb20fbc0c0a16c949754efc50e92
parent0f8fb53088f150c1078161241842ae266f69563c (diff)
downloadtor-84581b47234838dc2b7fc70055f7ba09cd58a91c.tar.gz
tor-84581b47234838dc2b7fc70055f7ba09cd58a91c.zip
first cut of mid-february goals.
svn:r17510
-rw-r--r--doc/TODO.external112
1 files changed, 112 insertions, 0 deletions
diff --git a/doc/TODO.external b/doc/TODO.external
index b2091fea30..308696a3ef 100644
--- a/doc/TODO.external
+++ b/doc/TODO.external
@@ -44,3 +44,115 @@ W - Finish testing, debugging, unit testing, etc the directory overhead
- end of January
NSE - Write first draft of research study for Paul's research problem.
+ - mid February
+S - Examine current load balancing issues and evaluate trade-offs
+ associated with other methods.
+ - For each potential routing improvement strategy...
+ - Explain method, calculate theoretical impact, estimate likely
+ impact, prioritize
+ - Establish implementation work plan
+ - Document strategy for metrics and evaluation
+ - Highlight which items on your list are doable in 2009.
+
+N - Write a summary of progress toward Overlapped I/O on Windows.
+
+S - Write a summary of progress toward understanding risks to relays
+ (and thus bridges) from letting attackers route traffic through
+ them.
+
+R - Revise and publish incentive draft paper
+ - Write an explanation for its current flaws
+ - Gather comments, search for new designs
+ - Write up a summary of recommendations and next steps
+
+W - Download fewer descriptors
+ - Summarize progress so far, on all the different approaches to
+ reducing directory download overhead.
+ - Measure/estimate impact of each improvement.
+ - Build a plan and timeline for implementing the rest.
+
+N - Write a summary of progress toward "enumerating TLS fingerprint
+ blocking risks and how we would overcome / respond to each".
+
+I - Email auto-responder
+ - Document the design and spec.
+ - Describe auto-responder "commands"
+ - Describe DKIM requirement (and alternatives)
+ - Describe how we're going to localize the text
+ - Describe the workflow for a user that wants to know she's got
+ the right file. Digitally signed installer? Feed it to the
+ updater that recognizes signatures? Other options?
+ - How do we better support users with limited email
+ bandwidth? Multi-part download? Teach them how to reconnect
+ their gmail? Does downloading your gmail work when your network
+ keeps dying?
+
+K - Metrics.
+ - Gather and document monthly usage metrics, by country
+ - Using Roger's old method of counting users
+ - Using Nick's new method of counting users
+ - Start playing around with figuring out which one is more
+ accurate, or how to combine them to get better guesses,
+ or something.
+ - Automatically collect and document or publish other monthly
+ statistics
+ - Total data over time
+ - Number, availability and performance of relays
+ - Advertised capacity
+ - With Mike's help, use Torflow to start doing monthly rudimentary
+ performance evaluations:
+ - Circuit throughput and latency
+ - Measure via Broadband and dialup
+ - Make a few graphs of the most interesting public data
+ - 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
+ - Implement Vidalia presentation of plaintext port warnings
+ - Figure out a plan for presenting other Tor status warning events.
+ - Move Polipo into the main Vidalia -dev bundle.
+ - Vidalia displays by-country user summary for bridge operators
+R - Tor sends a status event or something so Vidalia knows what
+ to display
+
+M - Network scanning and network health
+ - Implement some initial automated scans.
+ - Describe a roadmap for how to get from here to plausible,
+ long-term security scanning tests for Tor network
+ - Document a strategy for incorporating results into directory
+ consensus documents. At what phases will we be ready to automate
+ which parts? How will we recognize when we are ready?
+
+M - Torbutton development
+ - Keep up with our bugfixes -- build a plan for (or resolve)
+ every item in Flyspray, and other known issues.
+ - Build a strategy for how Torbutton and Vidalia can
+ communicate. E.g., what do we do with the 'new identity' button
+ in Vidalia?
+ - Make Torbutton happy on FF3, especially so TBB can drop FF2.
+
+C - Transparent interception of connections on Windows
+ - Produce prototype, with screenshots for how to install and test.
+ - Document open issues, future work, things users need to be aware
+ of, etc.
+
+S - Tor Browser bundle work
+ - Use native Vidalia (non-PortableFirefox) launcher for browser
+ - Close Browser on clean Vidalia exit
+ - Establish feasibility of simultaneous Firefox usage (also
+ considering implications for (OpenVPN-style or other) system-wide
+ Tor interception)
+ - Switch Tor Browser Bundle to Firefox 3, once Torbutton is ready.
+ - Continue analyzing "traces" left on host machine by use of
+ Tor Browser. Write a summary of current progress, and what
+ remains.
+
+I - Periodic summaries of localization progress
+I - Collecting user stories
+I - Revise the 'Tor mirror page' so it doesn't list obsolete-looking
+ timestamps. Just have two tables, "new enough" and "not new enough".
+