Make bridges.torproject.org more user friendly

Users who visit bridges.torproject.org to get obfsproxy bridges are required to specify the transport by name to get a set of IP address. Most users only know these addresses as "bridges", and will not be familiar with terms such as "obfs2" and "obfs3". It would also be great if the page was updated to clearly separate the normal-bridges-page from the obfs2-bridges-page.

added bridgedb-0.0.1 component::circumvention/bridgedb owner::isis parent::7319 priority::medium resolution::fixed status::closed type::enhancement labels

Trac:
Parent: N/A to #7319 (moved)

An idea here would be to have obfsbundles output some kind of unique identifier (maybe even the filename), which when inserted into bridgedb gives you some obfsbridges appropriate for your bundle.

So for example, if you gave the identifier of the first bundles we released, bridgedb would give you only obfs2 bridges. If you gave the identifier of the latest pyobfs/flashproxy bundles, bridgedb would give you both obfs2 and obfs3 bridges.

This way, users won't need to learn any transport names whatsoever. The drawback is that we have to keep bridgedb updated for every new obfsbundle.

The mirror image of this idea is for bridges.tp.o to annotate really-new-transport-types with a note about how you'll need version such-and-such of the circumvention bundle to use this bridge.

Replying to arma:

The mirror image of this idea is for bridges.tp.o to annotate really-new-transport-types with a note about how you'll need version such-and-such of the circumvention bundle to use this bridge.

Aha. Both of these ideas are compatible, and can probably be implemented with the same BridgeDB config (which will include stuff like bundle names, versions, release dates and supported transports). I'm not sure which approach is better, and I can imagine use cases that can benefit from both approaches.

Also, the new BridgeDB interface should contain links to all the obfsbundles (especially for really-new-transport-types), links to pluggable transport documentation, pointers to help@rt.torproject.org, etc. Sounds like a non-trivial project but very worth doing.

Feedback from Runa would probably be very helpful regarding bridgedb support and translation.

Most people seem to recognize the string "Obfsproxy" at this point, so I think we should make nice big buttons/links for each transport type that is in use (and perhaps remove the query box).

P.S. I mentioned to asn on IRC my TorCheck project on https://github.com/aagbsn/TorCheck.git It's a web service built on twisted with templating and i18 internationalization, so it might be worth a look, particularly the translation stuff.

Thanks again!

Trac:
Cc: N/A to runa

Here's a html mockup from asn's outline + text - https://people.torproject.org/~gsathya/html/layout.html

Trac:
Status: new to needs_information

Looks pretty clean! Have you thought about replacing the "Click here" links with some sort of badges or buttons?

Have you considered where the version strings will come from? Will the bridgedb page need to be updated every release?

Replying to aagbsn:

Looks pretty clean! Have you thought about replacing the "Click here" links with some sort of badges or buttons?

Interesting. I will think more about this. But this can be changed later even. (not a blocker)

Have you considered where the version strings will come from? Will the bridgedb page need to be updated every release?

asn?

You might also want to add tbb download links and a description of the gettor email service. And, all of this information should get added to the email distributor as well. (email bridges@torproject.org for a current idea of what it looks like).

I also have plans to make the email distributor more interactive, but that's a separate ticket.

Replying to aagbsn:

You might also want to add tbb download links

Hmm. I thought bridgedb would be mostly for people who have already downloaded TBB. But I guess it would make sense to point the normal TBB users to Obfs-TBB download links.(Although I don't want to show too much information and confuse them).

and a description of the gettor email service.

Yeah, see "I need an alternative way of getting bridges!" in my mockup

Moar pages- https://people.torproject.org/~gsathya/html/captcha.html https://people.torproject.org/~gsathya/html/bridges.html

You'll probably want to look at the Raptcha.py, which wraps recaptcha so that clients of bridges.tpo do not make a connection to recaptcha directly (we don't use their javascript, and proxy all of the recaptcha api submissions), ideally we don't show a captcha until the visitor selects the type of bridge that they need (currently, bridgedb asks for a captcha whenever someone visits bridges.tpo, and asks for the user to solve another captcha if they request a different type of bridge)

Ok, so we successfully deployed gsathya's new design (and it looks awesome!). Now we have some followup tickets #9127 (moved), #9156 (moved), #9157 (moved). #8616 (moved) is still in progress.

Users can (mostly easily) request transports from both the email responder and the web interface now. (Thanks gsathya!)

Trac:
Owner: aagbsn to isis
Keywords: N/A deleted, bridgedb-0.0.1 added
Status: needs_information to assigned
Cc: runa to runa, isis

This ticket is very general, without clear address of problems or specific ideas for solutions, and I am inclined to close it. (Basically I'm imagining being a new volunteer, wanting to help, finding all these vague tickets, and then getting confused and unsure of where to help.)

Feel free to reopen with clarification if you feel this ticket hasn't been finished.

Trac:
Status: assigned to closed
Resolution: N/A to fixed

closed

mentioned in issue #7520 (moved)

mentioned in issue #7547 (moved)

mentioned in issue #8616 (moved)

mentioned in issue #8705 (moved)

mentioned in issue #10833 (closed)

moved to tpo/anti-censorship/bridgedb#7296 (closed)