mark a few todo items as deferable
[tor.git] / doc / TODO.external
blob5ff8e4fcae237862a5b678ed17936231add1c4fe
1 $Id$
2 Legend:
3 SPEC!!  - Not specified
4 SPEC    - Spec not finalized
5 N       - nick claims
6 R       - arma claims
7 P       - phobos claims
8 S       - Steven claims
9 E       - Matt claims
10 M       - Mike claims
11 J       - Jeff claims
12 I       - ioerror claims
13 W       - weasel claims
14 K       - Karsten claims
15 C       - coderman claims
16         - Not done
17         * Top priority
18         . Partially done
19         o Done
20         d Deferrable
21         D Deferred
22         X Abandoned
24 =======================================================================
26 External constraints:
28   - mid January
29 W   - Finish testing, debugging, unit testing, etc the directory overhead
30       changes. Have it in the development version and in use.
31       o Roger writes a proposal unifying the or-dev discussions
32 ?     * Somebody implements the proposal. Who?
33 E   - Implement KDE Marble into Vidalia.  In order to improve the user
34       interface for easier understanding of circuits and where traffic
35       travels, replacing the current Vidalia map with KDE's Marble
36       is desired.  KDE's Marble widget gives a better quality map and
37       enables improved interactivity.  This is the first step in allowing
38       users to choose an exit country, or being able to interact with
39       Tor circuits in new ways.
41   - end of January
42     - Write first draft of research study for Paul's research problem.
43 R     - Get the stuff in the wiki into a "report" we can show some
44         bureaucrat, for phase one.
45 I   - Periodic summaries of localization progress: both pootle and wml.
47   - mid February
48 S   * Examine current load balancing issues and evaluate trade-offs
49       associated with other methods.
50       - For each potential routing improvement strategy...
51         - Explain method, calculate theoretical impact, estimate likely
52           impact, prioritize
53         - Establish implementation work plan
54         - Document strategy for metrics and evaluation
55       - Highlight which items on your list are doable in 2009.
57 N   - Write a summary of progress toward Overlapped I/O on Windows.
59 S   - Write a summary of progress toward understanding risks to relays
60       (and thus bridges) from letting attackers route traffic through
61       them. Eg, if relays have 100KB/s but set relaybandwidthrate to
62       10KB/s, do your interference attacks still work?
64 W   - Download fewer descriptors
65       - Summarize progress so far, on all the different approaches to
66         reducing directory download overhead.
67         - Measure/estimate impact of each improvement.
68       - Build a plan and timeline for implementing the rest.
70 N   - TLS arms race: Produce a list of likely avenues for blocking,
71       and for each avenue summarize a plan for how we should respond to
72       get Tor unblocked again.
74 I   * Email auto-responder
75       - Document the design and spec.
76         - Describe auto-responder "commands"
77         - Describe DKIM requirement (and alternatives)
78         - Describe how we're going to localize the text
79       - Describe the workflow for a user that wants to know she's got
80         the right file. Digitally signed installer? Feed it to the
81         updater that recognizes signatures? Other options?
82       * How do we better support users with limited email
83         bandwidth? Multi-part download? Teach them how to reconnect
84         their gmail? Does downloading your gmail work when your network
85         keeps dying?
87 K   - Metrics.
88       * Gather and document monthly usage metrics, by country
89         - Using Roger's old method of counting users
90         - Using Nick's new method of counting users
91         - Start playing around with figuring out which one is more
92           accurate, or how to combine them to get better guesses,
93           or something.
94       * Automatically collect and document or publish other monthly
95         statistics
96         - Total data over time
97         - Number, availability and performance of relays
98         - Advertised capacity
99       - With Mike's help, use Torflow to start doing monthly rudimentary
100         performance evaluations:
101         - Circuit throughput and latency
102         - Measure via Broadband and dialup
103       - Make a few graphs of the most interesting public data
104       - Publish a report addressing key long-term metrics questions:
105         - What metrics should we present?
106         - What data are available for these metrics?
107         - What data are missing, and can collect them safely? Can we
108           publish them safely?
109         - What systems are available to present this data?
111 E   - Vidalia improvements
112       - Implement Vidalia presentation of plaintext port warnings
113       - Figure out a plan for presenting other Tor status warning events.
114       - Move Polipo into the main Vidalia -dev bundle.
115       - Vidalia displays by-country user summary for bridge operators
116 ?       - write a help page for vidalia, "what is this"
117       - Get the onion icons back into vidalia svn
118         d Find an OS X user who can do design who thinks the OS X onion
119           icons are crappy and need fixing
121 M   - Network scanning and network health
122       - Implement some initial automated scans.
123       - Describe a roadmap for how to get from here to plausible,
124         long-term security scanning tests for Tor network
125       - Document a strategy for incorporating results into directory
126         consensus documents. At what phases will we be ready to automate
127         which parts? How will we recognize when we are ready?
129 M   - Torbutton development
130       - Keep up with our bugfixes -- build a plan for (or resolve)
131         every item in Flyspray, and other known issues like the Google
132         captcha issue.
133       - Build a strategy for how Torbutton and Vidalia can
134         communicate. E.g., what do we do with the 'new identity' button
135         in Vidalia?
136       * Make Torbutton happy on FF3, especially so TBB can drop FF2.
138 C   - Transparent interception of connections on Windows
139       - Produce prototype, with screenshots for how to install and test.
140       - Document open issues, future work, things users need to be aware
141         of, etc.
143 S   - Tor Browser bundle work
144       - Use native Vidalia (non-PortableFirefox) launcher for browser
145       - Close Browser on clean Vidalia exit
146       - Establish feasibility of simultaneous Firefox usage (also
147         considering implications for (OpenVPN-style or other) system-wide
148         Tor interception)
149       - Switch Tor Browser Bundle to Firefox 3, once Torbutton is ready.
150       - Decide whether TBB should use Torbutton's "lock" feature.
151         http://archives.seul.org/or/cvs/Jun-2008/msg00186.html
152 I     . Jake learns how to build the TBB and takes over doing new
153         releases.
155 S   - Continue analyzing "traces" left on host machine by use of
156       Tor Browser, especially once we have our new launcher and have moved
157       to FF3. Write a summary of current progress, and what remains. Try
158       to solve some of the low-hanging fruit.
160 I   - Periodic summaries of localization progress: both pootle and wml.
161 I   - Collecting user stories
162 I   d Revise the 'Tor mirror page' so it doesn't list obsolete-looking
163       timestamps. Just have two tables, "new enough" and "not new enough".
164 I   * Get Tor Weather up, stable, and in use by some relay operators.
165 I   d Get a relay operator mailing list going, with a plan and supporting
166       scripts and so on.