mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-30 23:53:32 +01:00
9e8f8223db
implementation. svn:r17573
188 lines
8.0 KiB
Plaintext
188 lines
8.0 KiB
Plaintext
$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.
|
||
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.
|
||
- 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.
|
||
|