Re: [Tails-dev] What do we miss to replace Vidalia [was: Get…

Delete this message

Reply to this message
Author: intrigeri
Date:  
To: The Tails public development discussion list
Subject: Re: [Tails-dev] What do we miss to replace Vidalia [was: Getting rid of Vidalia]
Hi,

Alan wrote (12 Feb 2015 15:32:15 GMT) :
>> > - Ability to close a circuit manually.
>>
>> No idea what are the use case for this feature that we would want to
>> support. If someone really wants it, better add it to arm IMO.
>>
> Tor Monitor doesn't provide this feature yet. It would be very easy to
> add, even though I'm not sure I find it desirable: currently we only
> *monitor* Tor. Do we also really want to *control* it?


Rather not IMO, but I guess everybody got that already :)

I'd love to see Tails run no X application, except Tor Launcher, that
is able to trivially deanonymize the user via the control port.

>> > - Bandwidth Graph.
>>
>> Advanced feature IMO, already present in arm. If we care much about
>> getting this info graphically, then I think some GNOME system monitor
>> would be a better tool to satisfy the need (it would be a suitable
>> replacement in the context of Tails, since we're routing almost
>> everything through Tor).
>>
> It would be possible (and I think desirable) [...]


I'd love to understand why this would be more useful than some
existing GNOME network monitor that we don't have to maintain, and so
far I fail to. You find it desirable, so there's probably a good
reason. Let me try harder to understand:

In which use cases is the Tor bandwidth traffic info more useful than
the overall system network traffic? (I can see the "heavy I2P
+ Tor user" one, but this can't be a good enough reason to write and
maintain this code given we have arm already, I guess.)

Or is it a matter of UX, as in users would find the tool more easily
if it was accessible from the Tor Monitor's interface? I've no idea,
and it might very well be the case. But then perhaps we can start
whatever network traffic monitor we want from Tor Monitor.


And now, I'll add another candidate feature:

- Can access the Tor control port via a tight filtering proxy

I'm curious what kind of access the new thing needs. And forcibly
keeping this access read-only tightens things a bit against
X11-based attacks.

And a few more questions:

- Why does Tor Monitor need to use a Tor SOCKS port? Just curious :)
(The next question will be: what kind of data does it retrieve via
this port, how is it used and parsed, but for that I can probably
just look at the code.)

- Assuming it really does need access to a SOCKS port: how about
using the SOCKS port meant for Tails-specific traffic, instead of
the fallback one?

- Has there been any thought put already into how Tor Monitor would
integrate into #7437 ("Add a progress indicator while establishing
a connection to Tor"), or live aside of it? I was kinda hoping that
removing Vidalia would help consolidating the sources of
information we provide to the user about the network bootstrap
process: I bet the variety of such sources participate in confusing
users. So if Tor Monitor is meant to be an independent tool,
perhaps it's better if it does *not* start by default. Anyway, I'm
wandering a bit off-topic here, but you don't want me to wait
6 months before I ask this question, right?

Cheers,
--
intrigeri