From e5fad43ea05e361e61a5d34ae2898f2d46fedd30 Mon Sep 17 00:00:00 2001 From: Karsten Loesing Date: Thu, 29 Mar 2012 09:19:17 +0200 Subject: [PATCH 2/2] Make some minor changes. --- pt_roadmap/roadmap.tex | 20 ++++++++++---------- 1 files changed, 10 insertions(+), 10 deletions(-) diff --git a/pt_roadmap/roadmap.tex b/pt_roadmap/roadmap.tex index 76fa927..45bfefc 100644 --- a/pt_roadmap/roadmap.tex +++ b/pt_roadmap/roadmap.tex @@ -21,8 +21,8 @@ SSL blocking. When we learned that Iran was blocking SSL, we considered it a good opportunity for obfsproxy to have a small beta test. After some -recruiting mailing list posts% -\footnote{\url{http://archives.seul.org/or/talk/Feb-2012/msg00074.html}} +recruiting mailing list posts\footnote{\url{% +https://lists.torproject.org/pipermail/tor-talk/2012-February/023070.html}} we ended up with more than 60 obfsproxy bridges. We looked through all the bridges, and found the fastest and most @@ -32,7 +32,7 @@ obfsproxy and 14 obfuscated bridges baked into it. We called it the https://www.torproject.org/projects/obfsproxy.html.en\#download}} Within 2 days, we had more than 4000 obfsproxy users from Iran -(Fig. \ref{usage.png}). +(Fig.~\ref{usage.png}). \begin{figure} \begin{center} @@ -51,7 +51,7 @@ Even though obfsproxy is currently in use by end-users, it's still a prototype and under heavy development. We have concrete plans for improvements on how obfsproxy works and on -how it integrates with the rest of the tor ecosystem: +how it integrates with the rest of the Tor ecosystem: \subsection{User Interface Improvements} @@ -90,9 +90,9 @@ addresses in the same way as they currently do for normal bridges. This means that Tor bridges will add another field to their extra-info descriptors\footnote{\url{% -https://gitweb.torproject.org/torspec.git/blob/HEAD:/dir-spec.txt#l599}} +https://gitweb.torproject.org/torspec.git/blob/d34f737:/dir-spec.txt#l599}} listing the transports they support. The bridge authorities will pass -those descriptors to BridgeDB, who will then be responsible for +those descriptors to BridgeDB, which will then be responsible for classifying them and distributing them to users. \subsection{Statistics} @@ -120,8 +120,8 @@ each transport, so that we can track the popularity of transport. In the future, we also plan\footnote{\url{ https://trac.torproject.org/projects/tor/ticket/4567}} to extend Tor's NAT punching functionality to obfsproxy. Specifically, -Tor will instruct upnp-helper to forward ports both to Tor's ORPort -but also to obfsproxy's listening port. +Tor will instruct UPnP-helper to forward ports both to Tor's ORPort +but also to obfsproxy's listening port(s). This way, a bridge behind a NAT will be able to offer pluggable transports too. @@ -141,7 +141,7 @@ In the short-term future, new pluggable transports will be deployed by updating obfsproxy on the server side, and by updating the Obfsproxy Browser Bundle on the client side. -When thandy\footnote{\url{% +When Thandy\footnote{\url{% https://trac.torproject.org/projects/tor/wiki/org/roadmaps/Thandy}}, Tor's secure updater, is implemented, it will be used to update the various components of Tor (including pluggable transport proxies), in @@ -190,7 +190,7 @@ https://aur.archlinux.org/packages.php?ID=56555}}. \section{Future} Even though obfsproxy is currently in use by end users, there is still -much work to be done before calling obfsproxy an end product. +much work to be done before calling obfsproxy an end-user product. Apart from implementing the above improvements, we are constantly researching on better pluggable transports and deployment techniques. -- 1.7.5.4