commit 37c8237aafdb416507be0eeb8638ec0c9f01e5a4 Author: Roger Dingledine arma@torproject.org Date: Tue Jun 12 06:32:01 2012 -0400

add in a point that rransom and i independently came up with --- proposals/188-bridge-guards.txt | 8 +++++++- 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/proposals/188-bridge-guards.txt b/proposals/188-bridge-guards.txt index 3c53cfb..5a5a005 100644 --- a/proposals/188-bridge-guards.txt +++ b/proposals/188-bridge-guards.txt @@ -32,7 +32,7 @@ Status: Open same way clients do. This has been a known attack since early versions {XXXX check} of the design document; let's try to fix it.

-2.1. Related ideas: Guard nodes +2.1. Related idea: Guard nodes

The idea of guard nodes isn't new: since 0.1.1, Tor has used guard nodes (first designed as "Helper" nodes by Wright et al in {XXXX}) @@ -203,6 +203,12 @@ Status: Open from learning that we're a bridge... but another set of nodes will learn that anyway, so it's not clear what we'd gain.

+ One good reason to keep separate guard lists is to prevent the + *client* of the bridge from being able to enumerate the guards that + the bridge uses to protect its own traffic (by extending a circuit + through the bridge to a node it controls, and finding out where the + extend request arrives from). + 5. Other considerations

What fraction of our traffic is bridge traffic? Will this alter