[or-cvs] finish the "other policy" section

[arma@xxxxxxxx (Roger Dingledine)]

Update of /home2/or/cvsroot/tor/doc/design-paper
In directory moria.mit.edu:/home2/arma/work/onion/cvs/tor/doc/design-paper

Modified Files:
	challenges.tex 
Log Message:
finish the 'other policy' section


Index: challenges.tex
===================================================================
RCS file: /home2/or/cvsroot/tor/doc/design-paper/challenges.tex,v
retrieving revision 1.32
retrieving revision 1.33
diff -u -d -r1.32 -r1.33
--- challenges.tex	1 Feb 2005 23:57:07 -0000	1.32
+++ challenges.tex	3 Feb 2005 06:37:42 -0000	1.33
@@ -33,7 +33,7 @@
 to be practical and usable for protecting TCP streams over the
 Internet~\cite{tor-design}. We have been operating a publicly deployed
 Tor network since October 2003 that has grown to over a hundred volunteer
-nodes and carries on average over 70 megabits of traffic per second.
+nodes and sometimes as much as 80 megabits of average traffic per second.
 
 Tor has a weaker threat model than many anonymity designs in the
 literature, because our foremost goal is to deploy a
@@ -652,34 +652,10 @@
 continued use of identification by IP number as long as there is no
 workable alternative.
 
-
-
-
-\subsection{Other}
-
-[Once you build a generic overlay network, everybody wants to use it.]
-
-Tor's scope: How much should Tor aim to do? Applications that leak
-data: we can say they're not our problem, but they're somebody's problem.
-Also, the more widely deployed Tor becomes, the more people who need a
-deployed overlay network tell us they'd like to use us if only we added
-the following more features. For example, Blossom \cite{blossom} and
-random community wireless projects both want source-routable overlay
-networks for their own purposes. Fortunately, our modular design separates
-routing from node discovery; so we could implement Morphmix in Tor just
-by implementing the Morphmix-specific node discovery and path selection
-pieces. On the other hand, we could easily get distracted building a
-general-purpose overlay library, and we're only a few developers.
-
-[arma will work on this]
-
-%Should we allow revocation of anonymity if a threshold of
-%servers want to?
-
-Logging. Making logs not revealing. A happy coincidence that verbose
-logging is our \#2 performance bottleneck. Is there a way to detect
-modified servers, or to have them volunteer the information that they're
-logging verbosely? Would that actually solve any attacks?
+%Fortunately, our modular design separates
+%routing from node discovery; so we could implement Morphmix in Tor just
+%by implementing the Morphmix-specific node discovery and path selection
+%pieces.
 
 \section{Crossroads: Scaling and Design choices}
 \label{sec:crossroads-design}
@@ -1377,6 +1353,12 @@
 
 will our sustainability approach work? we'll see.
 
+Applications that leak data: we can say they're not our problem, but
+they're somebody's problem.
+The more widely deployed Tor becomes, the more people who need a
+deployed overlay network tell us they'd like to use us if only we added
+the following more features.
+
 "These are difficult and open questions, yet choosing not to solve them
 means leaving most users to a less secure network or no anonymizing
 network at all."