Select Page

Need: Since its 2013 launch SecureDrop has earned accolades for the protections its offered whistleblowers and journalists. It’s been adopted by major NGOs and newsrooms around the world to communicate with anonymous sources, with best-in-breed security. Its user & maintenance experience have been a Rube-Goldberg’esque burden for the high-risk humans dependent on it, though.

Response: In 2017 the SecureDrop team architected a radical simplification of the hardware required to support a Journalist user’s experience—utilizing a virtualized Linux environment called Qubes OS. In 2018 the non-profit that stewards the SecureDrop project, Freedom of The Press Foundation (FPF), hired me to work with them in shaping a new experience for journalists using SecureDrop, within Qubes OS; a project since named The SecureDrop Workstation.

— Case study in progress. It may read a touch awkward or incomplete. —

Unpacking who our end users are and what they need from SecureDrop—beyond not landing themselves or their sources in jail or at a morgue—was the jumping-off point into my first open source project.

Free and Open Source” means that even the The New York Times gets SecureDrop for free—and while a handful of newsrooms do pay for premium support, their few journalist users of SecureDrop are intentionally kept from contact with FPF support engineers. Add to that the frenetic pace of most newsrooms, and recruiting for user research was a challenge from the start. On past enterprise projects, it was always an option to just hit up some customers for users to learn from. Time is the most precious of all resources for journalists, it turns out; later, its own design research finding.

At 2018’s Internet Freedom Festival a group of volunteers had crowdsourced interviews with attending journalists, leaving transcripts to be synthesized. These proved to be a terrific trove of information ready to devour for an initial report to build forward momentum from. Freedom of The Press Foundation’s security trainers had trained many SecureDrop users, and what they’d been able to observe was also helpful to learn.

Early sketches and prototypes felt deceptively simple. It’s really just a communications client like Email or SMS, right? Not really.

Each SecureDrop instance has a single “Inbox” for all sources (whistleblowers, in newsroom jargon). So, all SecureDrop journalist users within an organization (typically 1-5) share the same inbox and a single conversation thread with each source. Journalists are also corresponding with anonymous sources “named” in the UI with two-word phrases such as Benign Artichoke or Deviant Potato. Names that at times are laughably funny, but also work against the more natural name:story matching patterns our brains have developed in other correspondence contexts.

All of this and more was observed in bi-weekly user research sessions; sessions with both new and existing users and conducted either as remote interviews, or as remote screen sharing sessions observing folks navigate the latest Invision prototype.

For the first ~6 months, prototyping for rapid learning was the focus of the team’s work. In parallel to my UX prototyping, developers were building the most minimum-viable-anything in QT, an SDK for projects developed in Python. The goal of that work was to give the team an opportunity to observe the performance of this new system architecture as our users might. QT was a framework the entire team had zero experience with, at the start of the project. Electron (what Slack and many other desktop clients) is a more familiar Python SDK in the desktop world, however is prone to security vulnerabilities that made it less desirable.

At the outset of my earliest design work I sought to learn more about native QT widgets to explore an aesthetic “gapfill” design direction to keep frontend implementation overhead low. QT is a notoriously… err, “clunky” frontend framework, reminiscent of Windows 93 or Eclipse widgets, in its aesthetics—so that would have been its own labrynthic maze of learning.

The team could not make the mental leap to see any such design direction as better than a “polished turd” however, and since QT’s documentation suggested CSS and customization capabilities to be more generous than we later learned to be true, a fully bespoke solution was sought. The existing web product was also young in its lifecycle, with a piecemeal and problematic UI in need of an overhaul—so the Workstation project also served as the beginning of a cross-platform design system.

SDK gymnastics, inter-VM communication affordances, the tedious points of security, and backend/frontend design choreography to deliver a fluid experience had the whole team learning together about what was and was not possible in our unique technology environment. In production, all connectivity is done over the Tor network, which is notoriously slow and can be prone to outages. While our uncommon architecture had been validated in whitepapers and security reviews, its performance remained an unknown—and performance is a critical experiential factor.

It was decided early that building a beta version for a limited pilot and learning from real users was essential to better understand the system architecture’s practical nuances. The opportunity to also learn from users which features were esoteric vs basic, how security concepts were understood or obfuscated by the UI when managing true risks, and where potential value might be in workflow-enhancing capabilities, were also identified and embraced as an opportunity to bring focus to our unusually lean development org.

From our technical prototype early value was delivered when it was observed that even simple API/server-call tasks we take for granted with IMAP email could take several seconds, and that large files automatically downloading in the client would create a performance bottleneck. What might this experience actually be like for non-technical journalist users felt like more of a distant mystery, the more we learned leading up to the pilot.

