|
@@ -25,87 +25,24 @@ C - coderman claims
|
|
|
|
|
|
External constraints:
|
|
|
|
|
|
- - mid January
|
|
|
-W - Finish testing, debugging, unit testing, etc the directory overhead
|
|
|
- changes. Have it in the development version and in use.
|
|
|
- o Roger writes a proposal unifying the or-dev discussions
|
|
|
-? * Somebody implements the proposal. Who?
|
|
|
-E - Implement KDE Marble into Vidalia. In order to improve the user
|
|
|
- interface for easier understanding of circuits and where traffic
|
|
|
- travels, replacing the current Vidalia map with KDE's Marble
|
|
|
- is desired. KDE's Marble widget gives a better quality map and
|
|
|
- enables improved interactivity. This is the first step in allowing
|
|
|
- users to choose an exit country, or being able to interact with
|
|
|
- Tor circuits in new ways.
|
|
|
+Past due:
|
|
|
+N - Refine proposal 158, and implement.
|
|
|
|
|
|
- - end of January
|
|
|
- - Write first draft of research study for Paul's research problem.
|
|
|
-R - Get the stuff in the wiki into a "report" we can show some
|
|
|
- bureaucrat, for phase one.
|
|
|
-I - Periodic summaries of localization progress: both pootle and wml.
|
|
|
-
|
|
|
- - 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. Eg, if relays have 100KB/s but set relaybandwidthrate to
|
|
|
- 10KB/s, do your interference attacks still work?
|
|
|
-
|
|
|
- o Revise and publish incentive draft paper
|
|
|
- o Write an explanation for its current flaws
|
|
|
- . Gather comments, search for new designs
|
|
|
- o 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 - TLS arms race: Produce a list of likely avenues for blocking,
|
|
|
- and for each avenue summarize a plan for how we should respond to
|
|
|
- get Tor unblocked again.
|
|
|
+For June/July:
|
|
|
+NR - Work more on Paul's NRL research problem.
|
|
|
|
|
|
+For March 22:
|
|
|
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?
|
|
@@ -114,59 +51,22 @@ K - Metrics.
|
|
|
- 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.
|
|
|
+ - Put out a Vidalia release with the new features in it.
|
|
|
- Vidalia displays by-country user summary for bridge operators
|
|
|
? - write a help page for vidalia, "what is this"
|
|
|
- - Get the onion icons back into vidalia svn
|
|
|
- d Find an OS X user who can do design who thinks the OS X onion
|
|
|
- icons are crappy and need fixing
|
|
|
-
|
|
|
-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 like the Google
|
|
|
- captcha issue.
|
|
|
- - 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.
|
|
|
+ - Put out a Torbutton release with the new features in it.
|
|
|
|
|
|
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.
|
|
|
- - Decide whether TBB should use Torbutton's "lock" feature.
|
|
|
- http://archives.seul.org/or/cvs/Jun-2008/msg00186.html
|
|
|
-I . Jake learns how to build the TBB and takes over doing new
|
|
|
- releases.
|
|
|
+ - Write a summary (with links) of current progress and current
|
|
|
+ limitations.
|
|
|
|
|
|
S - Continue analyzing "traces" left on host machine by use of
|
|
|
Tor Browser, especially once we have our new launcher and have moved
|
|
|
to FF3. Write a summary of current progress, and what remains. Try
|
|
|
to solve some of the low-hanging fruit.
|
|
|
|
|
|
-I - Periodic summaries of localization progress: both pootle and wml.
|
|
|
-I - Collecting user stories
|
|
|
-I d Revise the 'Tor mirror page' so it doesn't list obsolete-looking
|
|
|
- timestamps. Just have two tables, "new enough" and "not new enough".
|
|
|
-I * Get Tor Weather up, stable, and in use by some relay operators.
|
|
|
I d Get a relay operator mailing list going, with a plan and supporting
|
|
|
scripts and so on.
|
|
|
|