Bug #16293

Focus is on the "Enter" button in the first screen of Tor Launcher

Added by sajolida 2019-01-05 16:20:28 . Updated 2019-08-28 09:19:02 .

Status:
Rejected
Priority:
Normal
Assignee:
Category:
Tor configuration
Target version:
Start date:
2019-01-05
Due date:
% Done:

0%

Feature Branch:
Type of work:
Code
Blueprint:

Starter:
Affected tool:
Tor Launcher
Deliverable for:

Description

If you choose to “Configure a Tor bridge or local proxy” in Tails Greeter, you get the first screen of Tor Launcher after connecting to the network.

On this screen, pressing “Enter” leads to Tor being started without bridges or proxy as “Connect” is preselected by default.

I’m concerned about:

  • People pressing “Enter” by mistake, for example right when the screen appears. I’ve done this a couple of times myself. Then you might connect without bridges or not know how to get back to the configuration screen.
  • People shooting themselves in the foot: why make it so easy to start without bridges after you said you needed extra Tor configuration?
  • The 1st screen not being helpful anyway and basically asking the same question as we already have in Tails Greeter. The 2nd second is the helpful one.

On the other hand, on the 2nd screen of Tor Launcher, the bridges option is selected by default and a mistyped “Enter” activates it.

It’s still possible to skip additional Tor configuration by pressing “Connect” anyway.

How complicated would it be to skip the 1st screen of Tor Launcher in Tails?

Skipping this screen would also solve a number of other issues, see related tickets.


Subtasks


Related issues

Related to Tails - Feature #14544: Spend software developer time on smallish UX improvements In Progress 2018-08-31
Related to Tails - Bug #6898: Don't point to the Tor support channels in Tor Launcher Confirmed 2014-03-11
Has duplicate Tails - Bug #6893: Skip the first screen of Tor Launcher Duplicate 2014-03-10
Has duplicate Tails - Bug #6986: Repeated prompt for simple vs. complex Tor configuration Duplicate 2014-03-29

History

#1 Updated by sajolida 2019-01-05 16:21:31

  • Description updated

#2 Updated by sajolida 2019-01-05 16:21:50

  • related to Feature #14544: Spend software developer time on smallish UX improvements added

#3 Updated by sajolida 2019-01-22 20:03:32

  • has duplicate Bug #6893: Skip the first screen of Tor Launcher added

#4 Updated by intrigeri 2019-01-23 11:08:48

  • related to Bug #6898: Don't point to the Tor support channels in Tor Launcher added

#5 Updated by intrigeri 2019-01-23 11:09:34

  • has duplicate Bug #6986: Repeated prompt for simple vs. complex Tor configuration added

#6 Updated by intrigeri 2019-01-23 11:10:23

I think this needs a new pref + some code to take it into account, both in upstream Tor Launcher.

#7 Updated by intrigeri 2019-01-23 12:13:29

  • Subject changed from Pressing "Enter" launches Tor without bridges to Skip the first screen of Tor Launcher
  • Description updated

#8 Updated by intrigeri 2019-08-25 07:17:40

@sajolida, this conflicts with our first iteration of https://tails.boum.org/blueprint/network_connection/, no? Once we display Tor Launcher to everybody, we will need that first screen.

#9 Updated by sajolida 2019-08-27 17:29:04

  • Subject changed from Skip the first screen of Tor Launcher to Focus is on the "Enter" button in the first screen of Tor Launcher

Good catch! Though displaying Tor Launcher by default might only make worse the problem of having the focus on the “Enter” button by default.

Could we add to our iteration #1 to prevent the bridge configuration if the user presses “Enter” by mistake?

I renamed this ticket to adjust to that.

A solution could be to put the focus on the “Config” button by default instead.

#10 Updated by intrigeri 2019-08-27 20:07:56

> Good catch!

:)

> Though displaying Tor Launcher by default might only make worse the problem of having the focus on the “Enter” button by default.

This conclusion was not obvious to me, so I went to the drawing board.

As far as I understand the problem and the ticket description, there are two main things at stake here:

  • A. Trying to connect to Tor in a way that won’t work, and then it fails.
    • Mistakes have no security impact on user safety.
    • To be given the opportunity to solve the problem, one can either restart Tails (currently + in iteration 1), or reconnect to the network (and see Tor Launcher again; only in iteration 1) ⇒ iteration 1 improves things here, right?
  • B. Connecting to Tor in a way that does not hide the fact one is using Tor, while the user needs to hide this fact.
    • Mistakes have serious security impact on user safety.
    • No mitigation is available apart of making a run for it.

In both cases:

  • Currently, one needs to make 1 single mistake for this to happen, but they have 2 opportunities for that: either forget to select the necessary option in the Greeter, or do that but later, press Enter in Tor Launcher.
  • In the 1st iteration as-is, one still needs to make only 1 mistake (in Tor Launcher). But there’s only 1 opportunity for a mistake, so the risk is lower ⇒ improvement.

So to me, it seems that the 1st iteration as-is already gives us small improvements on this topic.

> Could we add to our iteration #1 to prevent the bridge configuration if the user presses “Enter” by mistake?

I don’t understand what you mean with “prevent the bridge configuration” here. Did you mean “display”, or similar?

> A solution could be to put the focus on the “Config” button by default instead.

This would indeed make it much harder to hit the aforementioned problematic situations.
I don’t like it much though, because:

  • Users of Tor Browser are used to “Enter” being focused by default. Consistency put aside, if we train Tails users that they can press “Enter” to configure (possibly obfuscated) bridges, then we put them at risk when they use Tor Browser.
  • It requires one necessary action for everyone who can directly connect to Tor. I suspect that’s the vast majority of our current users, if not of our prospective users (thankfully, Tails is useful and relevant in many situations where one can connect to Tor directly).
  • Problem (A) has no security impact and can be solved in several manners by the user (while currently, the only way is to reboot IIRC).
  • Problem (B) matters but it’s not clear to me that Tails should optimize for this use case, if that means making it more painful for those who can connect directly to Tor.
  • Iteration 2 will further improve the situation for problems A and B, and in a nicer way (except for the first few boots). And then, the drawbacks of focusing the “Config” button by default will outweigh the advantages. But we’ll be stuck with it, because reverting such a change puts users at risk, after we’ve trained them to press “Enter” to not connect to Tor directly.

So at this point, I think I would reject this ticket in favour of iterations 1 and 2.

#11 Updated by sajolida 2019-08-28 08:44:14

> So to me, it seems that the 1st iteration as-is already gives us small improvements on this topic.

Indeed!

>> Could we add to our iteration #1 to prevent the bridge configuration if the user presses “Enter” by mistake?
>
> I don’t understand what you mean with “prevent the bridge configuration” here. Did you mean “display”, or similar?

Looks like my sentence is broken. Forget it.

> So at this point, I think I would reject this ticket in favour of iterations 1 and 2.

Ok!

#12 Updated by intrigeri 2019-08-28 09:19:02

  • Status changed from Confirmed to Rejected