Opened 5 years ago

Closed 17 months ago

#11343 closed defect (wontfix)

TorLauncher's UI should warn users when a bridge fingerprint appears to be incomplete

Reported by: isis Owned by: brade
Priority: Medium Milestone:
Component: Applications/Tor Launcher Version:
Severity: Normal Keywords: bridgedb
Cc: isis, alster@…, mcs Actual Points:
Parent ID: #11180 Points:
Reviewer: Sponsor:

Description

A Tails user reported some trouble using the new Tails (version 0.23) which includes TorLauncher. They were entering a bridge line, and were confused why it was not working. After some troubleshooting, we determined that they had only entered 27 (out of 40) of the characters of the bridge's fingerprint.

Perhaps it would help users to have some sort of feedback on this?

The simplest would be: when they hit "OK", to take them back and display a message saying "Oops! It looks like you were trying to enter a bridge fingerprint. Bridge fingerprints are 40 characters long, and you only have 27!"

More complicated: while they are typing the fingerprint, display a dynamic message which counts down the number of characters missing.

For posterity, here is the conversation from #tails:

00:55  alster ) i'm just trying to run tails for the first time actually, with
                a bridges setup, but having trouble to get past the point where
                i need to type the bridges.
00:56  alster ) but the error message actually sounds like i may have a typo
00:56  alster ) [warn] key digest for bridge is wrong
00:57  velope ) hmm, are you entering a fingerprint for the bridge? don't.
00:57  alster ) [warn] controller gave us config lines that didn't validate:
                Bridge line did not parse. See logs for details.
00:58  alster ) the lines i got in the box look like this:
00:58  alster ) bridge obfs3 <IPv4> <HASH>
00:59  alster ) i guess the HASH is the fingerprint you're referring to?
00:59    isis ) yes, HASH is the fingerprint
00:59  alster ) actually that's
00:59  alster ) bridge obfs3 <IPv4:PORT> <HASH>
00:59    isis ) that should be correct
01:00  alster ) so what i should be using is this instead?
01:00  alster ) bridge obfs3 <IPv4:PORT>
01:00  alster ) correct?
01:00    isis ) i am not sure, i have not tried the new tails yet, but you really want the fingerprint in there, otherwise you could be trivially man-in-the-middled
01:01    isis ) so if tails is not handing the fingerprint correctly, that is a
                serious bug
01:01  alster ) maybe i don't want the leading "bridge"? since bridges.torproject.org does not output this
01:02    isis ) well, i write the code for bridges.tpo
01:02  alster ) well i entered the data manually, so chances are i just
                misspelled it
01:02    isis ) and the only reason we stopped putting the 'bridge ' at the
                beginning was because vidalia is idiotic and didn't handle it
                correctly
01:03    isis ) torlauncher explicitly has code to handle lines which either start
                with 'bridge ', or with the transport method, or with the IP:PORT
01:03  alster ) i assume the fingerprints should be the exact same # of characters
                always, right?
01:03    isis ) yes, always 40 chars
01:04    isis ) though? perhaps? is your bridge's fingerprint all uppercase or
                all lowercase?
01:04  alster ) all lowercase
01:04    isis ) bridges.torproject.org currently returns lowercase
01:05  alster ) i just checked, https://bridges.torproject.org gave me 2
                fingerprints with 40 characters each
01:05  alster ) but one of those i typed has 29 only
01:05  alster ) so it's my fault
01:05    isis ) ah, okay, that make sense :)
01:06    isis ) but perhaps torlauncher should be a bit smarter and tell you
                that that was the problem
01:06    arma ) isis: you could be man-in-the-middled for your first hop, but
                not your second or third. and if they're in a position to
                man-in-the-middle your first hop, they're in a position to
                do traffic analysis on it. so either way you'd best hope
                they're not watching the other end too. and if they are, it
                doesn't matter that they can mitm the first end.
01:06    isis ) arma: yes, true
01:07    arma ) that's why i was fine giving out bridges without fingerprints
01:07    arma ) it seems there's been a big push lately to switch to "you must
                have a fingerprint"
01:07    arma ) which seems to really harm usability
01:07    isis ) arma: though mitm'ing the first hop opens the grounds for more
                attacks than just analysis, like the replay attack and xor'ing
                in tags into the encrypted streams
01:08    isis ) arma: but this is the first i've heard of a usability issue
                with the fingerprints, is this normal? there are lots of these
                problems?
01:08  alster ) this GUI definitely needs something like "okay, you entered 27
                characters so far, 13 more to go."
01:09  alster ) also, the lines you enter there do currently wrap
01:09  alster ) (making it hard to read)
01:09    isis ) yes, i agree, it definitely should tell you that something was
                amok
01:09    arma ) isis: anybody who tries to manually copy a bridge line will
                basically fail if it's more than an ip and a port and maybe a
                few more characters
01:10    isis ) arma: i can give them a QR code with two lines of python,
                would that help?
01:10    arma ) but also, good point, they can get in past the tls if they can
                mitm the bridge. which is meaningful.
01:11    arma ) would the qr code help this tails person? probably not. would it
                help an orbot person? maybe.
01:11  alster ) presenting the fingerprint in a user friendly way (and having a
                user freindly input on the other end) would help
01:12  alster ) so think of images of fruits or whatever
01:12    isis ) should there be a "Wat? You expect me to type that in? Give me
                a QR code!" button on BridgeDB when you get bridges?
01:13  velope ) the GUI could be better, but for most people anything involving
                long meaningless strings is massive fail
