3 SPEC - Spec not finalized
23 =======================================================================
28 NR - Work more on Paul's NRL research problem.
31 I * Email auto-responder
32 * teach gettor how to ask for (and attach) split files.
35 . With Mike's help, use Torflow to start doing monthly rudimentary
36 performance evaluations:
37 . Circuit throughput and latency
38 - Measure via Broadband and dialup
39 . Publish a report addressing key long-term metrics questions:
40 . What metrics should we present?
41 . What data are available for these metrics?
42 . What data are missing, and can collect them safely? Can we
44 . What systems are available to present this data?
46 E . Vidalia improvements
47 o Vidalia displays by-country user summary for bridge operators
48 ? - write a help page for vidalia, "what is this"
52 Section 0, items that didn't make it into the original roadmap:
54 0.1, installers and packaging
55 C . i18n for the msi bundle files
56 P . more consistent TBB builds
57 IC- get a buildbot up again. Have Linux and BSD build machines.
58 (Windows would be nice but realistically will come later.)
59 E - Get Tor to work properly on the iPhone.
61 3.1, performance work. [Section numbers in here are from performance.pdf]
62 - High-priority items from performance.pdf
63 RS - 1.2, new circuit window sizes. make the default package window lower.
64 R+ - 2.1, squeeze loud circuits
65 - Evaluate the code to see what stats we can keep about circuit use.
66 - Write proposals for various meddling. Look at the research papers
67 that Juliusz pointed us to. Ask our systems friends. Plan to put
68 a lot of the parameters in the consensus, so we can tune it with
69 short turnaround times.
70 E+ - 2.5, Change Vidalia's default exit policy to not click "other
71 protocols". Or choose not to. Think this through first.
72 R+ - 2.6, Tell users not to file-share.
73 - Put statement on the Tor front page
74 - Put statement on the download pages too
77 I - Implement time-to-notification (immediate, a day, a week)
78 I - Get a relay operator mailing list going, with a plan and supporting
80 R - Link to them from the Tor relay page
81 R - and the torrc.sample?
82 SM - 4.1, balance traffic better
83 - Steven and Mike should decide if we should do Steven's plan
84 (rejigger the bandwidth numbers at the authorities based on
85 Steven's algorithm), or Mike's plan (relay scanning to identify
86 the unbalanced relays and fix them on the fly), or both.
87 - Implement Proposal 160
88 o 4.5, Older entry guards are overloaded
89 o Pick a conservative timeout like a month, and implement.
90 M - 5.2, better timeouts for giving up on circuits/streams
91 - clients gather data about circuit timeouts, and then abandon
92 circuits that take more than a std dev above that.
94 4.1, IOCP / libevent / windows / tor
95 N - get it working for nick
96 N - put out a release so other people can start testing it.
97 N - both the libevent buffer abstraction, and the
98 tor-uses-libevent-buffer-abstraction. Unless we think that's
99 unreachable for this milestone?
101 4.2.1, risks from becoming a relay
102 S - Have a clear plan for how users who become relays will be safe,
103 and be confident that we can build this plan.
104 - evaluate all the various attacks that are made possible by relaying.
105 specifically, see "relaying-traffic attacks" in 6.6.
106 - identify and evaluate ways to make them not a big deal
107 - setting a low RelayBandwidth
108 - Nick Hopper's FC08 paper suggesting that we should do a modified
109 round-robin so we leak less about other circuits
110 - instructing clients to disable pings in their firewall, etc
111 - pick the promising ones, improve them so they're even better, and
112 spec them out so we know how to build them and how much effort is
113 involved in building them.
115 4.5, clients download less directory info
116 N * deploy proposal 158.
117 N - decide whether to do proposal 140. if so, construct an implementation
118 plan for how we'll do it. if not, explain why not.
120 5.1, Normalize TLS fingerprint
121 N o write a draft list of possible attacks for this section, with
122 estimates about difficulty of attack, difficulty of solution, etc
123 N - revisit the list and revise our plans as needed
124 NR- put up a blog post about the two contradictory conclusions: we can
125 discuss the theory of arms races, and our quandry, without revealing
126 any specific vulnerabilities. (or decide not to put up a blog post,
127 and explain why not.)
129 5.5, email autoresponder
130 I . maintenance and keeping it running
137 E - add breakpad support or similar for windows debugging
138 E o let vidalia change languages without needing a restart
139 E - Implement the status warning event interface started for the
140 phase one deliverables.
141 E - Work with Steve Tyree on building a Vidalia plugin API to enable
142 building Herdict and TBB plugins.
145 M - Steps toward automation
146 - Set up email list for results
147 - Map failure types to potential BadExit lines
148 M - Improve the ability of SoaT to mimic various real web browsers
149 - randomizing user agents and locale strings
150 - caching, XMLHTTPRequest, form posting, content sniffing
151 - Investigate ideas like running Chrome/xulrunner in parallel
153 - SSH, IMAPS, POPS, SMTPS
154 M - Add ability to geolocalize exit selection based on scanner location
155 - Use this to rescan dynamic urls filtered by the URL filter
157 6.4, Torbutton development
158 M - Resolve extension conflicts and other high priority bugs
159 M - Fix or hack around ugly firefox bugs, especially Timezone issue.
160 Definitely leaning towards "hack around" unless we see some
161 level of love from Mozilla.
162 M - Vidalia New Nym Integration
163 - Implement for Torbutton to pick up on Vidalia's NEWNYM and clear
164 cookies based on FoeBud's source
165 - Do this in such a way that we could adapt polipo to purge cache
166 if we were so inclined
167 M - Write up a summary of our options for dealing with the google
168 you-must-solve-a-captcha-to-search problem, and pick one as our
171 6.6, Evaluate new anonymity attacks
172 S - relaying-traffic attacks
173 - original murdoch-danezis attack
174 - nick hopper's latency measurement attack
175 - columbia bandwidth measurement attack
176 - christian grothoff's long-circuit attack
178 - website fingerprinting
180 7.1, Tor VM Research, analysis, and prototyping
181 C . Get a working package out, meaning other people are testing it.
183 7.2, Tor Browser Bundle
184 I - Port to one of OS X or Linux, and start the port to the other.
185 I . Make it the recommended Tor download on Windows
186 I - Make sure it's easy to un-brand TBB in case Firefox asks us to
187 I - Evaluate CCC's Freedom Stick