We had expected the real star of the SecureDrop Workstation experience to be the radical simplification in hardware made possible by Qubes (2 devices vs 5, for journalist users)—and how that would enable users to fluidly download, consume, create, and share content, all from the same device. What that “simplification” could look like in reality, though, and the unknown tradeoffs, became harder and harder to not become distracted by, the longer our preliminary development extended.

Pandemic pilot ≠ fun. The pilot had been planned meticulously for months in advance. Just a few weeks before we launched, offices and cities everywhere shut down with COVID’s global onset. In-person installation, training, and user research, all had to pivot to remote—which for a highly technical product, was no easy feat. Two organizations had to delay their participation, and the research plan with its carefully timed events and dependent success measures, needed to be re-thought.

My own love of ethnographic observation had already been challenged by the hard reality that viewing our users consuming whistleblower content was not a risk that I was willing to take, nor an ethical ask to make of our journalist users. Now the team had to make what already felt like Olympic leaps forward, go farther, with making it all work remotely.

The workplace shifts everyone experienced with COVID later changed the features needed by our users. Teams no longer being co-located, journalist users no longer had the ease of access to an IT person for sanitizing files they’d hand-off on a USB stick, as was the procedure in most orgs before COVID. In response to one customer request and observed behavior among others, the team began exploring how to export files directly from the SecureDrop client and in to other VMs within Qubes—so journalist users could potentially do file sanitization on their own.

The below video was captured from a UXPin prototype I created, to demonstrate a potential file sanitization workflow the Workstation would build-in for journalists to use without specialized knowledge. Sharing videos from functionally-rough prototypes turned out to be a lifesaver adaptation to my own workflow, with COVID limiting in-person team and user access. The above spreadsheet for post-session synthesis between myself and a partner in user research, however, remains a team favorite adaptation of in-person processes.

Learning as lemonade. Many adaptations were made by everyone before, during, and post-launch. Our team’s adaptations to the pilot were informal and less structured than what had been planned at the outset. Our users were adapting their own day to day routines right there with us. Yes, it really (really!) hurt letting-go of the meticulously detailed, methodically paced research plan with its many activities that I had developed across numerous thoughtful and engaging review sessions with the team. And yet,  the informality and camaraderie that unfolded between our users and the FPF support team from everyone sharing these “new normal” adjustments, led to what felt like more candor than usual from pilot users, as well as an increased willingness to try new things. All quite a lot of fun, actually.

The pilot was re-structured from 3 organizations in parallel over 4 months, to three distinct phases that were each flexible in launch dates and duration. Only a few weeks into the pilot’s first phase and with only one customer, the Workstation’s ~2/3 reduction in active-time-on-task for journalist users emerged as its high point. The experiential fluidity created by eliminating decryption as a manual step between 3 different devices, and journalist users now having visibility into conversations (versus a series of sequential encrypted files) emerged as runner-up high points.

Time-on-task is a whole other impact factor when felt so viscerally by end users in software tasks (versus the standard proof-of-value metric executives like to see), it turns out. So much so, that the team was pushed to examine our Source experience more closely (which had me dancing for joy)—and everyone will benefit, in the long run. We also refined our ToT metric to measure active time-on-task, because users reported back that they actually didn’t mind absurdly long update processes. Much as the long updates made the dev team cringe. As long as users could hit the buttons at the beginning, and then walk away for half an hour (or whatever) to then return to a completed update, it really didn’t matter to them.

With active task times so dramatically improved, engagement with sources was also improved, as was the general ease in communication with newsroom reporters not using SecureDrop. It cannot be over-stated how important and vital both of those loops are; to internal newsroom teams, and to not losing important sources.

Some context on how sources access SecureDrop: In order to safely access SecureDrop, sources are advised to find a public wifi and log in from a machine they personally own (so, not a work laptop), or go to a public library. There no mobile integrations such as notifications, and because sources must use Tor Browser and legitimate tip submissions are unlikely to be stored on cloud drives, a laptop is required. These burdens for sources make it especially critical for journalist users to respond to sources as quickly as possible—either in conversation, or with initial tips. When sources are in danger, especially, weeks or months can pass between when they are able (or just have the courage) to check their SecureDrop.

Existing Workstation features built into the MVP received the feedback and insight sought from being put into the wild, to inform prioritization of improvements. The not-insignificant backlog of features and enhancements yet to be built have also received a healthy volume of feedback against, to inform their prioritization. Support engineers gained unplanned insight into how the Workstation worked with home internet routers, and were pleasantly surprised to learn that only a few bits in the docs needed updating. That otherwise, it’d be smooth sailing for journalist users wanting to work from home.

