Tails

#7 Updated by intrigeri 2016-08-29 02:17:40

I’ve had a very quick look. Assuming that we want to move or duplicate the least possible amount of code & functionality into the GNOME Shell extension, it seems to me that we could do:

• Give the openpgp-applet Perl program an additional operation mode, in which it would not display its “systray” icon nor handle any crypto operations, but instead would only monitor the clipboard and update a flag file whenever the clipboard content changes; the flag file should essentially contain the output of detect_text_type.
• Give the openpgp-applet Perl program an additional operation mode for each action it supports, namely symmetric_encrypt, public_crypto and decrypt_verify.
• write a GNOME Shell extension that:
  • displays an icon
  • monitors the aforementionned flag file, and updates its icon accordingly
  • when the icon is clicked, build & display an updated actions menu depending on the content of the flag file
  • when an action is clicked:
    • “Manage Keys” and “Open Text Editor” can be implemented directly in the extension
    • for other actions, run openpgp-applet ACTION (we don’t even need to pass any additional arguments since all actions operate on the clipboard, or need no parameter at all)

In other words, we would split the program into 3 components:

1. clipboard monitoring & flag file updating
2. GUI that provides feedback about clipboard state change, and allows to trigger actions
3. crypto operations backend

Alternatively, we can go the D-Bus way, which can be a little bit harder to implement for someone not at ease with D-Bus, but is nicer in that it uses higher-level IPC techniques instead of an ugly flag file:

1. Perl backend, providing a D-Bus service, that sends D-Bus signals when the clipboard changes, and receives D-Bus method calls as a way to trigger actions
2. JS GUI that provides feedback about clipboard state change, and allows to trigger actions

Regardless of which design we choose, it’s likely a bad idea to extend the current openpgp-applet program to add the functionality described above. It would become too big and badly organized to be maintainable => better start by moving to libraries the clipboard monitoring & text type detection code on the one hand, and crypto operations code on the other hand. Then whatever Perl components are needed in the new design can be written as 1 or 2 new, smaller programs… and the current “systray” openpgp-applet implementation becomes much smaller, and has greater chances to remain maintained :)

#8 Updated by intrigeri 2016-08-29 03:40:25

In order to avoid merge conflict hell later, any work on this should be based on top of the feature/7711-Gtk3 (in nodens’ openpgp-applet repo).

#12 Updated by nodens 2016-08-30 02:39:01

intrigeri wrote:
> I’ve had a very quick look. Assuming that we want to move or duplicate the least possible amount of code & functionality into the GNOME Shell extension, it seems to me that we could do:
>
> * Give the openpgp-applet Perl program an additional operation mode, in which it would not display its “systray” icon nor handle any crypto operations, but instead would only monitor the clipboard and update a flag file whenever the clipboard content changes; the flag file should essentially contain the output of detect_text_type.
> * Give the openpgp-applet Perl program an additional operation mode for each action it supports, namely symmetric_encrypt, public_crypto and decrypt_verify.
> * write a GNOME Shell extension that:
> displays an icon
> monitors the aforementionned flag file, and updates its icon accordingly
> when the icon is clicked, build & display an updated actions menu depending on the content of the flag file
> when an action is clicked:
> * “Manage Keys” and “Open Text Editor” can be implemented directly in the extension
> * for other actions, run openpgp-applet ACTION (we don’t even need to pass any additional arguments since all actions operate on the clipboard, or need no parameter at all)
>
> In other words, we would split the program into 3 components:
>
> # clipboard monitoring & flag file updating
> # GUI that provides feedback about clipboard state change, and allows to trigger actions
> # crypto operations backend
>
> Alternatively, we can go the D-Bus way, which can be a little bit harder to implement for someone not at ease with D-Bus, but is nicer in that it uses higher-level IPC techniques instead of an ugly flag file:
>
> # Perl backend, providing a D-Bus service, that sends D-Bus signals when the clipboard changes, and receives D-Bus method calls as a way to trigger actions
> # JS GUI that provides feedback about clipboard state change, and allows to trigger actions
>

Even though I’m not familiar with D-Bus (or JS / gnome-shell extensions for that matter), I’d really prefer to go that route. The flag file seems like a hack to me.

> Regardless of which design we choose, it’s likely a bad idea to extend the current openpgp-applet program to add the functionality described above. It would become too big and badly organized to be maintainable => better start by moving to libraries the clipboard monitoring & text type detection code on the one hand, and crypto operations code on the other hand. Then whatever Perl components are needed in the new design can be written as 1 or 2 new, smaller programs… and the current “systray” openpgp-applet implementation becomes much smaller, and has greater chances to remain maintained :)

ACK.

> I have some work in progress locally, and I’d like to fix that early in the 3.0 dev cycle (porting Tails to Stretch), so I’ll steal it from you.

