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