[tor-bugs] #28015 [Applications/Tor Browser]: Brainstorm improved ux for orgs that want to give bridges to their people

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#28015: Brainstorm improved ux for orgs that want to give bridges to their people
------------------------------------------+----------------------
     Reporter:  arma                      |      Owner:  tbb-team
         Type:  defect                    |     Status:  new
     Priority:  Medium                    |  Milestone:
    Component:  Applications/Tor Browser  |    Version:
     Severity:  Normal                    |   Keywords:  ux-team
Actual Points:                            |  Parent ID:
       Points:                            |   Reviewer:
      Sponsor:                            |
------------------------------------------+----------------------
 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]

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/28015>
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