ACK.

Cheers !

#14 Updated by intrigeri 2016-11-16 15:05:32

The backend side now provides a D-Bus service that exposes the basic functionality. Alan will write a GNOME Shell extension to expose it to the user. Then I’ll make the backend also monitor the clipboard and send signals that the GNOME Shell extension can subscribe to, in order to update its icon and menu dynamically just like the current Perl applet does.

#17 Updated by nodens 2018-02-25 18:22:47

Upstream Issue: https://salsa.debian.org/openpgp-applet-team/openpgp-applet/issues/4
Not closing here, since it’s related to some Tails work.

#22 Updated by intrigeri 2019-03-23 17:32:39

Thanks a lot for your feedback, you pointed out quite a few things I had not in mind :)

> If we want to have more info or try a few things out before making a firm decision we could:

> * Disable TopIcons in 1 release and see what happens. People could still enable it again with 1 command line. I’m not sure how we could measure how popular this workaround his apart from the noise on our help desk.

This is cheap and, I must say, very tempting. I bet the users of OpenPGP Applet will be very vocal so it should be easy to learn what they’re using it for. I’d be happy to help Help Desk collect this data so we can make a firm decision.

Better do this while we’re still running X.Org (i.e. before Tails 5.0), because presumably folks who really need TopIcons can install it and restart GNOME Shell to enable it (I didn’t test this); no huge deal if that’s not possible though IMO.

So I’ll go ahead and will file a dedicated ticket about this experiment, that we could run in 3.14.

> * Move faster on Feature #14545. Right now I’m focusing my UX work on following up on the front that I opened at the summit (Feature #11162, Feature #9814, Feature #16539) but I could slow down on these and work on the survey “soon”.

Nah, I don’t think my question is worth changing your current (and sensible) priorities.

> Knowing more about your idea timeline might help.

Bug #11188 has been blocked by this ticket for 3 years so arguably it’s not that urgent. Still, exposing all our users to that bug, merely to keep OpenPGP Applet for the (probably very) few people who use it, does not feel sensible to me. So I’d rather fix that sooner than later, i.e.: ASAP.

The other matter blocked by this ticket is Feature #12213, which is 2020 material, so no big hurry on this front.

#27 Updated by segfault 2019-03-24 12:25:18

There has just started a discussion on GNOME’s desktop-devel-list about reconsidering the systray removal, because it turns out users want systray icons and use extensions (like TopIcons) to get them back:

https://mail.gnome.org/archives/desktop-devel-list/2019-March/msg00020.html

Maybe we should hold our horses here to see if we might be able to keep the OpenPGP Applet with it’s systray icon after all.

Also, in general, I much dislike the “break things for the users and see how much it hurts” approach. Tails has enough usability issues as it is. Asking them to first use the command line every time they boot Tails in order to use the OpenPGP Applet seems like bad UX to me. My guess is that for most users it will be so painful that they will change their workflow anyway, so that’s almost as bad as just removing it forever.

I would prefer other solutions:

* Tell users on our website / in the release notes that we consider removing the OpenPGP Applet because it’s hard to maintain and we don’t know how many users actually use it, and that they should reach out to us if they want us to keep it and maybe tell us about their use case.
* Consider asking users to opt-in (or even opt-out) to anonymized usage statistics. For most applications this could be implemented by a simple wrapper script which sends a ping whenever the application is started. In the case of the OpenPGP Applet it’s a bit more effort, but something like this could generally help us to make more informed decisions.

#29 Updated by sajolida 2019-03-27 11:41:46

>> Also, in general, I much dislike the “break things for the users and see how much it hurts” approach. Tails has enough usability issues as it is. Asking them to first use the command line every time they boot Tails in order to use the OpenPGP Applet seems like bad UX to me.
>
> Oops, I forgot something: disabling TopIcons does not prevent using OpenPGP Applet. Its systray icon is in the bottom-left tray. Granted, it’s “a bit” hidden by default and thus poorly discoverable. But once one knows it’s there, there’s nothing that prevents them from using the OpenPGP Applet. See attached screenshots.

Oh! I like that even more.

And of course, I agree with segfault that breaking stuff to see how
people react is not nice. I’m glad he helped us coming up with other
solutions :)

> @segfault, does this make you feel differently about the Bug #16608 strategy?

I didn’t think either about the hidden system tray.

At first sight, it even looks like a decent solution on the long-term.

>> * Tell users on our website / in the release notes that we consider removing the OpenPGP Applet because it’s hard to maintain and we don’t know how many users actually use it, and that they should reach out to us if they want us to keep it and maybe tell us about their use case.
>
> I have doubts we’ll gather much useful info this way but it’s cheap so we could try it. Actually, I would suggest we do Bug #16608 and in the release notes for that version, we document how to reach the OpenPGP Applet and ask folks to tell us what they’re using it for. This way, that call for feedback should reach exactly the people we want data from: those who already know about that applet and use it already.

