Hi again,
On Thu, 19 Feb 2015 14:23:03 +0000
sajolida <sajolida@???> wrote:
> intrigeri:
> > sajolida wrote (18 Feb 2015 11:32:17 GMT) :
> >> intrigeri:
> >>> Alan wrote (12 Feb 2015 15:32:15 GMT) :
> >>>>>> - Ability to close a circuit manually.
> >>>>>
[...]
> > => seems like we can address this corner case in a good-enough way
> > without compromising security nor spending large amounts of energy on
> > this topic.
>
> Fine with me. Still, we would need to have arm documented in the first
> place. And since I propose it to go in "Advanced topics" anyway we can
> explain the workaround there for now and create the upstream ticket that
> you mentioned as well.
>
+1
[About the green onion]
> > Now... does Vidalia really do that? In other words, does Vidalia's
> > green onion really turn yellow or red or something whenever this
> > happens? I don't think so: I *believe* that Vidalia's onion indicator,
> > once it has turned green, only reflects the state of Vidalia's
> > connection to the Tor control port, not the state of the tor daemon's
> > connection to the Tor network. I don't remember seeing it change
> > colors unless I e.g. restarted Tor. I'd be happy to be proven wrong,
> > though :)
>
> Same for me, I'm pretty sure that Vidalia stays green forever once Tor
> is started.
...until Vidalia loose connection to the Tor daemon.
> And I'm fine with mimicking this behavior for a start if
> that's easier to implement (no regression), but I think this is buggy
> (the onion shouldn't be green if Tor is not in a working state anymore).
> I want to replace Vidalia to get rid of its bugs not to reimplement them :)
>
> >> but would it be conceivable to have Tor Monitor
> >> appear as green onion on the desktop as Vidalia does until now?
> >
I don't think it's the way to go:
- I'd like Tor Monitor to stay a generic application, with a clear
focus on being a monitor for Tor and showing whatever icon on the
desktop doesn't look like the same task for me.
- System Tray Icons were deprecated in Gtk since 3.14. A proper
implementation of this "green onion" for GNOME 3 desktop would be a
(very simple) Shell extension, to which "we" (the NetworkManager
hook) should send a DBus signal (or the opposite). That might be a
tiny funny project.
[...]
> Yes, and if I understood correctly Tor Monitor currently needs Tails
> Jessie. So an obvious roadmap would be to have a working replacement of
> Vidalia with Tor Monitor (without regressions) in Tails Jessie. Does
> that sound realistic? Then only we can work on making it better (eg.
> smarter onion status icon, progress bar while starting Tor, etc.).
>
> >> And if Tor Monitor is always running in the background, then maybe it
> >> could also provide information while Tor is starting and be the right
> >> tool to solve #7437 in the future?
> >
> > That's what I had hidden in the back of my head when asking this
> > question initially :)
> >
I'm not opposed to exposing a DBus interface in a future version of
TorMonitor to provide the "green onion" or other applications more
information that our hooks could. But I'm not sure it is the right
place to do it yet.
> > The main problem I see with this approach is: if we go this way, then
> > either Tor Monitor stops being a generic tool, but becomes yet another
> > Tails-specific thing, which would make me sad.
>
> Let's try to make it generic straight away! I'd love to have it on my
> regular Debian as well.
>
Me too! I'm not really into solving all the issues we have in this
application.
> > I thought about it
> > a bit harder, and now it's not obvious to me what we would gain by
> > merging the two tools we need into a single one:
> >
> > * Tails could start the Tor bootstrap and time sync progress monitor.
> > Upon completion, this piece of software would either just
> > terminate, or (if we need a permanent indicator that's tight to the
> > actual Tor status) start Tor Monitor --hide-in-taskbar, that would
> > display some onion.
> >
> > * Anyone else would just use Tor Monitor.
> >
> > And then this topic becomes mostly orthogonal to the current
> > discussion, I think :)
>
For the reasons I exposed before, I don't think it's the right
solution. But you can try to convince me...
Cheers
