commit 58eb425869b34cc76ae2f76e751e160aa6ad229e
Author: Isis Lovecruft <isis(a)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