Both segfault’s and intrigeri’s proposals work for me.

>> * Consider asking users to opt-in (or even opt-out) to anonymized usage statistics. For most applications this could be implemented by a simple wrapper script which sends a ping whenever the application is started. In the case of the OpenPGP Applet it’s a bit more effort, but something like this could generally help us to make more informed decisions.
>
> Yeah, metrics! I’m pretty sure sajolida will be happy to read this :) I think this would be worth a dedicated ticket where we can discuss this.

Wow, I’m glad and very surprised that I’m not the first one to propose
something like that :) Getting more metrics from inside Tails is
definitely something I want to explore more. But it’s also not something
that we will have before 4.0 and it might come too late to help us on
this particular discussion.

I envisioned the survey (Feature #14545) as faster and cheaper way of getting a
first glimpse at these things. It won’t be as accurate and detailed but
could help us know, for example, what percentage of our users use
OpenPGP in general for example.

#30 Updated by segfault 2019-03-28 23:33:22

> Oops, I forgot something: disabling TopIcons does not prevent using OpenPGP Applet. Its systray icon is in the bottom-left tray. Granted, it’s “a bit” hidden by default and thus poorly discoverable. But once one knows it’s there, there’s nothing that prevents them from using the OpenPGP Applet. See attached screenshots.
>
> @segfault, does this make you feel differently about the Bug #16608 strategy?

Right, in the gnome-shell version in Stretch there is still the system tray. Note that this was removed in gnome-shell 3.26, so this won’t be a long-term solution.

I find the system tray pretty ugly UI and UX wise, but at least it will be easier for users to keep using the applet (easier than typing a command in the terminal).

I’m generally not happy about removing the top icons, but after reading the email thread on desktop-devel-list, it seems like there is no solution in sight to have top icons in wayland, and if there will be support at some point it will use a different API, so legacy applications won’t be able to use them :(

Anyway, I’m fine with going ahead with the Bug #16608 strategy if we mention in the release notes that the icon can now be found in the systray.

#31 Updated by intrigeri 2019-04-08 10:02:24

>>> * Tell users on our website / in the release notes that we consider removing the OpenPGP Applet because it’s hard to maintain and we don’t know how many users actually use it, and that they should reach out to us if they want us to keep it and maybe tell us about their use case.
>>
>> I have doubts we’ll gather much useful info this way but it’s cheap so we could try it. Actually, I would suggest we do Bug #16608 and in the release notes for that version, we document how to reach the OpenPGP Applet and ask folks to tell us what they’re using it for. This way, that call for feedback should reach exactly the people we want data from: those who already know about that applet and use it already.

> Both segfault’s and intrigeri’s proposals work for me.

I’ve linked Bug #16608 with Feature #16399 so this is not forgotten while writing the release notes for 3.14.

#32 Updated by intrigeri 2019-04-08 10:03:42

>> @segfault, does this make you feel differently about the Bug #16608 strategy?

> Right, in the gnome-shell version in Stretch there is still the system tray. Note that this was removed in gnome-shell 3.26, so this won’t be a long-term solution.

Right. Depending on how it goes on Bug #16608, we might decide that Bug #8310 is a blocker for 4.0, or to bring back topIcons, or that we should remove OpenPGP Applet altogether.

> Anyway, I’m fine with going ahead with the Bug #16608 strategy if we mention in the release notes that the icon can now be found in the systray.

OK, thanks!

#34 Updated by sajolida 2019-04-26 10:12:58

This week-end I spoke to a bunch of hardcore Tails users who use it to publish on an alternative media website. One of them told me that they use OpenPGP but don’t use Thunderbird because they use Tails to connect to many different mailboxes and using Thunderbird would link them. Whether this is true or not is not really the point here: it probably does link them a tiny bit if Thunderbird fetches all the different mailboxes in a batch or make it easier to do mistake and send emails from the wrong mailbox. But I inferred that they used OpenPGP Applet for their encrypted emails, a concrete use case of what I described in Bug #8310#note-21, and one that I care about.

#36 Updated by intrigeri 2019-05-02 08:10:16

Before spending much more time on the OpenPGP Applet GNOME Shell extension front, I think we should investigate whether adding AppIndicator support + Ubuntu’s https://extensions.gnome.org/extension/615/appindicator-support/ (aka. https://github.com/ubuntu/gnome-shell-extension-appindicator) would be cheaper and suitable (e.g. does it work on Wayland? including allowing user interaction, not just displaying a status icon?).