[tor-dev] Vidalia 2.0 - an complete rewrite

Mike Perry mikeperry at torproject.org
Thu Feb 21 18:49:52 UTC 2013


Thus spake Leo Unglaub (leo at leo-unglaub.net):

> Hey guys,
> thanks for all the feedback. I am happy there is an interest from your
> part in this project.
> 
> I am trying to answer to all of your questions below.
> 
> > (since Vidalia and the TBB are two different application windows)
> > 
> > Is that an issue you're trying to solve in your rewrite?
> 
> I didn't address this problem specific, because my UI is complete
> different than the current one. So i hope this confusion will be fixed
> automatically.

This is actually a pretty deep problem with many pieces. It might not be
fixed automatically so long as the OS considers the Tor Controller a
separate app.

Right now, users are currently confused in multiple ways by Vidalia
being a separate app from the browser:

1. The appearance of the Vidalia window before the browser window causes
many users believe that Vidalia is somehow routing *all* traffic through
Tor, and that it is safe to use *any* browser once the Vidalia status
bar has completed (and sometimes even before).

2. Another common source of confusion is the separate Vidalia Dock icon
on Mac, Windows 7+, and Gnome/Unity desktops. This causes all manner of
sub-problems:

2a). People sometimes dock the wrong app icon and later try to launch the
Tor Browser directly without Vidalia.

2b). People get confused over which app (Vidalia or Tor Browser) they
actually need to quit when they're done using the software.

2c). To make matters worse: For some reason, technically sophisticated
users won the argument that TBB's Vidalia+Tor should remain open after
the browser was closed (so they could manually configure other app SOCKS
settings to point at Tor's SOCKS port, and manually re-launch the
browser piece from the command line). This choice was made to the
detriment and confusion of novice users, who often end up launching
several copies of Tor over time, or simply giving up on TBB altogether
when it fails to re-launch with Vidalia open, depending on their OS's
dock behavior.


Not to mention Vidalia+Qt adds 11M to our *compressed* bundle size (60M+
on disk), and also doesn't appear to have a dedicated maintainer.

So the situation is pretty dire, in my opinion.
 
Our plan over the next few months is to create a super-simplified Tor
Controller as a Firefox extension for TBB that can configure
proxies/bridges/pluggable transports (but nothing else), launch Tor, and
display a bootstrap progress bar *inside* the browser window while it
waits for Tor to download network data.

Once we get to that point, I plan to make Vidalia an optional package
for people who really want advanced configuration like also running a
relay/bridge, watching the network map, etc. However, if your Tor
Controller ends up being superior to Vidalia by then, I could easily see
recommending it as the official "Advanced Controller" addon package,
especially since it should be substantially less of a packaging burden
than building and shipping all of Qt for several platforms (I hope).

It will be pretty hard to convince me that we should continue shipping a
separate Controller UI bundled with Tor Browser by default though, given
the above issues.


-- 
Mike Perry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20130221/9815cb00/attachment.pgp>


More information about the tor-dev mailing list