1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
|
$Id: TODO 16258 2008-07-30 13:04:38Z nickm $
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
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 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.
|