01:13    isis ) hmm, the images of fruits thing becomes much harder to do, i
                think, because it would need to be something that the bridge
                puts in their descriptor (so that your tor could check it when
                you try to connect to the bridge)
01:14    isis ) hmm. i will need to think about this more.
01:14  velope ) "needs proposal"
01:15    isis ) though torlauncher should also be okay if there is no
                fingerprint at all
01:15  velope ) it is

Child Tickets

Attachments (1)

torlauncher_ui_mockup_bridges.png (59.5 KB) - added by cypherpunks 5 years ago.
Mockup of suggested Tor Launcher bridge address input screen

Download all attachments as: .zip

Change History (11)

comment:1 Changed 5 years ago by isis

Cc: alster@… added; alstar@… removed

comment:2 Changed 5 years ago by arma

Hm. The flip side here is that we don't want Tor Launcher to be enforcing syntax on the bridge lines -- if we do that then we need to change Tor Launcher every time we start using some other piece of the bridge line syntax. Remember how Tor Launcher in the past was refusing to accept obfs2 bridges because surely you made a mistake by putting the string "obfs2" where you just did?

Changed 5 years ago by cypherpunks

Mockup of suggested Tor Launcher bridge address input screen

comment:3 Changed 5 years ago by cypherpunks

So you lack a solution which helps the user enter the bridge information in proper format. But you also need a way to override this and accept any input even if Tor Launcher doesn't think the user input would be properly formatted since this format can change any time. So, from a user perspective, this would be a good way to do this:

Mockup of suggested Tor Launcher bridge address input screen

-- alster

comment:4 Changed 5 years ago by mcs

Cc: mcs added

The Tor Launcher bridges UI was designed with the idea that most users would copy/paste bridge configuration info. Do we think most people would prefer to enter the various pieces separately?

I just tried entering an obfs3 bridge line in Tor Launcher that was missing part of the fingerprint. An error alert is immediately displayed:

Unable to save Tor settings.

Unacceptable option value: Bridge line did not parse. See logs for details.

Tor Launcher's "Copy Tor Log To Clipboard" button is highlighted with a caution icon. The last two lines of the tor log are:

[WARN] Key digest for Bridge is wrong length. 
[WARN] Controller gave us config lines that didn't validate: Bridge line did not
       parse. See logs for details. 

The second to last log message clearly indicates what the problem is, assuming you know what a "key digest" is.

comment:5 Changed 5 years ago by cypherpunks

When making a decision as to whether most or some Tor Launcher bridges UI users may prefer (be able) to copy/paste bridge configuration info, please keep in mind that there are scenarios, such as with Tails, where the user is not online, and does not have any means to copy / paste this information from anywhere, but just has to enter it manually.

Please also keep in mind that the average user does not understand "does not parse", "key digest" nor "controller gave us config lines that didn't validate", and is not necessarily aware that scrolling to the very end of a lengthy log can be necessary to understand the cause of an error (nor may she be used to and comfortable with looking at and trying to interpret log files at all).

It is nice to see that much effort has been put into making things somewhat accessible while still remaining forward compatible - but my personal view is that the current interface is just not good enough for the average, non technical user, from a usability perspective.

-- alster

comment:6 in reply to:  5 Changed 5 years ago by mcs

Replying to cypherpunks:

When making a decision as to whether most or some Tor Launcher bridges UI users may prefer (be able) to copy/paste bridge configuration info, please keep in mind that there are scenarios, such as with Tails, where the user is not online, and does not have any means to copy / paste this information from anywhere, but just has to enter it manually.

Good point. I am worried that any manual entry scenario will be challenging for non-expert users, but I am not sure how best to address the problem (for example, it will be very easy to make a typo in the fingerprint).

Please also keep in mind that the average user does not understand "does not parse", "key digest" nor "controller gave us config lines that didn't validate", and is not necessarily aware that scrolling to the very end of a lengthy log can be necessary to understand the cause of an error (nor may she be used to and comfortable with looking at and trying to interpret log files at all).

Understood. The point of my previous comment is that the information necessary to determine what went wrong is available (but maybe in a form that is only helpful to help desk people and other experts). I think there is a lot of room for improvement in our error reporting.

It is nice to see that much effort has been put into making things somewhat accessible while still remaining forward compatible - but my personal view is that the current interface is just not good enough for the average, non technical user, from a usability perspective.

Fair enough. I know there was some brainstorming/discussion at the recent winter dev meeting regarding the entire flow of how a user acquires and uses bridges.

comment:7 Changed 5 years ago by yawning

A few extra design considerations that an improved UI should be aware of:

  • Bridges (including those that use pluggable transports with newer obfsproxy) can be IPv6. There are not a large number of those actually running, but the number will hopefully increase as time passes.
  • Pluggable transports can have per-bridge arguments independent of the fingerprint. This does not apply to obfs2/3, but will to ScrambleSuit and it will be an important use case moving forward (For example, the ScrambleSuit argument is of the format "password=<32 characters Base32>").

comment:8 Changed 5 years ago by mcs

Parent ID: #11180

comment:9 Changed 21 months ago by teor

Severity: Normal

Set all open tickets without a severity to "Normal"

comment:10 Changed 17 months ago by mcs

Resolution: wontfix
Status: newclosed

Closing this as "won't fix" given the difficulty of knowing what a bridge line should look like for different transports, as well as the fact that we now have Moat which allows users to directly request bridges.

Note: See TracTickets for help on using tickets.