Ken Keys transcribed 3.4K bytes:
On 7/23/2014 10:57 AM, Matt Pagan wrote:
COMMANDs: (combine COMMANDs to specify multiple options simultaneously) get bridges Request vanilla bridges. get transport [TYPE] Request a Pluggable Transport by TYPE. get help Displays this message. get key Get a copy of BridgeDB's public GnuPG key. get ipv6 Request IPv6 bridges.
Currently supported transport TYPEs: obfs2 obfs3 scramblesuit
I'm starting to see usability issues with this interface show up on the help desk. For example, a person who received the above message emailed the help desk asking what to do next. BridgeDB's response is reminiscent of a command line program interface. I personally find this appealing, but remember that bridges are needed by some of our least technical users, many of whom have never even seen a command line before.
I'm wondering if the following message would be any less confusing (Should I put this suggestion on the ticket?):
Hey, <you>!
Please respond to this email with one of the following commands: (You can combine commands to request multiple items simultaneously)
get bridges Requests vanilla bridges. get transport obfs2 Requests obfs2 bridges[*]. get transport obfs3 Requests obfs3 bridges[*]. get transport scramblesuit Requests scramblesuit bridges[*]. get help Displays this message. get key Gets a copy of BridgeDB's public GnuPG key. get ipv6 Requests IPv6 bridges.
BridgeDB can provide bridges with several types of Pluggable Transports[*], which can help obfuscate your connections to the Tor Network, making it more difficult for anyone watching your internet traffic to determine that you are using Tor.
Some bridges with IPv6 addresses are also available, though some Pluggable Transports aren't IPv6 compatible.
Additionally, BridgeDB has plenty of plain-ol'-vanilla bridges - without any Pluggable Transports - which maybe doesn't sound as cool, but they can still help to circumvent internet censorship in many cases.
[*]: You may need to request Pluggable Transport type bridges if Tor is censored for everyone in your country. https://www.torproject.org/docs/pluggable-transports.html
-- <3 BridgeDB ______________________________________________________________________ Public Keys: https://bridges.torproject.org/keys This email was generated with rainbows, unicorns, and sparkles for your@email.com on Sunday, 20 July, 2014 at 16:59:19. _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Are some of our least technical users, many of whom have never even seen a command line before and who may live in Sub-Saharan Africa or one of the Stan countries with only a rudimentary knowledge of English going to understand the difference between vanilla bridges and, say, chocolate almond bridges? Wouldn't it be better to choose terms that at least translate into something resembling what they actually mean?
Noted. What to call bridges without any pluggable transports has been argued about for years, with the result that everyone ended up calling them different things all over the place, which I believe is worse.
Eventually, everyone figured out what "obfsproxy" meant, even if they didn't understand how it worked, nor how to pronounce it. My hope is that a consistent usage of consistently confusing and untranslatable terminology will eventually produce predictable and steadily decreasing levels of user confusion.
Should the interface say "get transport unhuggable", perhaps? The obvious choices were:
1. `get tor bridges` / `get transport tor` This is no good because it could potentially cause users to erroneously think that pluggable transport bridges somehow aren't using tor.
2. `get plain bridges` I think this one is bad because people might assume that this one is somehow plaintext, especially if the string were to be translated.
Do you have a better suggestion for what to call "vanilla bridges"?