[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-bugs] #28015 [Applications/Tor Browser]: Brainstorm improved ux for orgs that want to give bridges to their people
#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