Opened 3 months ago

Last modified 4 weeks ago

#28015 new defect

Brainstorm improved ux for orgs that want to give bridges to their people

Reported by: arma Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: ux-team, education, documentation
Cc: ahf, mcs, brade Actual Points:
Parent ID: Points:
Reviewer: Sponsor: Sponsor19

Description

We have the new moat feature in Tor Browser, which provide a usable way for people in censored areas to fetch bridges from bridgedb. Great.

There's another bridge distribution model though, where an org runs bridges for its own people, and wants to get its custom bridge addresses into their people's tor browsers easily. Like, picture a human rights org wanting to help its own users in a given country.

I can imagine two ways that users might get these bridges with our current software:

(1) via email, and then manually clicking a bunch of things in Tor Browser and pasting the bridges into the right place.

(2) Getting a pre-populated Tor Browser from their org.

The first one is not great from a usability perspective, and the second one is not great from a "we taught them how to check the signatures but now their Tor Browser differs from the one we signed" perspective.

Is there a way in Tor Browser to help improve the usability flow for this goal?

One idea would be to essentially have a cheat code in our moat interface, where if you type in a secret password instead of the captcha solution, you get some secret bridges. We would still be "in the middle" in this scenario.

Another idea would be to make it easy for other orgs to run their own moat, and then add an interface option in Tor Browser to add your own moat url. We probably want some sort of authentication (so the domain name itself doesn't have to stay a secret), and maybe that's done by having a url with both a (fine if the adversary learns it) domain and a (should stay secret) path component.

Maybe there is some brilliant third idea?

We also want to ponder usability for mobile users, e.g. in the world where they get and scan a QR code.

[Ticket created based on discussions in https://trac.torproject.org/projects/tor/wiki/org/meetings/2018MexicoCity/Notes/BridgeDB]

Child Tickets

Change History (6)

comment:1 Changed 3 months ago by arma

Keywords: sponsor19 added

comment:2 Changed 3 months ago by gk

Cc: mcs brade added

comment:3 Changed 3 months ago by tom

Your ideas were the first that came to my mind. I wracked my brain for a little bit trying to come up with additional ones.

Ideas of varying quality:

Instead of 'via email, and then manually clicking a bunch of things in Tor Browser and pasting the bridges into the right place' - make this a supported flow where on copy/pastes a big blob of base64 and Tor Browser decodes and parses it and does all the right things.

Orgs distribute a symmetric key that decrypts an encrypted blob baked into the browser. This contains some or all of: a passphrase used to get secret bridges from our moat, the location of their moat, or even new default bridges. (This could be used by Tor Projects direct user support to test connection failures also, by having a few of our own secret bridges)

Org distributes an 'add-on pack' (but not a browser add-on in that sense, just the generic definition of 'supplemental') that one installs on top of tor browser that contains *something*. A new moat url, new default bridges, etc. The 'add-on pack' might be as simple as a specially named json file Tor Browser looks for in its startup process. You could even encrypt it by default with a passphrase Tor browser prompts you for on startup if you really wanted to?

Orgs could distribute a true browser add-on one installs over Tor Browser that alter's Tor Browser's behavior in the same sense of a Mozilla Partner Repack (as we call them): it could supply bridge info, but also theme the browser, add a default homepage, bookmarks, even add-ons. (Or maybe not add-ons :) ) I think Psiphon did this as a funding mechanism also.

Tangential: a 'secret passphrase with a public moat URL' approach could also have two other authentication mechanisms besides a high-entropy passphrase: a TOTP based token o a WebAuth/FIDO USB Key.

comment:4 Changed 3 months ago by pili

Sponsor: Sponsor19

comment:5 Changed 2 months ago by arma

Nathan tells me that in Orbot-land, Orbot hooks the "bridge://" url, so you can get a bridge address in your email or signal or instant messaging or web page or whatever, and click on it, and Orbot will intercept the click and populate your bridge configuration for you.

It's not immediately clear how to make use of this idea on Tor Browser Desktop, but it's another data point to consider (and it opens up a lot of new options on Android).

comment:6 Changed 4 weeks ago by gaba

Keywords: education documentation added; sponsor19 removed
Note: See TracTickets for help on using tickets.