Opened 9 years ago

Closed 8 years ago

Last modified 5 years ago

#2132 closed enhancement (implemented)

Vidalia's password prompt is often unhelpful; generates support requests

Reported by: nickm Owned by: chiiph
Priority: Medium Milestone: Vidalia: 0.3.x
Component: Archived/Vidalia Version:
Severity: Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

I'd say that at least 40% of the support requests we get for Vidalia are from people who have encountered the controller password prompt, and are asking themselves "What's this about a password?" And then we refer them to https://www.torproject.org/docs/faq#VidaliaPassword

It would be good if Vidalia were better able to detect the cases that put it into this state, and tell the user what's really going on. It would also be good if Vidalia could try to recover from this state whenever it can. When Vidalia can neither explain what went wrong nor fix it, it should at the very least give the user more guidance about what might have happened and what they should do, so that they can sort it out themselves without searching for the FAQ.

Apologies if this is a duplicate; I scanned the open vidalia bugs and didn't find it mentioned.

Child Tickets

Attachments (2)

vidalia-option1.png (21.1 KB) - added by chiiph 8 years ago.
Option 1 dialog
vidalia-option2.png (22.3 KB) - added by chiiph 8 years ago.
Option 2 dialog

Download all attachments as: .zip

Change History (17)

comment:1 Changed 8 years ago by chiiph

I think the main problem is that there is no explicit password setting done when you first run Vidalia.
May be if there's a setup wizard, for example, when you first run Vidalia this wouldn't happen.
Something like this:
Screen 1: Welcome, this is a configuration wizard for Vidalia. blablabla
Screen 2: Tor is the main application behind all this, Vidalia is a controller for Tor. For them to communicate safely, you need to setup a password. (widget to write a password). Sometimes Vidalia will need this password, so remember it. NOTE: if you run Tor "by hand", ignore this and configure it properly later on.
Screen 3: Thank you!

(The text of course is not finished :) )

This way, the user will understand at least vaguely what's going on. The screens and texts will need careful thought, but I think it's a nice way to educate users about this.

comment:2 Changed 8 years ago by nickm

I disagree strongly with that.

The main reason that these passwords exist is that we want Cidalia to be able to control Tor without allowing all other applications that can connect to localhost also control Tor. (In particular, we are most worried about the case where a local application is tricked into connecting to the control port by hostile remote content.)

There are other ways to authenticate Vidalia to Tor that ought to work just fine:

  • There's the cookie authentication method if Vidalia can see Tor's data directory, or if Tor can be told to store the cookie somewhere with appropriate protections.
  • Vidalia could remember (locally) the last password it used when setting up tor.
  • On Unix, the control port can be a unix domain socket rather than a TCP port on localhost.

Also, Vidalia could give a useful error message when it fails to connect, and offer the user the option to automatically take one of the actions suggested at https://www.torproject.org/docs/faq#VidaliaPassword .

Any of these appraoches is IMO better than forcing the user to set their own password. Most people, left to their own devices, choose bad passwords and forget them.

comment:3 in reply to:  2 Changed 8 years ago by chiiph

Replying to nickm:

I disagree strongly with that.

There are other ways to authenticate Vidalia to Tor that ought to work just fine:

  • There's the cookie authentication method if Vidalia can see Tor's data directory, or if Tor can be told to store the cookie somewhere with appropriate protections.

I wouldn't trust Windows's filesystem for this.

  • Vidalia could remember (locally) the last password it used when setting up tor.

It's the same as with the cookie auth, how do you save the password?
I think this is worst than (or at least as bad) a user setting a weak password

  • On Unix, the control port can be a unix domain socket rather than a TCP port on localhost.

Yes, ControlSocket capabilities are in the changelog for the next release :)

Also, Vidalia could give a useful error message when it fails to connect, and offer the user the option to automatically take one of the actions suggested at https://www.torproject.org/docs/faq#VidaliaPassword .

We could add this to the help content to easy/fast access, may be displaying a short message and a link to the help content.

Any of these appraoches is IMO better than forcing the user to set their own password. Most people, left to their own devices, choose bad passwords and forget them.

Yes, well, if they want to be anonymous they need to be aware of certain things, it's something you can't avoid. It's like users that setup Internet Explorer to run with Tor, they've been told it's a no-go, but they do it anyway.

comment:4 Changed 8 years ago by nickm

I wouldn't trust Windows's filesystem for this.

Sure. On Unix, we've got many more options than on Windows. We should see if there's anything we can do on windows to make this work out.

Even if the only option is a UI complication, I think that

"Vidalia has detected that there is a Tor running, probably launched by a previous Vidalia. But Vidalia doesn't remember the password that it used. Should vidalia a) Exit, or b) restart Tor"

is a much better interface than the current

