Project

General

Profile

Bug #8310

Bug #8309: Remove the topIcons GNOME Shell extension

Convert OpenPGP Applet into a proper GNOME Shell extension

Added by intrigeri almost 5 years ago. Updated 6 months ago.

Status:
In Progress
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
11/16/2016
Due date:
% Done:

37%

Feature Branch:
intrigeri/openpgp-applet:feature/8310-gnome-shell
Type of work:
Code
Blueprint:
Starter:
Affected tool:
OpenPGP Applet

tray-hidden.png View (22.8 KB) intrigeri, 03/24/2019 01:39 PM

tray-displayed.png View (23.7 KB) intrigeri, 03/24/2019 01:39 PM


Subtasks

Feature #11934: Have org.Tails.OpenPGPApplet send signals when the type of what's in the clipboard changesConfirmed

Feature #11935: OpenPGP applet GNOME Shell extension: allow encryption, decryption and signature verificationIn Progress

Feature #11936: OpenPGP applet GNOME Shell extension: dynamically update the icon & menu depending on the content of the clipboardIn Progress


Related issues

Related to Tails - Feature #7433: Turn Tails OpenPGP Applet into a standalone application Duplicate 06/22/2014
Related to Tails - Bug #16415: openpgp-applet dont want to start in VirtualBox (with VBoxVGA and 3D acceration enabled) Rejected 01/31/2019
Related to Tails - Feature #16531: Define our core code base In Progress 03/05/2019
Duplicated by Tails - Feature #14925: AppIndicator Support for OpenPGP Applet Duplicate 11/06/2017
Blocked by Tails - Feature #7711: Port the OpenPGP applet to GTK+ 3 Resolved 08/01/2014
Blocked by Tails - Bug #16608: Disable the topIcons GNOME Shell extension in one Tails release Resolved 03/23/2019
Blocked by Tails - Bug #16709: Re-add the topIcons GNOME Shell extension Resolved

History

#1 Updated by intrigeri almost 5 years ago

  • Related to Feature #7433: Turn Tails OpenPGP Applet into a standalone application added

#2 Updated by intrigeri almost 5 years ago

  • Blocks Feature #6507: Package our OpenPGP applet for Debian and maintain it there added

#3 Updated by BitingBird almost 5 years ago

  • Affected tool set to OpenPGP Applet

