Edits to recent edits.

svn:r739

doc/tor-design.tex

@@ -401,12 +401,10 @@ it is a security requirement \cite{econymics,back01}. Tor should
 therefore not
 require modifying applications; should not introduce prohibitive delays;
 and should require the user to make as few configuration decisions
-as possible.
-Platform support is also an important factor in both usability and
-deployability. Tor currently runs on linux, Windows, and assorted
-BSDs (including MacOS X).
-%XXX Did I forget any? We need to say this somewhere. It's a big deal
-%XXX so should it instead be at the beginning and/or end? -PS
+as possible.  Finally, Tor should be easily implemented on all commonly used
+platforms; we cannot require users to change their operating system in order
+to be anonymous.  (The current Tor implementation runs on Windows and
+assorted Unix-clones including Linux, FreeBSD, and MacOS X.)
 
 \textbf{Flexibility:} The protocol must be flexible and well-specified,
 so that it can serve as a test-bed for future research in low-latency
@@ -633,7 +631,7 @@ seven bytes, plus one byte for the command.
 
 %XXXX Discuss what happens with circIDs here.
 
-A User's OP constructs a circuit incrementally, negotiating a
+A user's OP constructs a circuit incrementally, negotiating a
 symmetric key with each OR on the circuit, one hop at a time. To begin
 creating a new circuit, the OP (call her Alice) sends a
 \emph{create} cell to the first node in her chosen path. This cell's
@@ -1344,15 +1342,16 @@ design withstands them.
   end-to-end timing correlations. An attacker watching patterns of
   traffic at the initiator and the responder will be
   able to confirm the correspondence with high probability. The
-  greatest protection currently against such confirmation is to hide
+  greatest protection currently available against such confirmation is to hide
   the connection between the onion proxy and the first Tor node,
-  either because it is local or behind a firewall.  This approach
+  by running the onion proxy locally or 
+  behind a firewall.  This approach
   requires an observer to separate traffic originating at the onion
-  router from traffic passes through it; but because we do not mix
+  router from traffic passing through it; but because we do not mix
   or pad, this does not provide much defense.
   
 \item \emph{End-to-end Size correlation.} Simple packet counting
-  without timing consideration will also be effective in confirming
+  without timing correlation will also be effective in confirming
   endpoints of a stream. However, even without padding, we have some
   limited protection: the leaky pipe topology means different numbers
   of packets may enter one end of a circuit than exit at the other.
@@ -1841,6 +1840,7 @@ issues remaining to be ironed out. In particular:
   cached at the ORs to avoid high loads on the directory servers.
 % XXX this is a design paper, not an implementation paper. the design
 %     says that they're already cached at the ORs. Agree/disagree?
+% XXX Agree. -NM
 \item \emph{Implementing location-hidden servers:} While
   Section~\ref{sec:rendezvous} describes a design for rendezvous
   points and location-hidden servers, these feature has not yet been