"Hi, What's your password?"

and also better than the proposed

"Hi, you're starting vidalia for the first time. Come up with a nice secure password and remember it!"

comment:5 in reply to:  4 Changed 8 years ago by chiiph

Changing that dialog to an information one is really easy. I just thought educating the user was a better approach.

comment:6 Changed 8 years ago by nickm

Educating the user is good. But it's best to:

  • Minimize the need for education. (To the extent that we can make this whole problem go away, that's better than having to teach people how to fix it.)
  • Educate the user at the time when it's helpful. ("Here's what happened and here are your options" is better than "hey, here is something that might happen later that you had better remember about in case it happens!" People are most receptive to new information when it solves a problem they have now, not when it solves a problem they have not yet experienced.)

comment:7 in reply to:  6 Changed 8 years ago by chiiph

Replying to nickm:

Educating the user is good. But it's best to:

  • Minimize the need for education. (To the extent that we can make this whole problem go away, that's better than having to teach people how to fix it.)
  • Educate the user at the time when it's helpful. ("Here's what happened and here are your options" is better than "hey, here is something that might happen later that you had better remember about in case it happens!" People are most receptive to new information when it solves a problem they have now, not when it solves a problem they have not yet experienced.)

Agreed. This is a clear "lets see how the user takes this" situation, for which the idea of releasing an alpha version was meant. I'll transform the prompt into an information dialog, unless someone else comes up with a better approach.

comment:8 Changed 8 years ago by chiiph

Milestone: Vidalia-0.3.X

Changed 8 years ago by chiiph

Attachment: vidalia-option1.png added

Option 1 dialog

Changed 8 years ago by chiiph

Attachment: vidalia-option2.png added

Option 2 dialog

comment:9 Changed 8 years ago by chiiph

Status: newneeds_review

Attached are the two possibilities to this new approach.

Option 1: Vidalia can't kill Tor (this is the case for Linux and OSX) so it informs the situation and gives the only solution possible: quit and kill tor yourself.
Option 2: Vidalia might be able to kill Tor, so it displays the Reset button to try it, or the user can just quit Vidalia.

The wording can probably be improved :)

Here's the commitdiff for this change:
https://gitweb.torproject.org/chiiph/vidalia.git/commitdiff/540b2aa9c3cf7f72b71ef1377ac33210f8a0fc3e

comment:10 Changed 8 years ago by nickm

Looks like a good start.

Do you mean for Option 2 to also include *all* cases where we're running on Linux/OSX ? If the Tor process isn't running as a different user, we should be able to send it a TERM signal just fine.

Let's work on the wording. :)

There are lots of HCI documents out there: is there one that Vidalia tries to follow? For most of them, I think that instead of the "You could" phrasing, I'd expect to see something like "Do you want to".

Here's a first cut of some revised text for the can't-kill-it case:

Tor is already running, but Vidalia can't connect to it.

This can happen when something else (such as another active Vidalia process, or a Vidalia process that crashed) launched Tor.

You will need to shut down the Tor process before Vidalia can launch a new one. 

[ help ]                               [ ok ]

And here's some revised text for the can-kill-it case:

Tor is already running, but Vidalia can't connect to it.

This can happen when something else (such as another active Vidalia process, or a Vidalia process that crashed) launched Tor.

Vidalia can try to restart Tor for you.  Doing so will close all currently active connections through your Tor process.

[ help ]                [ restart Tor ] [ cancel ]

comment:11 Changed 8 years ago by chiiph

Here's a fix regarding nickm's comments:
https://gitweb.torproject.org/chiiph/vidalia.git/commitdiff/e428847150a282aa107b0ba173f3956453810eb4

It can kill processes on Linux/Windows/Mac, and it can handle more than one Tor instance, just killing the one behind the ControlPort that Vidalia's trying to connect to.
This won't work on FreeBSD for what I'm told, I have to build a VM for that.

comment:12 Changed 8 years ago by rransom

The solution is not for Vidalia to go hunt down and kill Tor processes -- the solution is to not let a Tor process that some instance of Vidalia ‘owns’ get orphaned, because nothing else will be able to control it (or even shut it down gracefully on Windows). See #3049.

comment:13 Changed 8 years ago by chiiph

Resolution: implemented
Status: needs_reviewclosed

comment:14 Changed 8 years ago by chiiph

This will be on 0.3.0-alpha.

comment:15 Changed 5 years ago by spectreshadow990

looking at ideas here and being so long ago, would it hurt to just make it with a bit of all that don't clash? say an installer with the ability to create a passwword, a secure store for such localhost info, settings with ports to its main blah blah?? or if the source is available for users who can contribute wwith making rather than just talking about it? and i notice using this a nifty crpto wouldn't go a miss too

Note: See TracTickets for help on using tickets.