Re: [Tails-dev] How to replace the green onion [was: What do we miss to replace Vidalia]

2016-01-03 Thread intrigeri
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.

Re: [Tails-dev] How to replace the green onion [was: What do we miss to replace Vidalia]

2015-07-01 Thread intrigeri
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]

2015-03-18 Thread Alan
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]

2015-03-15 Thread intrigeri
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]

2015-03-15 Thread sajolida
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]

2015-03-15 Thread intrigeri
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]

2015-03-15 Thread Alan
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]

2015-03-10 Thread sajolida
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]

2015-03-07 Thread intrigeri
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]

2015-03-06 Thread Alan
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]

2015-03-05 Thread sajolida
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]

2015-03-03 Thread intrigeri
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]

2015-03-01 Thread Alan
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.