[tor-commits] [bridgedb/master] Update social bridge distributor proposal to include terminology.

isis at torproject.org isis at torproject.org
Tue Feb 4 00:28:48 UTC 2014 

commit 578abc670ad7e9576f9977d78584a2c8779184c0
Author: Isis Lovecruft <isis at torproject.org>
Date:   Tue Oct 22 02:42:18 2013 +0000

    Update social bridge distributor proposal to include terminology.
    
     * ADD beginning of threat model as well.
     * ADD defⁿ table for constants/variable names in
       doc/proposal/XXX-bridgedb-social-distributor.txt.
---
 doc/proposals/XXX-bridgedb-social-distribution.txt |  101 ++++++++++++++++----
 1 file changed, 85 insertions(+), 16 deletions(-)

diff --git a/doc/proposals/XXX-bridgedb-social-distribution.txt b/doc/proposals/XXX-bridgedb-social-distribution.txt
index 199302c..538f6ae 100644
--- a/doc/proposals/XXX-bridgedb-social-distribution.txt
+++ b/doc/proposals/XXX-bridgedb-social-distribution.txt
@@ -16,7 +16,7 @@ Status: Open
    such malicious users and/or censoring entities from joining the pool of
    Tor clients who are able to receive distributed bridges.
 
-*  II. Motivation and 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
@@ -69,9 +69,72 @@ Status: Open
        roughly 1000 bridges in the Email Distributor's pool, distributing 3
        bridges per email response,
 
-*  III. Design
+*  III. Terminology & Notations
+** III.A. Terminology Definitions
+
+   User := A client connecting to BridgeDB in order to obtain bridges.
+
+** III.B. Notations
+
+|--------------------+---------------------------------------------------------------------------------------------|
+| Symbol             | Definition                                                                                  |
+|--------------------+---------------------------------------------------------------------------------------------|
+| U                  | A user connecting to BridgeDB in order to obtain bridges, identified by a User Credential   |
+| D                  | The bridge distributor, i.e. BridgeDB                                                       |
+| Gᵐᵃˣ               | Upper limit (maximum) number of bridge users for a bridge Bᵢ                                |
+| Gˢᵗᵃʳᵗ             | Number of starting users                                                                    |
+| Gᵃᵛᵍ               | Average number of users per bridge                                                          |
+| M                  | Fraction of users which are malicious                                                       |
+| B                  | A bridge                                                                                    |
+| {B₁, …, Bᵢ, …, Bₖ} | The set of bridges assigned and given to user U                                             |
+| k                  | The number of bridges which have been given to user U                                       |
+| Tᵐⁱⁿ               | The minimum time which a bridge must remain reachable                                       |
+| Tᶜᵘʳ               | The current time, given in Unix Era (UE) seconds notation (an integer, seconds since epoch) |
+| Tᵐᵃˣ               | The upper bound on the time for which a user U can earn coins from Bᵢ                       |
+| Ï„áµ¢                 | The time when bridge Báµ¢ was first given to user U                                           |
+| tᵢ                 | The time from when U was first given Bᵢ to either Tᶜᵘʳ or ßᵢ, whichever is greater          |
+| ßᵢ                 | The time when bridge Bᵢ was first considered blocked; if not blocked, ßᵢ = 0                |
+| Ï•                  | Total coins owned by user U                                                                 |
+| φᵢ                 | The coins which user U has earned thus far from bridge Bᵢ                                   |
+| ϱᵢ                 | Rate of earning coins from bridge Bᵢ                                                        |
+| λᵢ                 | The probability that bridge Bᵢ has been blocked                                             |
+| ω                  | The last time that U requested and Invite Ticket from D                                     |
+|--------------------+---------------------------------------------------------------------------------------------|
+
+** III.C. Unicode characters
+
+*  III. 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)
+   identity, the list of bridges given to U, the from BridgeDBBridgeDB is
+
+   In our modifications to the rBridge social bridge distribution scheme,
+   BridgeDB is considered a trusted party, that is to say, BridgeDB is
+   assumed to be honest in all protocols, and no protections are taken to
+   protect clients from malicious behaviour from BridgeDB.
+
+** III.A. Modifications
 
-** III.A. Overview
+   
+
+   Modification: allow BridgeDB to be a malicious actor (protecting against it
+   at this point is too costly, instead we want to eliminate BridgeDB's
+   ability to obtain a social graph for Tor bridge users.)
+
+
+*** 1. BridgeDB is permitted to know the following information:
+
+    
+   
+
+   XXX finishme
+
+
+
+*  IV. Design
+
+** IV.A. Overview
 
    As mentioned, most of this proposal is based upon §IV of the rBridge
    paper, which is the non-privacy preserving portion of the paper. [0] The
@@ -88,15 +151,7 @@ Status: Open
 
    XXX finishme
 
-** III.B. Threat Model
-
-   Modification: allow BridgeDB to be a malicious actor (protecting against it
-   at this point is too costly, instead we want to eliminate BridgeDB's
-   ability to obtain a social graph for Tor bridge users.)
-
-   XXX finishme
-
-** III.C. Data Formats
+** IV.C. Data Formats
 
 *** 1. User Credential 
 
@@ -136,9 +191,9 @@ Status: Open
  
 *** XXX other formats
 
-*  IV. Databases
+*  V. Databases
 
-** IV.A. Scalability Requirements
+** V.A. Scalability Requirements
 
    Databases SHOULD be implemented in a manner which is ammenable to using a
    distributed storage system; this is necessary because certain types of data
@@ -214,6 +269,13 @@ Status: Open
     XXX evaluation on data by calling the sha1 for a serverside Lua script [#]
     [#]: http://redis.io/commands/evalsha
 
+    XXX mediawiki notes and references on switching to redis
+    [#]: https://www.mediawiki.org/wiki/Redis
+
+    XXX using redis as a message queue for job scheduling
+    [#]: http://www.restmq.com/
+
+
 **** 2.a. Data Structures which should be stored in a RDBMS
 
     - User Credentials
@@ -222,9 +284,9 @@ Status: Open
 
     - Spent Credits
 
-*  IV. Open Questions
+*  VI. Open Questions
 
-** IV.A. In which component of the Tor ecosystem should the client application code go?
+** VI.A. In which component of the Tor ecosystem should the client application code go?
 
 *** 1. Should this be done as a Pluggable Transport?
 
@@ -290,3 +352,10 @@ Status: Open
 [6]: https://github.com/andymccurdy/redis-py/
 [7]: http://www.dr-josiah.com/2012/03/why-we-didnt-use-bloom-filter.html
 [8]: http://redis.io/topics/data-types §"Strings"
+
+[#]: Naor, Moni, and Benny Pinkas. "Efficient oblivious transfer protocols."
+       Proceedings of the twelfth annual ACM-SIAM symposium on Discrete algorithms.
+       Society for Industrial and Applied Mathematics, 2001.
+       http://www.wisdom.weizmann.ac.il/%7Enaor/PAPERS/eotp.ps
+       https://gitweb.torproject.org/user/isis/bridgedb.git/tree/refs/heads/feature/7520-social-dist-design:/doc/papers/naor2001efficient.pdf
+

More information about the tor-commits mailing list