Opened 7 years ago

Closed 2 years ago

#7522 closed task (fixed)

Design a user interface for redeeming invite tokens

Reported by: aagbsn Owned by: isis
Priority: Medium Milestone:
Component: Circumvention/BridgeDB Version:
Severity: Normal Keywords: bridgedb-socdist, isisExB, isis2016Q1, bridgedb-ui, tbb-usability
Cc: gk Actual Points:
Parent ID: #7520 Points:
Reviewer: Sponsor:

Description (last modified by isis)

Please see comment #4 on this ticket for a better description of the scope of this ticket. The following description is kept for historical purposes, and is no longer relevant due to developments in the design of #7520. —isis



Original Description

Should this interface be web based? Email based with gpg support? Both?

Should a token be redeemed for an account, or be used each time to request a bridge?

If a token is exchanged for an account, BridgeDB would need to store account credentials provided by a user. That might be more convenient for a user to remember, but might lead to problems such as:

account names can be probed (i.e. does an account by a certain name already exist?)
users might re-use nyms, potentially a liability.

On the other hand, an account might be identified by an email address, which could be used to periodically send new bridges or invites. We want to add email subscription support to BridgeDB (#1610), and perhaps these features should overlap.

Perhaps we could support both modes, where a valid token can be used to request bridges and add/remove email addresses. If a user chooses to add an email address, a suitable warning would be displayed to advise the user that the email address will be stored on the system.

Child Tickets

Change History (9)

comment:1 Changed 5 years ago by isis

Keywords: bridgedb-socdist added

comment:2 Changed 5 years ago by isis

Keywords: isisExB isis2015Q3Q4 added

comment:3 Changed 5 years ago by isis

Keywords: bridgedb-ui added

comment:4 Changed 4 years ago by isis

Keywords: isis2016Q1 tbb-usability added; isis2015Q3Q4 removed
Summary: Design a user interface for redeeming tokensDesign a user interface for redeeming invite tokens

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 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 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).

  1. What language do we use to describe these actions to users?
  1. 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.

comment:5 Changed 4 years ago by isis

Owner: set to isis
Status: newassigned

comment:6 Changed 4 years ago by isis

Description: modified (diff)
Status: assignednew

comment:7 Changed 4 years ago by gk

Cc: gk added

comment:8 in reply to:  4 Changed 4 years ago by yawning

Replying to isis:

  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).

Bob generates a Curve25519 keypair and conveys it to Alice. Alice encrypts the invite with said keypair (NaCl's crypto_box suggests itself). It sort of is a UI/UX disaster in that Bob needs to convey 32 bytes to Alice, but past that it allows the invite to be posted wherever, in a large number of formats (Under the assumption that if Curve25519 is broken, so is Tor in it's current state anyway).

comment:9 Changed 2 years ago by isis

Resolution: fixed
Severity: Normal
Status: newclosed

Please see the Hyphae paper that Henry de Valence and I wrote, specifically §4 and §6.1, for the current design.

Note: See TracTickets for help on using tickets.