Hi!
[Cc'ing tails-dev@ for attention. Discussion should continue on
tails-ux@].
It's been a while that I've felt there was a couple pain points in the
process of getting all the way to being connected to the Tor network.
Let's try to list them:
* After the greeter, it's hard to notice that I have to click on
a little icon to select the Wi-Fi network.
* It's the first time I'm coming to this café. Their Wi-Fi blocks
Tor. There's no clue that's the case. Just no progress on the Tor
front for a while. Now I need to reboot Tails just to be able to
configure bridges.
* It's the first time I'm coming to this office. There's no clue,
except that Tor makes no progress, that I need to start the
Unsafe Browser to get through their captive portal.
* Oh, and once I've done the captive portal, Tor can take a long
while to notice that it can actually connects.
* And if it still doesn't connect and I need to configure bridges,
I need to reboot again. Urg! Now I'm getting cranky.
At the Tor meeting, we did a brainstorm on how we could make that part
of the process better. Here's a tentative summary.
One preliminary choice, probably in the greeter, is the type of network
configuration wanted:
1. Automatic configuration. (I don't fear to be identified as a Tails
user.)
2. Manual cofiguration. (I don't want to attract any attention and
I know how to configure the network and Tor.)
3. Offline only.
Then, a big window with a progress bar or at least a “Step 1/n”
indication would appear. We want visible progress so users know how
many things remain before they can actually do some work.
First they would be asked to pick a network. Networks for which a
configuration is known should probably appear on top of the list. [1]
Then we would bump the progress bar and ask them to wait until Tor is
ready.
If we detect a failure when Tor is trying to connect, we should try to
identify the problem as best as we can.
If time is not properly set, then let's ask them to select an accurate
date, time, and time zone. Then let Tor try again.
If we detect a mismatching fingerprint for the bridge or directories,
it's likely that we are under a captive portal.
If Tor is unable to connect, we should ask the user if they want us to
try to detect if they are behind a captive portal [2].
If the network requires a captive portal, then we display a trimmed down
browser in the connection window itself. Below, there's an indicator
which goes “green” when the periodic connectivity test works. A button
“Done” will make Tor try again. There would also be a small button
“Detach” that would extract the embedded browser in a small background
window to support captive portals which require a web page to be kept
open to keep the connection open.
After handling captive portals, if Tor is still unable to connect, that
means configuring bridges [3] is required. We then have a set of screens
to guide users in configuring the best pluggable transports and
trying/retrying various options.
Once Tor is connected to the network, the very last screen
offers buttons to start the browser, configure email, or read the
documentation so users are guided on what to do next.
(We've mainly discussed how it would work for automatic configuration,
but for manual, it's just about removing some screens and asking other
screens earlier.)
Attached is a picture of a bunch of post-its used to think all this
through.
Comments?
Spencer, would you be interested in helping to make some wireframes
unless somebody has good arguments on how this would be a bad idea?
[1]: There's a security/usability trade-off when keeping a record
of networks which have been used and the associated
configuration (WPA passphrase, need for a captive portal,
bridge configuration, …). Some maybe we need an explicit
“save network configuration for later” button at the end
of the process.
[2]: This should be modeled on how Fedora is doing its captive portal
detection to minimize the fingerprint.
[3]: Maybe configure an HTTP proxy as well…
--
Lunar <lunar@???>
