123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190 |
- $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:
- - mid October
- W - Finish implementation of directory overhead changes: have a set
- of patches that you think work.
- - end of October
- - Auto update
- C * Get the MSI working and stable for Windows Tor installer.
- N o Come up with an interface to export the package/bundle gloss
- descriptions so Vidalia can display them.
- (Done; see thandy-client json2xml. Matt was fine with this,
- last I heard.)
- E * Vidalia calls Thandy, learns when to upgrade, requests the upgrade.
- ? - Teach our OSX installer to register its version on install
- - end of December
- I - Periodic summaries of localization progress: both pootle and wml.
- - mid January
- KS . Finish testing, debugging, unit testing, etc the hidden service
- changes. Have it in the development version and in use.
- W - Finish testing, debugging, unit testing, etc the directory overhead
- changes. Have it in the development version and in use.
- R - 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.
- - end of January
- NSE - Write first draft of research study for Paul's research problem.
- 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?
- 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 - 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.
- 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.
- R * Roger should walk Karsten through applying (and maybe
- updating) the patch for each method, and write a summary
- of what we have tried/guessed so far.
- * 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
- o Tor sends a status event or something so Vidalia knows what
- to display: "clients_seen"
- 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.
- 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.
- 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 - 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 - Get a relay operator mailing list going, with a plan and supporting
- scripts and so on.
|