[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #7522 [BridgeDB]: Design a user interface for redeeming invite tokens (was: Design a user interface for redeeming tokens)

#7522: Design a user interface for redeeming invite tokens
-------------------------+-------------------------------------------------
     Reporter:  aagbsn   |      Owner:
         Type:  task     |     Status:  new
     Priority:  normal   |  Milestone:
    Component:           |    Version:
  BridgeDB               |   Keywords:  bridgedb-socdist, isisExB,
   Resolution:           |  isis2016Q1, bridgedb-ui, tbb-usability
Actual Points:           |  Parent ID:  #7520
       Points:           |
-------------------------+-------------------------------------------------
Changes (by isis):

 * keywords:  bridgedb-socdist, isisExB, isis2015Q3Q4, bridgedb-ui =>
     bridgedb-socdist, isisExB, isis2016Q1, bridgedb-ui, tbb-usability


Comment:

 '''Ignore everything this says about "usernames", "passwords", "human
 memorable", and "email addresses".'''

 The tokens I plan to use currently are the Camenisch-Lysyanskaya anonymous
 credentials as described in [https://eprint.iacr.org/2008/428 this paper
 (ePrint PDF)]:

 Belenkiy, M., Camenisch, J., Chase, M., Kohlweiss, M., Lysyanskaya, A., &
 Shacham, H. (2009).
 Randomizable proofs and delegatable anonymous credentials.
 In ''Advances in Cryptology-CRYPTO 2009'' (pp. 108-125). Springer Berlin
 Heidelberg.

 Which are well-suited to storing server-signed attributes containing
 things like the "good behaviour points" described in
 [https://people.torproject.org/~isis/papers/rBridge:%20User%20Reputation%20based%20Tor%20Bridge%20Distribution%20with%20Privacy%20Preservation.copy%20with%20notes.pdf
 the rBridge paper (PDF)] â a variant of which should be implemented for
 #7520. As these tokens are anonymous, not pseudonymous, it no longer makes
 sense to think about things like "usernames", "passwords", "human
 memorable", and "email addresses".

 However, the general direction of brainstorming the UI for this is still
 useful. In particular, the Tor Browser Team and I have extensively
 discussed adding support for (somehow) inputting a delegated credential
 into a fresh copy of Tor Browser. These credentials are large, as in
 "several kilobytes".


 === Open questions: ===

 1. How do we expect users to actually "invite" their friends? That is, if
 Alice invites Bob, how does the delegated credential get from Alice's
 computer to Bob's computer?

    Is it reasonable to expect users to transfer a file this large or copy-
 paste it?  It contains private key material, so we cannot simply put it
 somewhere in some sort of "download link" (at least not without encrypting
 it and telling Alice to give Bob the key/passphrase).

    '''Case !#1: Bob can use Tor, e.g. via meek''' What if Alice's tor
 client were directed to create an Hidden/Onion Service, and the credential
 was hosted there, and then Alice would only need to give Bob the .onion
 URI (and, optionally, key/passphrase)?

    '''Case !#2: Bob's network connection is censored in some way that even
 meek doesn't work''' In my opinion, we should only fallback to something
 like "Please, Alice, email this file to Bob, who will have to import it
 into his Tor Browser" if Case !#2 is true, or if Alice specifies that she
 wants to put Bob through this particular UX misery.

    '''Case !#3: Bob's network connection is pretty much entirely
 censored''' I don't know what to do here, but I'd ''really'' like to avoid
 solutions (including solutions to the above cases) where the user is
 encouraged/enabled to do something which presents a significant vector for
 malware transfer between Bridge users (e.g. Alice doesn't know what to do,
 so she puts the file containing the credential onto a USB stick and hands
 it to Bob).

 2. What language do we use to describe these actions to users?

 3. Is whatever proposed solution going to work for users of some other
 application (e.g. Ricochet, Orbot, OnionBrowser, etc.)?  We need to
 ensure, at the very least, that the system we design, and the underlying
 exposed APIs, are as much as possible reusable for other projects.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/7522#comment:4>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs