[Tails-dev] How to replace the green onion [was: What do we miss to replace Vidalia]
Hi! 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. > Now, I do appreciate that you have a strong vision for what Tor > Monitor should be, and this is very useful to avoid feature-bloating > it :) > > > - 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. > > Ah, right. And glad you find it potentially funny :) > > IMO, that Shell extension could very well be shipped in the same > upstream project as Tor Monitor, at least to start with: it would > benefit GNOME Shell users who would only have to install one single > package to get everything they need. And it wouldn't prevent the DBus > interface from being well-documented, stable, and re-usable by other > kinds of user feedback providers, be them desktop indicators > or whatever. > That makes sense. > > 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. 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. > (/me enters Alan's-mind-reading mode, let's try to guess what your > answer could be :) > > 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. > and sends DBus signals that e.g. a GNOME > Shell extension can receive and then provide feedback to the user. > I can see why there is no technical reason to couple this specific > feature with the rest of Tor Monitor's codebase. However, splitting it > out has a few clear disadvantages: > > 1. That's one more (presumably Python) process to run, which eats > memory etc. If there were a Tor controller C library, we could use directly from the extension through GI by writing a .typelib file for the interfaces we need. However, I didn't find such a library. So yes, we'd need a Python (of whatever language that has a Tor controller library) process running. > 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... > 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. > 3. For anyone who runs both Tor Monitor and that backend process, > we'll be putting additional load on the Tor control port. No idea > if/how it's measurable in practice, perhaps Stem's polling loop is > so efficient that it's not. > No idea either. > 4. That's one more upstream project to manage, release, tag, package, > import, etc. => not sure the overhead is worth it. > Good point. > 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 hel
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.
