Hi,
intrigeri <intrigeri@???> wrote:
> >> > - 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.
As an example, when using a poor connection, I like to see if there is
Tor traffic going on or not. I must admit I never tried to use GNOME
System Monitor for that and that it may very well work (or not).
Tor reports its bandwidth usage via the control port with a "bandwidth"
event every second, so there is really not much to maintain, it's just
about plotting this data.
>
> 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.
Tor monitor uses stem, and I didn't search about hidden things stem
might need. I use methods that directly call:
- GETINFO circuit-status
- GETINFO stream-status
- GETINFO ip-to-country
> And forcibly keeping this access read-only tightens things a bit against
> X11-based attacks.
>
We need at least to query Tor for its open circuits and streams if we
want to be able to start Tor Monitor after Tor. If we can ensure that
Tor Monitor connects to Tor before Tor has open any circuit or stream,
then it may be possible to have read only access if no command on the
control port is needed to be notified of circuit or stream changes.
> And a few more questions:
>
> - Why does Tor Monitor need to use a Tor SOCKS port? Just curious :)
To get details on a path. As Tor currently uses microdescriptors which
contains very few information, I use stem remote descriptor downloader,
which connects directly to Tor directory. Looking more deeply at what I
can get directly from Tor, I just found that I can get the IP and other
information missing in microdescriptors from Tor network status, so I'd
only miss platform and uptime - which are not visible in Vidalia
anymore.
> (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.)
>
I use stem.descriptor.remote.DescriptorDownloader.
> - 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?
>
Sure. I guess it should be configurable.
> - 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?
>
I was thinking about an application that an user would only launch from
the Applications menu/overview. I also thought about a button in the
"Tor is ready" notification. But not launching Tor Monitor
automatically means we *need* write access to the control port to list
open circuit/streams.
Cheers
