securedrop
securedrop copied to clipboard
freedomofpress
Consider switching to a GNOME Shell Extension rather than using deprecated Desktop launchers
Description
Right now, after SecureDrop is setup on an Admin Workstation Tails USB, we place a couple symlinked .desktop launchers inside of /home/amnesia/Desktop, which allows the user to easily access the various interfaces with a single click.
A while ago, GNOME removed .desktop icon support, and began to discourage developers from targeting this paradigm. Functionality has been added back in thanks to GNOME Shell extensions and some upstream changes to Nautilus to make everything work, but desktop icon support is still a bit of a hack.
They also have caused us issues in the past, where they have either not displayed correctly (you can find Nautilus' maintainer referencing the workarounds in this thread): https://github.com/freedomofpress/securedrop/issues/2586
Or, as it is now, they are not clickable on first boot until a connection is established and our script resets trusted permissions: https://github.com/freedomofpress/securedrop/issues/5728
I believe it makes sense to forgo the .desktop icon route, and instead make use of a GNOME Shell extension which we can set to load from Persistence. It has the following benefits:
- Places launchers in the top left, where users already expect applications to live
- The launcher is functional as soon as the system boots without relying on additional scripts
- It relies on a relatively stable API that is consistent between GNOME Shell versions (the extension I created has been tested on gnome-shell 3.38.6 through 4.2, so should continue working on future Tails releases for years to come)
- It looks pretty good :)
I went ahead and created an extension, and tested it locally, as well as within Tails. The screenshot above gives you an idea of how it looks. I'll attach a video which shows it in action, on Tails on my production Admin Workstation USB (I didn't have a network connection, but you can see it launching Tor with the address of the instance in the URL bar):
https://user-images.githubusercontent.com/6131358/187796240-989e16e6-56c6-43df-a3c8-7d8ac36d49af.mp4
I'd love to hear others' thoughts about whether or not this makes sense for the project moving forward. If anyone wants to take it for a spin, I'm attaching the extension I made here. To install it, from a Tails Terminal you can run:
gnome-extensions install [email protected]
gnome-extensions enable [email protected]
You'll need to press Alt + F2, then type r, then type enter, after each command above. After that, you should see it loaded in the top left.
If you have questions about those changes, how it works, or how to get it running, please don't hesitate to ask. :)
User Research Evidence
User Stories
As a user, I want a more robust and reliable way to access my SecureDrop interfaces when I load the Admin Workstation.
I have little context on the usage of the current .desktop launcher, but I find this case extremely compelling and love the idea of following current standards and recommended practices where they exist. :100:
I'm super in favour of this! One caveat is that the JI will still not be accessible until our script runs, as some Tor config changes need to be applied.
Would it make sense to add in other menu items? (ie a GUI updater launcher, and maybe app/mon ssh terminal sessions for the Admin workstation case?)
I want to join the choir of praise, I love it!
Re: the order-of-operation implications for JI access etc… because extensions are pretty flexible, we can definitely distinguish between configured/not-configured and adapt the UI accordingly. As to what that should look like I think is a discussion (sync or async) that might not even take that long!
A different topic altogether though: I know, it's not quite the same as the server/monitor setups and Tails bits aren't quite in the same ballpark, but since the kernel packages are moving out of this repo, I wonder where new additions like this should live?
@eaon see https://github.com/freedomofpress/securedrop/issues/3502 for historical discussion. Also in favour, especially if we can eventually deploy the same package on a hypothetical Qubes admin AppVM.
Thanks for the feedback, everyone! I'm excited to have some of these larger discussions, especially about further extending the capabilities and improving the design!
Just to echo what @eaon mentioned about the flexibility here, each entry in the submenu can trigger a command or launch a script, so we can get pretty creative about what we add, and how we implement it so that it reacts to the various system states.
I generally think it's a good idea to move beyond the deprecated desktop shortcuts. However, as much as the Gnome team may be convinced desktop shortcuts should be retired, many people who grew up on mobile smartphones and tablets have been used to "grid of app icons and app name underneath icons" as a UI paradigm so I kind of wish they would continue to be supported, since it's the least confusing way to open an application in my observations of some users. At a Tails training several years ago, a few people seemed a little confused by the Applications menu, and asked "why are the apps all in different places [menus and submenus]?" while sifting through menus trying to find what they were looking for. This shell extension wouldn't have the same problem since there's only two options but I wonder how noticeable it would be to users who aren't used to using computers that way (even some IT teams I've previously worked in add desktop shortcuts on work computers to avoid support calls on how to navigate a series of menus and click-to-show submenus to get to a specific app).
I think @huertanix is making a very good point, and I too can say that while I personally embrace the "type the first few characters first" approach to launching apps in GNOME, I also know for a fact that people I know remain confused by the absence of app icons.
While, the GNOME Shell Extension arguably goes one step towards increased discoverability, I think @huertanix's point remains very valid. That makes me wonder if we're in a either-or situation, or if we could embrace the GNOME Shell Shortcut while also keeping the .desktop launcher. (:grimacing: Sitting on my own feelings about using deprecated standards, in favor of acknowledging that maybe such deprecation could be somewhat premature, and that if it was, I'd rather assume the extra burden of maintaining the .desktop file in addition to the GNOME Shell Extension, than excluding people unintentionally.)
What do you think @nathandyer?
@huertanix I appreciate you bringing this perspective into the conversation! These are definitely good points that I think are worth considering, and @gonzalo-bulnes's point that it might not be an either-or situation may certainly be the right approach (although I do have reservations about the additional maintenance burden where there would then be two places for things to potentially break).
I'm not sure that I can be entirely objective on this one, since I did play a small part in helping to kill the concept of desktop icons in general (working on elementary OS and collaborating with GNOME back when those decisions were being made). I admit significant personal biases up front :)
I do think this is something that will need to be discussed as a larger group to get other folks' perspectives on it, but just to provide my own opinion here, when I think about it I don't see the new paradigm being particularly confusing for new users. Unless someone is already experienced with Tails or other operating systems that use the GNOME Desktop, they're already going to be in an unfamiliar environment. Having one button that's permanently visible that they know they can access for all the SecureDrop related functions would cut down on how many areas of the OS they need to explore and how many new features they need to understand. In the initial prototype for this extension I only had the two source interface links, but since then I've added shortcuts for SSH'ing into the servers, and have links to the KeypassXC manager. We can add in any other launchers or shortcuts we want to this submenu that we think would be helpful.
This option would mean most users (especially journalists) never have to understand where to find the rest of the apps, or even open the overview. Everything they need could be found within this one menu, labeled "SecureDrop" for maximum clarity. Only the admins setting up the initial servers/USBs would have to look elsewhere, during the initial setup. Even in the most extreme cases though, I'm not sure this change would throw them off. A large portion of users would be coming from systems like iOS/iPadOS/ChromeOS, or even macOS, which have either partially or completely eliminated desktop icons from their platform. That said, for admins who have mostly been using Windows, this would certainly be a departure from the norm for them.
Thanks for the summary and the prototyping work on this so far, Nathan!
My preference would be to avoid a situation where we have to maintain two systems, so I would recommend that we make a call in favor of either the icon-based approach or the menu-based one.
I think the argument that we can exercise more programmatic control over disabled/enabled status, more easily add other custom shortcuts, etc., is a pretty good one in favor of the menu-based approach. However, given the UX concerns David mentions, at the very least I think we'd have to carefully message this change to our users.
I'd suggest we chat a bit more about this when folks are back from travel. @tina-ux I would also appreciate your input on this issue. :)
We have kept the desktop icons working (with kindof a degraded user experience - they don't work or display correctly until the network is up) via a succession of dirty hacks, Even with @huertanix' concerns, I'm still very much in favour of this change as it cleans those up and puts us more in sync with the Tails UX.
I think @huertanix 's point is a very good one, and worth keeping in mind. That being said, knowing that the desktop icons are not a stable solution in the longer term, that both icons for the journalist interface and source interface look the same, and that a gnome extension would add a dedicated and dynamic menu on which we can expand, I would be in favor of this change.
Edit: Good job Nathan!
I'm posting an updated version of the demo extension I created, which has lots of small tweaks to allow for deeper discussion at the hackathon. Changes to this version include:
- Most of the actions are now either completely functional, or partly functional
- Updated and tested to work on GNOME 43 in case any hackathon participants are already running the latest GNOME desktop
- Namespace changed to no longer include my email
- General clean-up for wider visibility
Looking forward to chatting with any interested folks during the hackathon!
Download the latest version here
It's worth noting that our current attempts to support desktop icons via the csoriano extension also trigger a warning message (not visible to the user) when this line in the network hook runs:
"Reloading extensions does not work correctly and is no longer supported"
The functionality does appear to still be working for now.
An observation that may be relevant from a previous training: An SD admin was attempting to show a new SD user how to open Nautilus/the file explorer in Tails in order to look for the connected Transfer device and mount it. The admin only knew of the Applications menu and never seemed to notice the Places menu right next to it until training specifically pointed it out.
