Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
Trac
Trac
  • Project overview
    • Project overview
    • Details
    • Activity
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Operations
    • Operations
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Create a new issue
  • Issue Boards

GitLab is used only for code review, issue tracking and project management. Canonical locations for source code are still https://gitweb.torproject.org/ https://git.torproject.org/ and git-rw.torproject.org.

  • Legacy
  • TracTrac
  • Issues
  • #28015

Closed (moved)
Open
Opened Oct 12, 2018 by Roger Dingledine@arma

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

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]

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: legacy/trac#28015