4 years is a long time to bring a project to market, especially for a team that is only 1-2 full-time and 3-5 part-time developers—with only one of those folks, full-time on the Workstation project. There were many assumptions before users had a chance to use the Workstation everyday. How a pilot run of a product brings early team assumptions down to reality, is always fun to experience.

~18mos into piloting the Workstation (at the time of this writing), and use of the Workstation has finally extended its reach to the full set of participant organizations planned in the days before mask-wearing was a social norm. With the newer organizations, of course, different user and infrastructural customer needs have surfaced. Some of those needs have been artifacts of how each org has adapted to remote work, however more have had to do with how each team is staffed and what the broader organization’s workflow needs with investigative projects have been, all along. Why we chose those organizations at the outset, and why it’s so important to pilot new enterprise and B2B2C products.

Features of the SecureDrop experience for newsrooms that overlapped between the legacy journalist experience and the Workstation, were also learned about in far richer detail than previously understood. So much so, that at one point Workstation development was paused to reconsider a years-old feature, as the team’s understanding of how the feature performed in the wild was informed by visibility made possible through the pilot. Multiple other core product features have also been reconsidered—and overall, the team has relished this access to users. 

While the Pilot still continues with important learning opportunities ahead, the most critical questions FPF sought to learn from the Pilot have been answered: Should the Workstation project continue development as the next-generation newsroom experience for SecureDrop? Absolutely, yes. Is Qubes OS the right environment for this new SecureDrop experience? Yes. But, with work.

 

In December of 2019 I began work with the Qubes OS team in a volunteer capacity (with FPF’s support). In January of 2020 I went to Europe and met with the core Qubes folks to workshop through product and UX needs, and in March proper funding was secured. I’ve since maintained a dual presence working on both projects; my access to users in the SecureDrop Workstation pilot, essential to informing my work with Qubes. My work with Qubes and my connection to its team, a helpful conduit back to the SecureDrop team.

In August of 2021 I presented at the Qubes Mini-Summit (beginning at the 29:40 mark) the work that had been funded in 2020. Presenting about UX to developers is quite different from presenting about UX to other designers, and I had a ton of fun. Two presentations, the first on my own and the second co-presented with Qubes developer Marta Marczykowska-Górecka.

Returning to Workstation outcomes: when asking Is the SecureDrop client itself headed in the right direction? The answer to that was also Yes. However, its companion “Updater” app was only built as a stopgap for the pilot. While performance issues have greatly improved over the past year, working with users was able to produce formal affirmation of what all Mac users already know: that in fact, multiple updaters is a completely sucky experience for users, no matter how they’re sliced.

As a non-profit project always hustling to get more funding, there is value for funders in capturing opportunities that fit neatly into new grant asks. Collaboration with the Qubes team is subsequently in the works to explore opportunities for a single updater experience that Qubes would ship with, and would support 3rd party apps while also allowing for per-app customization of Qubes’ RPC policies.

Separate from the Workstation project, a lot is already known about community reported needs for their updater experience—and the two projects coming together with additional findings from user research from the Workstation project, will make the resulting design work and funding ask stronger. I’m continuing my work with the Qubes team to help them resolve many of the known UX papercuts that impact all users of Qubes, such that we can lower the bar for Qubes adoption for non-technical users with or without SecureDrop.

The maintenance and installation experiences for Qubes also need a good deal more work before Workstation customers will be able to self-sustain. What more the Workstation does need to make that final leap into GA readiness has also been made clear to the development team—so budgets can be drawn-up, and grant applications written. All of which, has value.

Finally, apart from “Should this continue?” is the question: “Should what already existed, be retired?” For better and for worse, not just yet. While the team has made leaps and bounds with improving customer team trainings, documentation clarity and thoroughness, installation protocols, and optimizing the Workstation’s underlying architecture for performance—and the two client applications have come so far—some mountains have yet to be climbed, to realistically reach GA readiness.

A solid enough ratio of SecureDrop’s existing ~70 newsroom customers need to be able to reliably use the Workstation without the 24/7 access to support engineers our Pilot customers have had. Likewise, global supply chain shortages have made acquisition of Qubes compatible hardware hardened to the highest security standards, quite difficult.

New organizations are still being learned from, a not-insignificant backlog of issues informed by user research and design to date lies ahead for developers, and new funding has made a larger staff of paid developers for SecureDrop possible to carry the project over the finish line in tandem with the legacy product.