|  | @@ -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.
 | 
	
		
			
				|  |  |  
 |