[or-cvs] r20248: {projects} update todo-external based on today's discussions (projects/todo)
arma at seul.org
arma at seul.org
Mon Aug 10 01:51:02 UTC 2009
Author: arma
Date: 2009-08-09 21:51:02 -0400 (Sun, 09 Aug 2009)
New Revision: 20248
Modified:
projects/todo/TODO.external
Log:
update todo-external based on today's discussions
Modified: projects/todo/TODO.external
===================================================================
--- projects/todo/TODO.external 2009-08-10 01:49:43 UTC (rev 20247)
+++ projects/todo/TODO.external 2009-08-10 01:51:02 UTC (rev 20248)
@@ -25,13 +25,12 @@
External constraints:
-For June/July:
-NR - Work more on Paul's NRL research problem.
-
For March 22:
I * Email auto-responder
* teach gettor how to ask for (and attach) split files.
- phobos: where are we with this task? When do we need os x split dmgs?
+ phobos: where are we with this task? When do we need os x split dmgs?
+ Andrew: you should put up the split osx dmg's somewhere, and we can
+ put "make them known to users" on the mid-feb list -RD
K o Metrics.
o With Mike's help, use Torflow to start doing monthly rudimentary
@@ -42,6 +41,7 @@
without a lot of details explained, we will continue to put these on the
metrics portal)
d Measure via Broadband and dialup
+ * send chris a pointer to torperf readme so he can run it
o Publish a report addressing key long-term metrics questions:
o What metrics should we present?
o What data are available for these metrics?
@@ -58,38 +58,40 @@
Section 0, items that didn't make it into the original roadmap:
0.1, installers and packaging
-C . i18n for the msi bundle files
-P . more consistent TBB builds
-IC- get a buildbot up again. Have Linux and BSD build machines.
- (Windows would be nice but realistically will come later.)
+C * i18n for the msi bundle files
+P o more consistent TBB builds
+ICE* get a buildbot up again. Have Linux and BSD build machines.
+ (Windows would be nice but realistically will come later.)
E - Get Tor to work properly on the iPhone. [early August]
phobos: progress on iphone port?
3.1, performance work. [Section numbers in here are from performance.pdf]
- High-priority items from performance.pdf
-R - 1.2, new circuit window sizes. make the default package window lower.
+R * 1.2, new circuit window sizes. make the default package window lower.
R+ - 2.1, squeeze loud circuits
- Evaluate the code to see what stats we can keep about circuit use.
- Write proposals for various meddling. Look at the research papers
that Juliusz pointed us to. Ask our systems friends. Plan to put
a lot of the parameters in the consensus, so we can tune it with
short turnaround times.
-E+ - 2.5, Change Vidalia's default exit policy to not click "other
+ - New plan: wait for Chris's thesis.
+E+ X 2.5, Change Vidalia's default exit policy to not click "other
protocols". Or choose not to. Think this through first.
- phobos: what further thought does this need?
+ Answer: doing this is redundant with Mike's BWAuth plan.
R+ - 2.6, Tell users not to file-share.
- Put statement on the Tor front page
- Put statement on the download pages too
- And the FAQ
- 3.1.2, Tor weather
I . Implement time-to-notification (immediate, a day, a week)
+ Status: leave it for September
I - Get a relay operator mailing list going, with a plan and supporting
scripts and so on.
(phobos: what's holding up the operator list? let's create one and
heavily moderate it to keep it on topic. karsten and I discussed some
more, using a human as the moderator could work, or we encourage
everyone to fill out the contact info and validate relay ops with a
-script into majordomo. phobos prefers the human method, karsten slighly
+script into majordomo. phobos prefers the human method, karsten slightly
prefers the script method.)
R - Link to them from the Tor relay page
R - and the torrc.sample?
@@ -108,12 +110,13 @@
all 7 scan? Should only some vote? Extra points if it doesn't
change all the numbers every new consensus, so consensus diffing
is still practical.
- - Get three authorities running the scanners in reality.
+IR - Get three authorities running the scanners in reality.
o 4.5, Older entry guards are overloaded
o Pick a conservative timeout like a month, and implement.
M - 5.2, better timeouts for giving up on circuits/streams
- clients gather data about circuit timeouts, and then abandon
circuits that take more than a std dev above that.
+ Status: Mike will do this after exit scanning
4.1, IOCP / libevent / windows / tor
N - get it working for nick
@@ -121,6 +124,11 @@
N - both the libevent buffer abstraction, and the
tor-uses-libevent-buffer-abstraction. Unless we think that's
unreachable for this milestone?
+ Status: Libevent 2.0.2 came out a few weeks ago. It's a good dev version.
+ Once 2.0.3 is out and there's a Tor alpha in mid Aug that has support
+ for it, we could put out an extra-unstable Tor Windows bundle. Or we
+ might just leave it in the not-quite-finished state for mid-Aug, so we
+ can get microdescriptors going too.
4.2.1, risks from becoming a relay
S - Have a clear plan for how users who become relays will be safe,
@@ -129,18 +137,24 @@
specifically, see "relaying-traffic attacks" in 6.6.
- identify and evaluate ways to make them not a big deal
- setting a low RelayBandwidth
- - Nick Hopper's FC08 paper suggesting that we should do a modified
+ d Nick Hopper's FC08 paper suggesting that we should do a modified
round-robin so we leak less about other circuits
- - instructing clients to disable pings in their firewall, etc
- - pick the promising ones, improve them so they're even better, and
+ d instructing clients to disable pings in their firewall, etc
+ d pick the promising ones, improve them so they're even better, and
spec them out so we know how to build them and how much effort is
involved in building them.
+ * Write a blog post explaining that we're probably screwed either way.
4.5, clients download less directory info
N * deploy proposal 158.
phobos: what's holding up this proposal?
+ Status: we don't have to build consensus flavors until after this. We're
+ going to try to get this done by end of Aug.
N - decide whether to do proposal 140. if so, construct an implementation
plan for how we'll do it. if not, explain why not.
+ Status: there's no C lib for producing and merging diffs. It's hard to
+ write our own good one. Not worth it until we get more intuition from
+ deploying microdescriptors. Doesn't count as low-hanging fruit yet.
5.1, Normalize TLS fingerprint
N o write a draft list of possible attacks for this section, with
@@ -152,7 +166,7 @@
and explain why not.)
5.5, email autoresponder
-I . maintenance and keeping it running
+I o maintenance and keeping it running
5.7.2, metrics
@@ -211,10 +225,23 @@
7.1, Tor VM Research, analysis, and prototyping
C . Get a working package out, meaning other people are testing it.
+ status: tor vm 0.3 will be coming out in august. our next steps should
+ be to put it on the download page, and eventually it will replace the
+ windows vidalia bundle on the easy-download page.
7.2, Tor Browser Bundle
I - Port to one of OS X or Linux, and start the port to the other.
-I . Make it the recommended Tor download on Windows
+I o Make it the recommended Tor download on Windows
I o Make sure it's easy to un-brand TBB in case Firefox asks us to
-I - Evaluate CCC's Freedom Stick
+I o Evaluate CCC's Freedom Stick
+ Status: Freedom stick was just a rebranded TBB. But Torbutton ought
+ to look at Foebud's Privacy Dongle to see how they launch Tor from
+ within Firefox.
+For mid October:
+
+K - submit to Sven's FC workshop
+
+For January:
+RS - Work more on Paul's NRL research problem.
+
More information about the tor-commits
mailing list