commit 58eb425869b34cc76ae2f76e751e160aa6ad229e Author: Isis Lovecruft <isis@torproject.org> Date: Wed Oct 23 11:55:28 2013 +0000 Fix alignment of topic headers in XXX-bdb-soc-dist. --- doc/proposals/XXX-bridgedb-social-distribution.txt | 18 ++++++++---------- 1 file changed, 8 insertions(+), 10 deletions(-) diff --git a/doc/proposals/XXX-bridgedb-social-distribution.txt b/doc/proposals/XXX-bridgedb-social-distribution.txt index 5f44fcf..7274132 100644 --- a/doc/proposals/XXX-bridgedb-social-distribution.txt +++ b/doc/proposals/XXX-bridgedb-social-distribution.txt @@ -8,7 +8,7 @@ Related Proposals: 199-bridgefinder-integration.txt XXX-bridgedb-database-improvements.txt Status: Draft -* I. Overview +* I. Overview This proposal specifies a system for social distribution of the centrally-stored bridges within BridgeDB. It is primarily based upon Part @@ -18,7 +18,7 @@ Status: Draft such malicious users and/or censoring entities from joining the pool of Tor clients who are able to receive distributed bridges. -* II. Motivation & Problem Scope +* II. Motivation & Problem Scope As it currently stands, Tor bridges which are stored within BridgeDB may be freely requested by any entity at nearly any time. While the openness, that @@ -35,7 +35,7 @@ Status: Draft can be even more in need of the identity protections and free speech enablement which Tor can provide, given their political contexts. -** II.A. Current Tor bridge distribution mechanisms and known pitfalls: +** II.A. Current Tor bridge distribution mechanisms and known pitfalls: *** 1. HTTP(S) Distributor @@ -71,7 +71,7 @@ Status: Draft roughly 1000 bridges in the Email Distributor's pool, distributing 3 bridges per email response, -* III. Terminology & Notations +* III. Terminology & Notations ** III.A. Terminology Definitions User := A client connecting to BridgeDB in order to obtain bridges. @@ -103,9 +103,7 @@ Status: Draft | ω | The last time that U requested and Invite Ticket from D | |--------------------+---------------------------------------------------------------------------------------------| -** III.C. Unicode characters - -* III. Threat Model +* IV. Threat Model In the original rBridge scheme, there are two separate proposals: the first does not make any attempt to hide information such as the user's (U) @@ -294,7 +292,7 @@ Status: Draft Considerations: -**** a. It doesn't need to modify the user's application-level traffic +**** 1a. It doesn't need to modify the user's application-level traffic The clientside will eventually need to be able to build a circuit to the BridgeDB backend, but it is not necessary that the clientside handle @@ -311,7 +309,7 @@ Status: Draft must be present before tor is started; tor will not reload these settings via SIGHUP. -**** c. TorLaucher is not the correct place for this functionality. +**** 1c. TorLaucher is not the correct place for this functionality. I am *not* adding this to TorLauncher. The clientside of rBridge will eventually need to handle a lot of complicated new cryptographic @@ -329,7 +327,7 @@ Status: Draft and then either launches tor (if the user wants to use an installed tor binary) or launches TorLauncher if we're running TBB. -**** d. Little-t tor is not the correct place for this either. +**** 1d. Little-t tor is not the correct place for this either. It might be possible, instead of (b) or (c), to add this to little-t tor. However, I feel like the bridge distribution problem is a