diff options
author | Roger Dingledine <arma@torproject.org> | 2008-12-07 18:49:28 +0000 |
---|---|---|
committer | Roger Dingledine <arma@torproject.org> | 2008-12-07 18:49:28 +0000 |
commit | 84581b47234838dc2b7fc70055f7ba09cd58a91c (patch) | |
tree | ce81b5236cbcbb20fbc0c0a16c949754efc50e92 | |
parent | 0f8fb53088f150c1078161241842ae266f69563c (diff) | |
download | tor-84581b47234838dc2b7fc70055f7ba09cd58a91c.tar tor-84581b47234838dc2b7fc70055f7ba09cd58a91c.tar.gz |
first cut of mid-february goals.
svn:r17510
-rw-r--r-- | doc/TODO.external | 112 |
1 files changed, 112 insertions, 0 deletions
diff --git a/doc/TODO.external b/doc/TODO.external index b2091fea3..308696a3e 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". + |