nihilist/tor
1
0
Fork 0
mirror of https://gitlab.torproject.org/tpo/core/tor.git synced 2024-11-10 13:13:44 +01:00
Code Issues Packages Projects Releases Wiki Activity

finish the 'other policy' section

Browse Source 
svn:r3505
This commit is contained in:
Roger Dingledine 2005-02-03 06:37:42 +00:00
parent 0133411df9
commit 0dc14b3b7d
1 changed files with 11 additions and 29 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

40
doc/design-paper/challenges.tex
View File

@ -33,7 +33,7 @@ Tor is a low-latency anonymous communication overlay network designed
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 @@ and incentive schemes \cite{price-privacy}. Similarly we can expect a
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 @@ conclusion.
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."