# [or-cvs] r8825: Fill in remaining items I understand in roadmap draft. Now t (in tor/trunk: . doc/design-paper)

nickm at seul.org nickm at seul.org
Wed Oct 25 02:01:31 UTC 2006

Author: nickm
Date: 2006-10-24 22:01:27 -0400 (Tue, 24 Oct 2006)
New Revision: 8825

Modified:
tor/trunk/
Log:
r9382 at Kushana:  nickm | 2006-10-24 22:01:18 -0400
Fill in remaining items I understand in roadmap draft.  Now to print and mess with on paper.

Property changes on: tor/trunk
___________________________________________________________________
svk:merge ticket from /tor/trunk [r9382] on c95137ef-5f19-0410-b913-86e773d04f59

===================================================================
(Binary files differ)

===================================================================
--- tor/trunk/doc/design-paper/roadmap-2007.tex	2006-10-25 01:25:17 UTC (rev 8824)
+++ tor/trunk/doc/design-paper/roadmap-2007.tex	2006-10-25 02:01:27 UTC (rev 8825)
@@ -130,9 +130,16 @@
they are to be deployed in 2008.

\subsubsection{Relay incentives}
+To support more users on the network, we need to get more servers.  So far,
+we've relied on volunteerism to attract server operators, and so far it's
+served us well.  But in the long run, we need to {\bf design incentices for
+  users to run servers} and relay traffic for others.  Most obviously, we
+could try to build the network so that servers offered improved service for
+other servers, but we would need to do so without weakening anonymity and
+making it obvious which connections originate from users running servers.  We
+have some preliminary designs here~\cite{challenges}, but need to perform
+some more research to make sure they would be safe and effective.

-\tmp{We need incentives to relay.}
-
\subsection{Portability}
Our {\bf Windows implementation}, though much improved, continues to lag
behind Unix and Mac OS X, especially when running as a server.  We hope to
@@ -426,11 +433,19 @@
major packages within an hour or so of source release.

\subsection{Improved metrics}
-\tmp{We'd like to know how the network is doing.}
+We need a way to {\bf measure the network's health, capacity, and degree of
+  utilization}.  Our current means for doing this are ad hoc and not
+completely accurate.

-\tmp{We'd like to know where users are in an even less intrusive way.}
+We need better ways to {\bf tell which countries are users are coming from,
+  and how many there are}.  A good perspective of the network helps us
+allocate resources and identify trouble spots, but our current approaches
+will work less and less well as we make it harder for adversaries to
+enumerate users.  We'll probably want to shift to a smarter, statistical
+approach rather than our current count and extrapolate'' method.

-\tmp{We'd like to know how much of the network is getting used.}
+% \tmp{We'd like to know how much of the network is getting used.}
+% I think this is covered above -NM

\subsection{Controller library}
We've done lots of design and development on our controller interface, which
@@ -460,20 +475,27 @@

\subsection{All-in-one bundle}
-\tmp{a.k.a Torpedo'', but rename this.}
+We need a well-tested, well-documented bundle of Tor and supporting
+applications configured to use it correctly.  We have an intial
+implementation well under way, but it will need additional work in
+identifying requisite Firefox extensions, identifying security threats,
+improving user experience, and so on.  This will need significantly more work
+before it's ready for a general public release.

\subsection{LiveCD Tor}
-\tmp{a.k.a anonym.os done right}
+We need a nice bootable livecd containing a minimal OS and a few applications
+configured to use it correctly.  The Anonym.OS project demonstrated that this
+is quite feasible, but their project is not currently maintained.

\subsection{A Tor client in a VM}
\tmp{a.k.a JanusVM} which is quite related to the firewall-level deployment
-section below
+section below .  Roger, can you write this?

-\subsection{Interface improvements}
-\tmp{Allow controllers to manipulate server status.}
+%\subsection{Interface improvements}
+%\tmp{Allow controllers to manipulate server status.}
% (Why is this in the User Experience section?) -RD
+% I think it's better left to a generic make controller iface bettter'' item.

-
\subsection{Firewall-level deployment}
Another useful deployment mode for some users is using {\bf Tor in a firewall
configuration}, and directing all their traffic through Tor.  This can be a
@@ -488,13 +510,22 @@
targetted at specialized home routing hardware, could be useful.

\subsection{Assess software and configurations for anonymity risks}
+Right now, users and packagers are more or less on their own when selecting
+firefox extensions.  We should {\bf assemble a recommended list of browser
+  extensions} through experiment, and include this in the application bundles
+we distribute.

-\tmp{which firefox extensions to use, and which to avoid. best practices for
-how to torify each class of application.}
+We should also describe {\bf best practices for using Tor with each class of
+  application}.  \tmp{Roger, say more}

-\tmp{clean up our own bundled software:
-E.g. Merge the good features of Foxtor into Torbutton}
+The Foxtor and Torbutton extensions serve similar purposes; we should pick a
+favorite, and merge in the useful features of the other.

+%\tmp{clean up our own bundled software:
+%E.g. Merge the good features of Foxtor into Torbutton}
+%
+% What else did you have in mind? -NM
+
\subsection{Localization}
Right now, most of our user-facing code is internationalized.  We need to
internationalize the last few hold-outs (like the Tor installer), and get
@@ -513,7 +544,8 @@
\section{Support}

\tmp{would be nice to set up some actual user support infrastructure, especially
-focusing on server operators and on coordinating volunteers.}
+focusing on server operators and on coordinating volunteers.} Roger, can you
+write this ?  I don't know what user support infrastructure'' is.

\section{Documentation}
@@ -542,7 +574,11 @@

\subsection{Missing user documentation}

-\tmp{Discoursive and comprehensive docs}
+Our documentation falls into two broad categories: some is discoursive' and
+explains in detail why users should take certain actions, and other
+documenation is comprehensive' and describes all of Tor's features.  Right
+now, we have no document that is both deep, readable, and thorough.  We
+should correct this by identifying missing spots in our design.

\bibliographystyle{plain} \bibliography{tor-design}