[or-cvs] r21438: {projects} fixes as suggested by jo glanville (projects/articles)

[Roger Dingledine <arma@xxxxxxxxxxxxxx>]

Author: arma
Date: 2010-01-18 23:04:36 +0000 (Mon, 18 Jan 2010)
New Revision: 21438

Modified:
   projects/articles/circumvention-features.txt
Log:
fixes as suggested by jo glanville


Modified: projects/articles/circumvention-features.txt
===================================================================
--- projects/articles/circumvention-features.txt	2010-01-18 22:57:21 UTC (rev 21437)
+++ projects/articles/circumvention-features.txt	2010-01-18 23:04:36 UTC (rev 21438)
@@ -9,10 +9,12 @@
 different features and different levels of security, and it's hard for
 users to understand the tradeoffs.
 
-This article lays out ten features or characteristics you should consider
-when evaluating a circumvention tool. The goal is not to advocate for
-any specific tool, but rather to point out what kind of tools are useful
-for what situations.
+This article lays out ten features you should consider when evaluating
+a circumvention tool. The goal isn't to advocate for any specific tool,
+but to point out what kind of tools are useful for different situations.
+In fact, having a diversity of circumvention tools in wide use increases
+robustness for all the tools, since censors have to tackle every strategy
+at once.
 
 One caveat to start out: I'm an inventor and developer of a tool
 called Tor (torproject.org) that is used both for privacy and for
@@ -150,10 +152,10 @@
 small and well-understood as possible. That's why crypto algorithms
 have keys (the secret part) and the rest can be explained in public
 to anybody. Historically, any crypto design that has a lot of secret
-parts has turned out to be broken. Similarly, in the case of secret
-designs for circumvention tools, the only groups examining the tool are
-its original developers and the attackers; the wider user and developer
-community is left out of the loop.
+parts has turned out to be less safe than its designers thought.
+Similarly, in the case of secret designs for circumvention tools,
+the only groups examining the tool are its original developers and the
+attackers; the wider user and developer community is left out of the loop.
 
 This question gets at another form of sustainability: whether the ideas
 from that project are reusable beyond that project's lifetime. Too many
@@ -256,7 +258,11 @@
 
 The ideal answer would be for everybody to use https (also known as
 SSL) when accessing websites, and for all websites to support https
-connections. But for a wide variety of reasons, pervasive encryption
+connections. When used correctly, https provides encryption between your
+web browser and the website. This "end-to-end" encryption means nobody
+on the network (not your ISP, not the backbone Internet providers, and
+not your circumvention provider) can listen in on the contents of your
+communication. But for a wide variety of reasons, pervasive encryption
 hasn't taken off. If the destination website doesn't support encryption,
 the best you can do is 1) not send identifying or sensitive information,
 such as a real name in a blog post or a password you don't want other
@@ -367,15 +373,6 @@
 
 Conclusion
 
-This article explains some of the issues you should consider when
-evaluating the strengths and weaknesses of circumvention tools. I've
-intentionally avoided drawing up a table of different tools and scoring
-them on each category. No doubt somebody will do that eventually and
-sum up how many checkmarks each tool gets, but the point here is not to
-find the "best" tool. No tool is suitable for every situation. In fact,
-having a diversity of circumvention tools in wide use increases robustness
-for all the tools, since censors have to tackle every strategy at once.
-
 Last, we should keep in mind that technology won't solve the whole
 problem. After all, firewalls are <i>socially</i> very successful in these
 countries. As long as many people in censored countries are saying "I'm so