#4 Updated by intrigeri about 4 years ago

  • Blocks deleted (Feature #6507: Package our OpenPGP applet for Debian and maintain it there)

#5 Updated by alant about 4 years ago

  • Parent task deleted (#8309)

#6 Updated by alant about 4 years ago

  • Parent task set to #8309

#7 Updated by intrigeri about 3 years ago

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 about 3 years ago

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).

#9 Updated by intrigeri about 3 years ago

  • Blocked by Feature #7711: Port the OpenPGP applet to GTK+ 3 added

#10 Updated by intrigeri about 3 years ago

  • Status changed from Confirmed to In Progress
  • Assignee changed from nodens to intrigeri

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.

#11 Updated by intrigeri about 3 years ago

  • Target version set to Tails_3.0

#12 Updated by nodens about 3 years ago

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:

  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

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 !

#13 Updated by intrigeri almost 3 years ago

  • % Done changed from 0 to 10
  • Feature Branch set to intrigeri/openpgp-applet:feature/8310-gnome-shell

#14 Updated by intrigeri almost 3 years ago

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.

#15 Updated by intrigeri over 2 years ago

  • Target version changed from Tails_3.0 to Tails_3.2

I doubt I'll be able to do this in time for 3.0.

#16 Updated by intrigeri over 2 years ago

  • Target version deleted (Tails_3.2)

Let's discuss when roadmaping at the summit how high it should be on my list.

#17 Updated by nodens over 1 year ago

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

#18 Updated by intrigeri 9 months ago

  • Related to Bug #16415: openpgp-applet dont want to start in VirtualBox (with VBoxVGA and 3D acceration enabled) added

#19 Updated by intrigeri 8 months ago

#20 Updated by intrigeri 8 months ago

  • Assignee changed from intrigeri to sajolida
  • QA Check set to Info Needed

At this point it's unclear to me how much efforts we should put into OpenPGP Applet, at least as part of Tails "core work":

  • I don't know how the use cases that made us create this app (encrypting/decrypting arbitrary text) are still widespread. In particular, I suspect the "group communication via a shared mailbox with PGP/inline encrypted email body, using passphrase-based symmetric encryption" use case is less popular than it used to.
  • Among our primary & secondary personas, I guess that only Cris might use OpenPGP, but I bet they'd be using PGP/MIME in Thunderbird and not OpenPGP Applet.

So I propose we demote this ticket and remove it from the list of blockers for #8309 (and thus, transitively, for #11188 and #12213). It's the only blocker left according to Redmine.

@sajolida, what do you think?

What we'll decide here could inform the discussion on #16531. But we could as well do it the other way round, i.e. decide on #16531 based on the big picture, and then only updating this ticket's metadata.

#21 Updated by sajolida 8 months ago

  • Assignee changed from sajolida to intrigeri

At this point it's unclear to me how much efforts we should put into OpenPGP Applet, at least as part of Tails "core work":

Same for me.

I don't know how the use cases that made us create this app (encrypting/decrypting arbitrary text) are still widespread.

Going back to our doc (https://tails.boum.org/doc/encryption_and_privacy/gpgapplet/public-key_cryptography/), I think that the main use of the OpenPGP Applet is, in general, to be able to send OpenPGP encrypted text (symmetric or not) through web applications. For example, webmail (you can't use GMail & others from Thunderbird but probably from Tor Browser with 2FA) and online markets in bitcoins (what a periphrasis!) that recommend OpenPGP-encrypted messages between customers and merchants.

I bet it's the same kind of users that also flood our help desk with basic OpenPGP questions regarding the verification.

In particular, I suspect the "group communication via a shared mailbox with PGP/inline encrypted email body, using passphrase-based symmetric encryption" use case is less popular than it used to.

I think it's more asymmetric encryption without Thunderbird and the command line.

  • Among our primary & secondary personas, I guess that only Cris might use OpenPGP, but I bet they'd be using PGP/MIME in Thunderbird and not OpenPGP Applet.

Agreed. To me it looks pretty similar to the Electrum case: people more like Derya. Breaking things for them might lead to a lot of noise on our help desk and less bitcoin donations but it won't be much of a problem for our most important personas. It's a strategical decision we have to make.

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.
  • Move faster on #14545. Right now I'm focusing my UX work on following up on the front that I opened at the summit (#11162, #9814, #16539) but I could slow down on these and work on the survey "soon". Knowing more about your idea timeline might help.

#22 Updated by intrigeri 8 months ago

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 #14545. Right now I'm focusing my UX work on following up on the front that I opened at the summit (#11162, #9814, #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.

#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 #12213, which is 2020 material, so no big hurry on this front.

#23 Updated by intrigeri 8 months ago

  • Blocked by Bug #16608: Disable the topIcons GNOME Shell extension in one Tails release added

#24 Updated by intrigeri 8 months ago

  • Assignee deleted (intrigeri)

#25 Updated by intrigeri 8 months ago

#26 Updated by intrigeri 8 months ago

#27 Updated by segfault 8 months ago

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.

#28 Updated by intrigeri 8 months ago

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.

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

  • 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 #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.

  • 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.

#29 Updated by sajolida 8 months ago

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 #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 #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 (#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 8 months ago

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 #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 #16608 strategy if we mention in the release notes that the icon can now be found in the systray.

#31 Updated by intrigeri 7 months ago

  • 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 #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 #16608 with #16399 so this is not forgotten while writing the release notes for 3.14.

#32 Updated by intrigeri 7 months ago

@segfault, does this make you feel differently about the #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 #16608, we might decide that #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 #16608 strategy if we mention in the release notes that the icon can now be found in the systray.

OK, thanks!

#33 Updated by intrigeri 7 months ago

  • QA Check deleted (Info Needed)

#34 Updated by sajolida 7 months ago

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 #8310#note-21, and one that I care about.

#35 Updated by intrigeri 6 months ago

  • Duplicated by Feature #14925: AppIndicator Support for OpenPGP Applet added

#36 Updated by intrigeri 6 months ago

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?).

#37 Updated by intrigeri 6 months ago

  • Blocked by Bug #16709: Re-add the topIcons GNOME Shell extension added

Also available in: Atom PDF