Re: [Tails-dev] How to replace the green onion
Hi,
Alan wrote (22 Feb 2015 01:48:28 GMT) :
> intrigeri wrote:
>> Alan wrote (20 Feb 2015 19:43:10 GMT) :
>> > 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.
>>
>> What would be a better place to do it in your opinion?
>>
> In my opinion, the easiest method to replace vidalia's green onion
> would be to write a very small GNOME Shell extension that would listen
> to a very simple DBus service.
Did I get it right that this extension will actually *provide* that
DBus service? And then other stuff (see below) will connect to it to
notify the extension that Tor is up?
> The very same mechanism that currently
> displays the "Tor is ready" notification in Tails would trigger a
> notification to this DBus service that would update this onion. I admit
> this would be very Tails specific.
I think we can go this way (or similar) for the first iteration, that
replaces what Vidalia gives us, including the buggy green onion.
So I've created #9002, as a child ticket of #6841 ("Replace Vidalia").
Now, in the first iteration, the information we want to convey to that
Shell extension is exactly one bit ("Tor is ready", and possibly "Tor
is down" on network post-down). Using DBus to convey this information
seems vastly overkill to me, to the point of being a little
bit ridiculous.
If that saves us time for the next iterations, why not. But for the
next iterations of that extension, the listening direction may change
(I expect that something else will provide the DBus service that
provides updates wrt. the status of Tor connectivity, and the Shell
extension will connect to that service to get these updates), so
perhaps it's really not useful to get DBus onboard before we have
a clearer idea of the design for the next iterations.
An alternative, for the initial iteration, is to do exactly what we're
doing now: when we display "Tor is ready", simply enable the Shell
extension that displays the green onion. And disable it when the
network gets disconnected. This way, we don't even need any
communication channel :)
> Please note that I'm not aware of such a concept of "connectivity
> status" in Tor. If you know about it, don't hesitate to point me to
> relevant documentation.
No idea. Is it equivalent to having circuits open? I think Tor tries
to maintain circuits open even when they're not requested by clients,
so if there's no circuit open, perhaps Tor can be considered
as disconnected?
>> However, splitting it out has a few clear disadvantages:
>>
>> 1. That's one more (presumably Python) process to run, which eats
>> memory etc. Of course, if we go this way, then we don't have to
>> run Tor Monitor by default, so it's only one *more* process for
>> users who manually start Tor Monitor, but still.
>>
> Looks to me that you basically destroyed you own argument...
... only if we don't care about people who will run Tor Monitor.
>> 2. I suspect that this program will be doing very similar things to
>> Tor Monitor under the hood, and then we may quickly have more code
>> duplication than reasonable.
>>
> If we only care about "connectivity status" I'm very unsure that there
> would be code duplication.
OK. At least the "reconnect to Tor when it restarts" part would need
to be implemented on both sides, I guess. But that's probably not
much, and you're probably right.
>> Granted, none of these arguments is very strong, except perhaps the
>> last one. If that backend program + Shell extension were shipped in
>> the same upstream project as Tor Monitor, then #2 and #4 are done
>> with, and I'm happy. Maybe we can reach a consensus on this design?
>>
> I'd agree on that. But I'm not opposed either on integrating a DBus
> interface more strongly in the current Tor Monitor application if:
> - it proves to be actually useful;
> - I get some help with the programming design. If you have a look at
> current code, you'll see that UI code is highly mixed with
> communicating with Tor. That didn't look ugly to me as stem already
> implements most of the logic. But to expose the same (or a subset of)
> this data on DBus, we'd need to redesign this a lot.
Absolutely (after finally having glanced over the code).
> An advantage if such an approach is that there is no reason why the
> DBus service would run the same unix user as the UI. So if the UI would
> only get its information from the DBus service, then we don't need any
> access to the Tor control port for the user running the UI.
I'm very skeptic about having the Tor Monitor UI get all the info it
needs over DBus. The backend would not only have to let it know about
updates, but also about Tor's initial state on Tor Monitor startup.
I already see how racy this can become with three different event
loops (Stem's, DBus' and GTK's) in the mix and a pil
Re: [Tails-dev] How to replace the green onion
sajolida wrote (05 Mar 2015 17:03:04 GMT) : > I hereby propose to have the list of circuits accessible directly from > the green onion as it is the case now in Vidalia. But I'm not sure how > this fits with your architectural plans and related > security implications. It should be no problem: assuming the green onion thingie is a GNOME Shell extension (this seems to be the only reasonable way to do it IMO), then it'll run as the `amnesia' users, who should be able to start Tor Monitor anyway. > Alan, I'm not sure what are the implications of the deprecation of > System Tray Icons as I couldn't find anything about that in the GNOME > HIG. The HIG apparently doesn't capture everything that the code does. Let me provide some background. In previous versions of GNOME, there were two different things: * proper panel applets (e.g. NM's one) * icons in the notification area (that very often were things that should really be applets, but their authors were lazy and they hijacked the notification area -- that's what we did for our own OpenPGP applet, oops) While with GNOME Shell: * the notification area isn't displayed by default anymore; * a third-party extension (topIcons) can be used to restore the old notification area icons placement; no idea how long this hack will work; * what used to be "proper panel applets" can now be implemented as GNOME Shell extensions. > But in Tails Jessie we still have various custom widgets in the top > bar that expend to more features when you act on them: the Florence > keyboard and the OpenPGP Applet. So I guess this is still acceptable... That's a temporary hack, made possible only via a third-party GNOME Shell extension, and I'd like to get rid of as soon as possible (https://labs.riseup.net/code/issues/8309). Adding more stuff there would add to the list of things that we'll have to rewrite/replace later. Cheers, -- intrigeri ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] How to replace the green onion
intrigeri: > sajolida wrote (05 Mar 2015 17:03:04 GMT) : >> I hereby propose to have the list of circuits accessible directly from >> the green onion as it is the case now in Vidalia. But I'm not sure how >> this fits with your architectural plans and related >> security implications. > > It should be no problem: assuming the green onion thingie is a GNOME > Shell extension (this seems to be the only reasonable way to do it > IMO), then it'll run as the `amnesia' users, who should be able to > start Tor Monitor anyway. Cool! >> Alan, I'm not sure what are the implications of the deprecation of >> System Tray Icons as I couldn't find anything about that in the GNOME >> HIG. > > The HIG apparently doesn't capture everything that the code does. > Let me provide some background. In previous versions of GNOME, there > were two different things: > > * proper panel applets (e.g. NM's one) > * icons in the notification area (that very often were things that > should really be applets, but their authors were lazy and they > hijacked the notification area -- that's what we did for our own > OpenPGP applet, oops) Understood. > While with GNOME Shell: > > * the notification area isn't displayed by default anymore; Yeah, I've seen the redesign for 3.16 that you sent me. > * a third-party extension (topIcons) can be used to restore the old > notification area icons placement; no idea how long this hack will > work; That's #8309. > * what used to be "proper panel applets" can now be implemented as > GNOME Shell extensions. > >> But in Tails Jessie we still have various custom widgets in the top >> bar that expend to more features when you act on them: the Florence >> keyboard and the OpenPGP Applet. So I guess this is still acceptable... > > That's a temporary hack, made possible only via a third-party GNOME > Shell extension, and I'd like to get rid of as soon as possible > (https://labs.riseup.net/code/issues/8309). Adding more stuff there > would add to the list of things that we'll have to > rewrite/replace later. Ok, so that confirms what I understood already. We can still put *some* stuff in the top bar (without much change for the user) but that needs to be done as GNOME Shell extensions. That's more of a infrastructure and code change than a UX change in the end. Good news. -- sajolida ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] How to replace the green onion
Hi,
intrigeri wrote:
> Alan wrote (22 Feb 2015 01:48:28 GMT) :
> > intrigeri wrote:
> >> Alan wrote (20 Feb 2015 19:43:10 GMT) :
> >> > 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.
> >>
> >> What would be a better place to do it in your opinion?
> >>
> > In my opinion, the easiest method to replace vidalia's green onion
> > would be to write a very small GNOME Shell extension that would listen
> > to a very simple DBus service.
>
> Did I get it right that this extension will actually *provide* that
> DBus service? And then other stuff (see below) will connect to it to
> notify the extension that Tor is up?
>
It may indeed be the easiest to do, even it it sounds a bit reverse
logic.
> > The very same mechanism that currently
> > displays the "Tor is ready" notification in Tails would trigger a
> > notification to this DBus service that would update this onion. I admit
> > this would be very Tails specific.
>
> I think we can go this way (or similar) for the first iteration, that
> replaces what Vidalia gives us, including the buggy green onion.
> So I've created #9002, as a child ticket of #6841 ("Replace Vidalia").
>
> Now, in the first iteration, the information we want to convey to that
> Shell extension is exactly one bit ("Tor is ready", and possibly "Tor
> is down" on network post-down).
Really? I though we wanted bootstrap progress too, that current
vidalia's onion provides (no onion/red > yellow > green)
> Using DBus to convey this information
> seems vastly overkill to me, to the point of being a little
> bit ridiculous.
>
If we only want a boolean status, I agree with you.
> If that saves us time for the next iterations, why not. But for the
> next iterations of that extension, the listening direction may change
> (I expect that something else will provide the DBus service that
> provides updates wrt. the status of Tor connectivity, and the Shell
> extension will connect to that service to get these updates), so
> perhaps it's really not useful to get DBus onboard before we have
> a clearer idea of the design for the next iterations.
>
> An alternative, for the initial iteration, is to do exactly what we're
> doing now: when we display "Tor is ready", simply enable the Shell
> extension that displays the green onion. And disable it when the
> network gets disconnected. This way, we don't even need any
> communication channel :)
>
This can be done by changing a GSetting. I do not find it very elegant
to change a setting at each network status change, but it may work. I
didn't found a DBus interface to enable/disable extensions. At first
glance, I think DBus might still be the more appropriate.
> > Please note that I'm not aware of such a concept of "connectivity
> > status" in Tor. If you know about it, don't hesitate to point me to
> > relevant documentation.
>
> No idea. Is it equivalent to having circuits open? I think Tor tries
> to maintain circuits open even when they're not requested by clients,
> so if there's no circuit open, perhaps Tor can be considered
> as disconnected?
>
Tor always tries to build circuits, so it has circuits in "launched"
state. We could consider Tor as "connected" as long as it has at least
one circuit in "built" state.
[...]
> > To sum up, I see three options (on order of complexity) to feed this
> > GNOME shell extension that would provide the onion:
>
> > 1. through the same mechanism that displays the "Tor is ready"
> >notification;
> > 2. through a DBus service that would be a separate process that the
> >Tor Monitor application (but managed in the same project);
> > 3. through a DBus service that would be tightly integrated in the Tor
> >Monitor application.
>
> I say let's go with (1) as far as #6841 is concerned.
>
I agree it's the easiest way to start with.
Cheers
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to
tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] How to replace the green onion
Hi,
Alan wrote (06 Mar 2015 21:04:46 GMT) :
> intrigeri wrote:
>> Alan wrote (22 Feb 2015 01:48:28 GMT) :
>> > The very same mechanism that currently
>> > displays the "Tor is ready" notification in Tails would trigger a
>> > notification to this DBus service that would update this onion. I admit
>> > this would be very Tails specific.
>>
>> I think we can go this way (or similar) for the first iteration, that
>> replaces what Vidalia gives us, including the buggy green onion.
>> So I've created #9002, as a child ticket of #6841 ("Replace Vidalia").
>>
>> Now, in the first iteration, the information we want to convey to that
>> Shell extension is exactly one bit ("Tor is ready", and possibly "Tor
>> is down" on network post-down).
> Really? I though we wanted bootstrap progress too, that current
> vidalia's onion provides (no onion/red > yellow > green)
Sadly, this assumption is not correct... which gives us yet another
demonstration that even *we* don't understand what these colors are
about (hence my doubts about whether it's really useful, but
thankfully I've given up on arguing about that already). In current
Tails:
a) no onion indeed means "Tor hasn't bootstrapped yet", since we start
Vidalia only when Tor has bootstrapped
b) yellow onion means that:
1. Vidalia is connected to the Tor control port
2. while Tor has already successfully bootstrapped (otherwise we
wouldn't have started Vidalia), Vidalia hasn't downloaded all
the info it needs to display a complete UI (most notably, the
detailed info about relays)
c) green onion means that Vidalia is connected to the Tor control port
and has all the info it needs to display a complete UI
[No idea if/how it's different when Vidalia is integrated into other
operating systems, but who cares, we're talking about avoiding
regressions vs. the current state of Tails here.]
The only information in there that is about Tor's bootstrap progress
is "display an onion at all, or not", which is 1 bit of information.
The rest is about Vidalia's own bootstrap progress.
I don't think that the onion Shell extension needs to differentiate
between cases (b) and (c): IIRC we want it to provide some way to
start Tor Monitor, and then Tor Monitor can itself convey to the user
any relevant message regarding its own bootstrap status, that is how
much it's ready to display complete information. As I understand it,
we want the onion icon to say something about the state of Tor, not
about the state of Tor Monitor.
So, we don't need to convey any additional information to the onion
Shell extension than "we've started you, display that green onion" and
"stop displaying that green onion" (possibly by disabling the
extensions altogether).
Thoughts?
>> An alternative, for the initial iteration, is to do exactly what we're
>> doing now: when we display "Tor is ready", simply enable the Shell
>> extension that displays the green onion. And disable it when the
>> network gets disconnected. This way, we don't even need any
>> communication channel :)
>>
> This can be done by changing a GSetting. I do not find it very elegant
> to change a setting at each network status change, but it may work. I
> didn't found a DBus interface to enable/disable extensions. At first
> glance, I think DBus might still be the more appropriate.
I don't understand why, but I guess that's probably a matter of
taste... and it now seems clear that our personal taste differs a lot
regarding what's an appropriate IPC mechanism to convey one single bit
of information. Now, if there's any technical reason why you still
prefer using DBus, I'm all ears :)
> Tor always tries to build circuits, so it has circuits in "launched"
> state. We could consider Tor as "connected" as long as it has at least
> one circuit in "built" state.
This seems worth trying, but doesn't seem necessarily part of the
first iteration about replacing what we have currently (since we don't
have that feature yet).
>> > To sum up, I see three options (on order of complexity) to feed this
>> > GNOME shell extension that would provide the onion:
>>
>> > 1. through the same mechanism that displays the "Tor is ready"
>> >notification;
[...]
>> I say let's go with (1) as far as #6841 is concerned.
>>
> I agree it's the easiest way to start with.
Oooh yeah. Are you interested in taking care of this Shell extension?
Do you want me to file whatever tickets are needed about it?
Cheers,
--
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to
tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] How to replace the green onion
intrigeri: > Alan wrote (06 Mar 2015 21:04:46 GMT) : >> intrigeri wrote: >>> Alan wrote (22 Feb 2015 01:48:28 GMT) : > >> Really? I though we wanted bootstrap progress too, that current >> vidalia's onion provides (no onion/red > yellow > green) > > Sadly, this assumption is not correct... which gives us yet another > demonstration that even *we* don't understand what these colors are > about (hence my doubts about whether it's really useful, but > thankfully I've given up on arguing about that already). In current > Tails: > > a) no onion indeed means "Tor hasn't bootstrapped yet", since we start >Vidalia only when Tor has bootstrapped > b) yellow onion means that: >1. Vidalia is connected to the Tor control port >2. while Tor has already successfully bootstrapped (otherwise we > wouldn't have started Vidalia), Vidalia hasn't downloaded all > the info it needs to display a complete UI (most notably, the > detailed info about relays) > c) green onion means that Vidalia is connected to the Tor control port >and has all the info it needs to display a complete UI > > [No idea if/how it's different when Vidalia is integrated into other > operating systems, but who cares, we're talking about avoiding > regressions vs. the current state of Tails here.] > > The only information in there that is about Tor's bootstrap progress > is "display an onion at all, or not", which is 1 bit of information. > The rest is about Vidalia's own bootstrap progress. > > I don't think that the onion Shell extension needs to differentiate > between cases (b) and (c): IIRC we want it to provide some way to > start Tor Monitor, and then Tor Monitor can itself convey to the user > any relevant message regarding its own bootstrap status, that is how > much it's ready to display complete information. As I understand it, > we want the onion icon to say something about the state of Tor, not > about the state of Tor Monitor. > > So, we don't need to convey any additional information to the onion > Shell extension than "we've started you, display that green onion" and > "stop displaying that green onion" (possibly by disabling the > extensions altogether). I agree with intrigeri that the yellow onion is currently broken. We could fix this to match "yellow" = "Tor is starting" which is, I guess, the intended meaning of it. At least that's what our doc say :) https://tails.boum.org/doc/anonymous_internet/vidalia/index.en.html But since it's broken now, we have no reason to fix it before replacing Vidalia, and I'd rather work on #7438 (progress indicator) to convey that meaning. Once we get there I definitely think that we won't need to duplicate whatever Tor progress indicator with a yellow onion. Unless the progress indicator itself is a yellow onion, ha ha! This I can't tell you as we haven't design this at all yet... Still, the fact that this green onion will probably end up being part of a bigger picture (Tor indicator) might be useful to keep in mind while designing its technical infrastructure. Regarding whether the onion turns red when Tor is not usable anymore (for whatever reason that we still need to specify). This I can't tell either. If you think that you need more UX design to be done before deciding on the right infrastructure for those tools, then we should start a thread on tails-ux. The bad thing to do would be to take technical decisions in this thread (which is dense and probably not read by anyone else than us) that would, later on, limit what we ca propose as UX for the big picture of #7438 and frustrate both the people designing and the people coding. -- sajolida ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] How to replace the green onion
Hi, sajolida wrote (10 Mar 2015 14:17:29 GMT) : > If you think that you need more UX design to be done before deciding on > the right infrastructure for those tools, then we should start a thread > on tails-ux. I don't think that's needed at this point, as long as we manage to stick to minimalistic solutions that 1. are good enough for the time being; 2. require as little work as possible; and 3. hence, can be ditched without regrets once the Next Generation thing has been designed and implemented. In this thread, I think we're doing pretty well so far on these angles, and I trust we'll avoid over-engineering stuff based on guesses about what the bigger picture will look like. > The bad thing to do would be to take technical decisions in > this thread (which is dense and probably not read by anyone else than > us) that would, later on, limit what we ca propose as UX for the big > picture of #7438 and frustrate both the people designing and the people > coding. Understood. Cheers, -- intrigeri ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] How to replace the green onion
Hi,
intrigeri wrote:
> Alan wrote (06 Mar 2015 21:04:46 GMT) :
> > intrigeri wrote:
> >> Now, in the first iteration, the information we want to convey to that
> >> Shell extension is exactly one bit ("Tor is ready", and possibly "Tor
> >> is down" on network post-down).
>
> > Really? I though we wanted bootstrap progress too, that current
> > vidalia's onion provides (no onion/red > yellow > green)
>
> Sadly, this assumption is not correct... which gives us yet another
> demonstration that even *we* don't understand what these colors are
> about (hence my doubts about whether it's really useful, but
> thankfully I've given up on arguing about that already). In current
> Tails:
>
[...]
Thanks for the explanation.
> The only information in there that is about Tor's bootstrap progress
> is "display an onion at all, or not", which is 1 bit of information.
> The rest is about Vidalia's own bootstrap progress.
>
OK
> I don't think that the onion Shell extension needs to differentiate
> between cases (b) and (c): IIRC we want it to provide some way to
> start Tor Monitor, and then Tor Monitor can itself convey to the user
> any relevant message regarding its own bootstrap status, that is how
> much it's ready to display complete information. As I understand it,
> we want the onion icon to say something about the state of Tor, not
> about the state of Tor Monitor.
>
There is no such concept op tor monitor bootstrap anymore, so let's
stop thinking about this.
> So, we don't need to convey any additional information to the onion
> Shell extension than "we've started you, display that green onion" and
> "stop displaying that green onion" (possibly by disabling the
> extensions altogether).
>
> Thoughts?
>
OK
> >> An alternative, for the initial iteration, is to do exactly what we're
> >> doing now: when we display "Tor is ready", simply enable the Shell
> >> extension that displays the green onion. And disable it when the
> >> network gets disconnected. This way, we don't even need any
> >> communication channel :)
> >>
> > This can be done by changing a GSetting. I do not find it very elegant
> > to change a setting at each network status change, but it may work. I
> > didn't found a DBus interface to enable/disable extensions. At first
> > glance, I think DBus might still be the more appropriate.
>
> I don't understand why,
Because a GSetting is not meant to be changed programatically in
response to the state of the world. It's a setting.
> but I guess that's probably a matter of
> taste... and it now seems clear that our personal taste differs a lot
> regarding what's an appropriate IPC mechanism to convey one single bit
> of information. Now, if there's any technical reason why you still
> prefer using DBus, I'm all ears :)
>
I don't prefer DBus, I'm only reluctant to change a setting. Monitoring
a file or any proposal that doesn't obviously misuse a system (e.g. the
GSetting) would suit me.
> > Tor always tries to build circuits, so it has circuits in "launched"
> > state. We could consider Tor as "connected" as long as it has at least
> > one circuit in "built" state.
>
> This seems worth trying, but doesn't seem necessarily part of the
> first iteration about replacing what we have currently (since we don't
> have that feature yet).
>
> >> > To sum up, I see three options (on order of complexity) to feed this
> >> > GNOME shell extension that would provide the onion:
> >>
> >> > 1. through the same mechanism that displays the "Tor is ready"
> >> >notification;
> [...]
> >> I say let's go with (1) as far as #6841 is concerned.
> >>
> > I agree it's the easiest way to start with.
>
> Oooh yeah. Are you interested in taking care of this Shell extension?
Yes.
> Do you want me to file whatever tickets are needed about it?
>
I'd appreciate it.
Cheers
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to
tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] How to replace the green onion
Hi, sajolida wrote: > Regarding whether the onion turns red when Tor is not usable anymore > (for whatever reason that we still need to specify). This I can't tell > either. > To avoid regressions, let's just implement a very simple 1 bit extension (Tor/no Tor). > If you think that you need more UX design to be done before deciding on > the right infrastructure for those tools, then we should start a thread > on tails-ux. The bad thing to do would be to take technical decisions in > this thread (which is dense and probably not read by anyone else than > us) that would, later on, limit what we ca propose as UX for the big > picture of #7438 and frustrate both the people designing and the people > coding. > I don't we need more design to implement the basic mechanism that would avoid regressions. Cheers ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] How to replace the green onion
Hi, Alan wrote (15 Mar 2015 10:41:55 GMT) : > intrigeri wrote: > Because a GSetting is not meant to be changed programatically in > response to the state of the world. It's a setting. Thanks, I got it now :) >> but I guess that's probably a matter of >> taste... and it now seems clear that our personal taste differs a lot >> regarding what's an appropriate IPC mechanism to convey one single bit >> of information. Now, if there's any technical reason why you still >> prefer using DBus, I'm all ears :) >> > I don't prefer DBus, I'm only reluctant to change a setting. Monitoring > a file or any proposal that doesn't obviously misuse a system (e.g. the > GSetting) would suit me. Let's go for monitoring a given file's existence, then. >> Oooh yeah. Are you interested in taking care of this Shell extension? > Yes. >> Do you want me to file whatever tickets are needed about it? >> > I'd appreciate it. I've updated #9002 to reflect what I believe is the consensus we've reached, and I've assigned it to you. ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] How to replace the green onion
Hi, On Sun, 15 Mar 2015 18:15:22 +0100 intrigeri wrote: > >> Do you want me to file whatever tickets are needed about it? > >> > > I'd appreciate it. > > I've updated #9002 to reflect what I believe is the consensus we've > reached, and I've assigned it to you. Thanks! ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] How to replace the green onion [was: What do we miss to replace Vidalia]
Hi, Some precisions on my last email below. Alan wrote: > intrigeri wrote: > > I can imagine that we have a totally separate backend that monitors > > Tor's connectivity status > > Please note that I'm not aware of such a concept of "connectivity > status" in Tor. If you know about it, don't hesitate to point me to > relevant documentation. > There is a 'bootstrap-status' client status event (and associated GETINFO) which gives information on the 1st bootstrap, but Tor doesn't seem aware of lost connection (unless system clock jumps) > An advantage if such an approach is that there is no reason why the > DBus service would run the same unix user as the UI. So if the UI would > only get its information from the DBus service, then we don't need any > access to the Tor control port for the user running the UI. > Here is a diagram on what I though for more privilege separation: control socket Tor <> TorMonitorD ^ debian-tor user | .DBus desktop user syetem bus /\ / \ gnome-shell Tor Monitor tor monitor application extension Pros: - only one connection to the Tor daemon - better isolation between the controller and X Cons: - much more complicated design - more work to implement ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] How to replace the green onion [was: What do we miss to replace Vidalia]
Hi, Alan wrote (01 Mar 2015 18:26:28 GMT) : > Here is a diagram on what I though for more privilege separation: > control socket > Tor <> TorMonitorD > ^ > debian-tor user | > .DBus > desktop user syetem bus > /\ >/ \ > gnome-shell Tor Monitor > tor monitor application > extension > Pros: > - only one connection to the Tor daemon We also get this advantage if whatever info other parts of the Tails desktop need is provided by the Tor Monitor process itself. > - better isolation between the controller and X ... but we're introducing yet another large pile of code, which relies on an even larger pile of underlying libraries, and which 1. can fully control Tor; 2. exposes lots of interfaces (including those that the Tor Monitor GUI itself needs) to any process running on the system. So, assuming we went this way, I'd want to have TorMonitorD talk to the Tor control port via our filtering proxy. And then, we can as well have Tor Monitor do the same, with basically the same security advantages + way less code and complexity. And the set of interfaces that it needs to expose on the system bus to unprivileged processes will be much smaller. (Also note that nothing forces us — I hope — to run Tor Monitor as the `amnesia' user: instead, we can run it as a dedicated user, just like we're currently doing for Vidalia.) Cheers, -- intrigeri ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] How to replace the green onion [was: What do we miss to replace Vidalia]
Alan: > intrigeri wrote: >> Alan wrote (20 Feb 2015 19:43:10 GMT) : >>> On Thu, 19 Feb 2015 14:23:03 + >>> sajolida wrote: intrigeri: > sajolida wrote (18 Feb 2015 11:32:17 GMT) : >> intrigeri: >>> [About the green onion] >> >> 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. >> >> IMO the "providing feedback regarding Tor connectivity status" feature >> fits pretty well into the "monitoring Tor" mission. Perhaps we don't >> put the same meaning behind "monitoring Tor". >> > Ok. You have a point here. This could be argued as some "desktop > integration" of the application. Meta: it's getting hard for me to follow the technical side of all this. I'm still maturing the UX side of things... Beware! Following-up on the ideas of: - Keeping the green onion as a permanent visual feedback on the desktop. - Not breaking too much of what people have been used to unless we have a good (UX) reason to do so (keeping what works in Vidalia). - Integrating Tor Monitor nicely on the desktop. - Considering the green onion and the list of circuits as part of the same user task of "monitoring tool". I hereby propose to have the list of circuits accessible directly from the green onion as it is the case now in Vidalia. But I'm not sure how this fits with your architectural plans and related security implications. Alan, I'm not sure what are the implications of the deprecation of System Tray Icons as I couldn't find anything about that in the GNOME HIG. But in Tails Jessie we still have various custom widgets in the top bar that expend to more features when you act on them: the Florence keyboard and the OpenPGP Applet. So I guess this is still acceptable... -- sajolida ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] How to replace the green onion [was: What do we miss to replace Vidalia]
Hi, sajolida wrote: > Following-up on the ideas of: > > - Keeping the green onion as a permanent visual feedback on the desktop. > - Not breaking too much of what people have been used to unless we > have a good (UX) reason to do so (keeping what works in Vidalia). > - Integrating Tor Monitor nicely on the desktop. > - Considering the green onion and the list of circuits as part of the > same user task of "monitoring tool". > > I hereby propose to have the list of circuits accessible directly from > the green onion as it is the case now in Vidalia. But I'm not sure how > this fits with your architectural plans and related security implications. > What I see is : Top shell bar Onion | | v v [_Applications_Places__O_o_o_o_] A___ |Tor is ready| |Open Tor Monitor| ++ Disconnected: striked onion X X XX_./\._XX /XX XX\ / XX \ | XX XX | XX__XX X X Bootstraping: onion with dots (as when network is connecting) _./\._ / \ //\ /\ /\\ |\/ \/ \/| \/ Connected: full onion _./\._ / \ /\ || \/ Would this address your requirements? By the way, I'm not sure the onion should be green. For better integration into GNOME Shell I think it should perhaps be monochromatic. Cheers ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] How to replace the green onion [was: What do we miss to replace Vidalia]
hi, Alan wrote (06 Mar 2015 21:12:43 GMT) : > sajolida wrote: >> I hereby propose to have the list of circuits accessible directly from >> the green onion as it is the case now in Vidalia. But I'm not sure how >> this fits with your architectural plans and related security implications. I'm not sure I understand what sajolida meant with "directly" in this sentence. If that's "clicking the onion icon directly starts Tor Monitor", or "clicking the onion icon opens a menu that proposes to start Tor Monitor", then I agree. > Top shell bar Onion > | | > v v > [_Applications_Places__O_o_o_o_] >A___ > |Tor is ready| > |Open Tor Monitor| > ++ ACK until here, for the first iteration. > Disconnected: striked onion [...] > Bootstraping: onion with dots (as when network is connecting) [...] > Connected: full onion IMO that should be thought through as part of #7437, and I haven't the big picture and goals in mind (if the latter were defined at all yet), so I won't comment on this part yet. Cheers, -- intrigeri ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] How to replace the green onion [was: What do we miss to replace Vidalia]
intrigeri: > Alan wrote (06 Mar 2015 21:12:43 GMT) : >> sajolida wrote: >>> I hereby propose to have the list of circuits accessible directly from >>> the green onion as it is the case now in Vidalia. But I'm not sure how >>> this fits with your architectural plans and related security implications. > > I'm not sure I understand what sajolida meant with "directly" in this > sentence. If that's "clicking the onion icon directly starts Tor > Monitor", or "clicking the onion icon opens a menu that proposes to > start Tor Monitor", then I agree. By "directly" I mostly wanted to express a general idea, not a precise implementation. I want the list of circuits to be available by clicking (somehow) on the green onion and not having to go through menus. That could be, from quickest to manipulate to the longest: 1. Clicking on the green onion opens a popup (like for Florence) with the list of circuits. That would be the most integrated solution but depends on the information in that popup to be dense enough. On your current screenshot for example, I'm not sure we should keep built but unused circuits. We might only list currently used circuits. I'm not sure either whether the detail of the relay need to be that complete. 2. Clicking on the green onion opens Tor Monitor is a window. 3. Clicking on the green onion opens a menu, and clicking on an item from that menu open Tor Monitor in a window. That's your solution if I understand correctly. But I'm not sure to understand what the menu brings, as "Tor is ready" is already the message provide by the onion being green. >> Top shell bar Onion >> | | >> v v >> [_Applications_Places__O_o_o_o_] >>A___ >> |Tor is ready| >> |Open Tor Monitor| >> ++ > >> Disconnected: striked onion > [...] >> Bootstraping: onion with dots (as when network is connecting) > [...] >> Connected: full onion > > IMO that should be thought through as part of #7437, and I haven't the > big picture and goals in mind (if the latter were defined at all yet), > so I won't comment on this part yet. Agreed. The big picture of #7437 hasn't been defined yet. Maybe at RightsCon :) Regarding the onion being monochrome to fit better in GNOME. Why not. That's interesting too but needs to be put in perspective with #7437. But I guess that changing the icon at some point in the future should be easy. -- sajolida ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] How to replace the green onion [was: What do we miss to replace Vidalia]
Hi, sajolida wrote: > intrigeri: > > Alan wrote (06 Mar 2015 21:12:43 GMT) : > >> sajolida wrote: > >>> I hereby propose to have the list of circuits accessible directly from > >>> the green onion as it is the case now in Vidalia. But I'm not sure how > >>> this fits with your architectural plans and related security implications. > > > > I'm not sure I understand what sajolida meant with "directly" in this > > sentence. If that's "clicking the onion icon directly starts Tor > > Monitor", or "clicking the onion icon opens a menu that proposes to > > start Tor Monitor", then I agree. > > By "directly" I mostly wanted to express a general idea, not a precise > implementation. I want the list of circuits to be available by clicking > (somehow) on the green onion and not having to go through menus. That > could be, from quickest to manipulate to the longest: > > 1. Clicking on the green onion opens a popup (like for Florence) with > the list of circuits. That would be the most integrated solution but > depends on the information in that popup to be dense enough. On your > current screenshot for example, I'm not sure we should keep built but > unused circuits. We might only list currently used circuits. I'm not > sure either whether the detail of the relay need to be that complete. I don't want to implement that. It's NOT easy at all to do for at least two reasons: - there is no JS or GIR to talk to Tor, but we can only use these languages easily from an extension; - we don't want the amnesia user to talk to Tor, but the extension runs under the Shell user. That thus means exposing just the right information through some safe IPC mechanism. So I's say: "no". > 2. Clicking on the green onion opens Tor Monitor is a window. > That's easy to implement, but I know no other extension that launches an application or display a window directly when clicking on it, so I'm afraid it would be confusing. > 3. Clicking on the green onion opens a menu, and clicking on an item > from that menu open Tor Monitor in a window. That's your solution if I > understand correctly. Right. > But I'm not sure to understand what the menu > brings, as "Tor is ready" is already the message provide by the onion > being green. > Right. So it only brings consistence with other extensions. [...] > Regarding the onion being monochrome to fit better in GNOME. Why not. > That's interesting too but needs to be put in perspective with #7437. > But I guess that changing the icon at some point in the future should be > easy. > Right. Cheers ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] How to replace the green onion [was: What do we miss to replace Vidalia]
Hi, sajolida wrote (10 Mar 2015 14:40:44 GMT) : > intrigeri: >> Alan wrote (06 Mar 2015 21:12:43 GMT) : >>> sajolida wrote: I hereby propose to have the list of circuits accessible directly from the green onion as it is the case now in Vidalia. But I'm not sure how this fits with your architectural plans and related security implications. >> >> I'm not sure I understand what sajolida meant with "directly" in this >> sentence. If that's "clicking the onion icon directly starts Tor >> Monitor", or "clicking the onion icon opens a menu that proposes to >> start Tor Monitor", then I agree. > By "directly" I mostly wanted to express a general idea, not a precise > implementation. I want the list of circuits to be available by clicking > (somehow) on the green onion and not having to go through menus. That > could be, from quickest to manipulate to the longest: Thanks! > 1. Clicking on the green onion opens a popup (like for Florence) with > the list of circuits. That would be the most integrated solution but > depends on the information in that popup to be dense enough. On your > current screenshot for example, I'm not sure we should keep built but > unused circuits. We might only list currently used circuits. I'm not > sure either whether the detail of the relay need to be that complete. IMO this one requires too much initial time investment, for something that a) exceeds what's needed to replace Vidalia without losing important features; and b) might not be what we want on the long run -- I mean, the UI may be what we want in the end, but to implement it, we need to first make technical decisions about the separation of concerns between the underlying programs, and it seems clear to me that any choice we could make right now has great chances to be wrong once #7438 is resolved, and then quite some work will have to be re-done. > 2. Clicking on the green onion opens Tor Monitor is a window. Seems trivial to implement. > 3. Clicking on the green onion opens a menu, and clicking on an item > from that menu open Tor Monitor in a window. Seems trivial to implement as well. > That's your solution if I understand correctly. I said I would be fine with it. I also said I agreed with "clicking the onion icon directly starts Tor Monitor", aka. the solution you call #2, so that's not "my" solution :) > But I'm not sure to understand what the menu brings, as "Tor is > ready" is already the message provide by the onion being green. I see two potential reasons why #3 might be better than #2: * a menu leaves us room to add stuff there later if we need to, without changing behaviour users have previously been trained to * interface consistency => behaviour that's more expected by users: all icons in GNOME Shell's top bar open a menu, and don't directly trigger any action... except some we've hackishly added there ourselves with the topIcons extension (Florence, Pidgin) Now, indeed #2 is faster to interact with. I'm personally undecided wrt. which one of these two is the best. Cheers, -- intrigeri ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] How to replace the green onion [was: What do we miss to replace Vidalia]
intrigeri: > sajolida wrote (10 Mar 2015 14:40:44 GMT) : >> 1. Clicking on the green onion opens a popup (like for Florence) with >> the list of circuits. That would be the most integrated solution but >> depends on the information in that popup to be dense enough. On your >> current screenshot for example, I'm not sure we should keep built but >> unused circuits. We might only list currently used circuits. I'm not >> sure either whether the detail of the relay need to be that complete. > > IMO this one requires too much initial time investment, for something > that a) exceeds what's needed to replace Vidalia without losing > important features; and b) might not be what we want on the long > run -- I mean, the UI may be what we want in the end, but to implement > it, we need to first make technical decisions about the separation of > concerns between the underlying programs, and it seems clear to me > that any choice we could make right now has great chances to be wrong > once #7438 is resolved, and then quite some work will have to be > re-done. Ok. >> 2. Clicking on the green onion opens Tor Monitor is a window. > > Seems trivial to implement. > >> 3. Clicking on the green onion opens a menu, and clicking on an item >> from that menu open Tor Monitor in a window. > > Seems trivial to implement as well. > >> That's your solution if I understand correctly. > > I said I would be fine with it. I also said I agreed with "clicking > the onion icon directly starts Tor Monitor", aka. the solution you > call #2, so that's not "my" solution :) > >> But I'm not sure to understand what the menu brings, as "Tor is >> ready" is already the message provide by the onion being green. > > I see two potential reasons why #3 might be better than #2: > > * a menu leaves us room to add stuff there later if we need to, > without changing behaviour users have previously been trained to > > * interface consistency => behaviour that's more expected by users: > all icons in GNOME Shell's top bar open a menu, and don't directly > trigger any action... except some we've hackishly added there > ourselves with the topIcons extension (Florence, Pidgin) > > Now, indeed #2 is faster to interact with. I'm personally > undecided wrt. which one of these two is the best. Neither am I :) -- sajolida ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] How to replace the green onion [was: What do we miss to replace Vidalia]
sajolida wrote (15 Mar 2015 19:46:47 GMT) : >> I'm personally undecided wrt. which one of these two is the best. > Neither am I :) Then I'm all for "those who do the work decide" — in this case, that would be Alan. Cheers, -- intrigeri ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] How to replace the green onion [was: What do we miss to replace Vidalia]
Hi, On Sun, 15 Mar 2015 23:29:55 +0100 intrigeri wrote: > sajolida wrote (15 Mar 2015 19:46:47 GMT) : > >> I'm personally undecided wrt. which one of these two is the best. > > > Neither am I :) > > Then I'm all for "those who do the work decide" — in this case, that > would be Alan. > Then there will be a menu I think. Cheers. ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] How to replace the green onion [was: What do we miss to replace Vidalia]
Alan wrote (18 Mar 2015 21:20:02 GMT) : > On Sun, 15 Mar 2015 23:29:55 +0100 > intrigeri wrote: >> sajolida wrote (15 Mar 2015 19:46:47 GMT) : >> >> I'm personally undecided wrt. which one of these two is the best. >> >> > Neither am I :) >> >> Then I'm all for "those who do the work decide" — in this case, that >> would be Alan. >> > Then there will be a menu I think. May you (or someone else) please encode this decision (and sum up the reasoning behind it) in a ticket, so that we don't have to retrieve it from a lengthy thread in the future? Cheers, -- intrigeri ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] How to replace the green onion [was: What do we miss to replace Vidalia]
Hi Alan, intrigeri wrote (01 Jul 2015 12:32:49 GMT) : > Alan wrote (18 Mar 2015 21:20:02 GMT) : >> On Sun, 15 Mar 2015 23:29:55 +0100 >> intrigeri wrote: >>> sajolida wrote (15 Mar 2015 19:46:47 GMT) : >>> >> I'm personally undecided wrt. which one of these two is the best. >>> >>> > Neither am I :) >>> >>> Then I'm all for "those who do the work decide" — in this case, that >>> would be Alan. >>> >> Then there will be a menu I think. > May you (or someone else) please encode this decision (and sum up the > reasoning behind it) in a ticket, so that we don't have to retrieve it > from a lengthy thread in the future? Ping? (FTR, 6 months later: I'll now stop tracking that the outcome of this thread is properly written down somewhere.) Cheers, -- intrigeri ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
