Need: Since its 2013 launch SecureDrop has earned accolades as a security and privacy centered communication platform for 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.

Approach

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. Unlike enterprise projects, access to end users of SecureDrop was limited—so early discovery drew from a combination of emailed surveys to users and non-users, synthesized crowdsourced research from an open source tech event, and interviews with FPF’s security trainers.

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 as either remote interviews, or as remote screen sharing sessions conducted while observing folks navigate our latest Invision prototype (new prototypes were generated almost weekly).

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 within our unique technology environment. In production, all Workstation 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 for a thing to both not suck, and to shape its user expectations management.

Value was quickly delivered from an early technical prototype when it was observed that even simple API/server-call tasks we take for granted in IMAP email experiences, could take several seconds in the Workstation. Likewise, that large files automatically downloading in the Workstation’s client would create performance bottlenecks.

Iterative technical and design prototyping at the “two steps forward, one step back” pace continued for months with our tiiny development team (also learning a new-to-all-of-us frontend framework), until we hit what felt safe as a Minimum Valuable Product point—with adequate usability for non-technical journalists—for moving into the Workstation’s pilot with newsroom customers.

Pandemic pilot ≠ fun. A limited pilot had been planned meticulously for months in advance. Just a few weeks before our planned launch, 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 planned methods, timed events, and dependent success measures, all needed to be re-thought.

The workplace shifts everyone experienced with COVID 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 to sanitize files from SecureDrop; a process that would have the journalist export files to a USB stick on the Workstation, to then hand-off to the IT expert in person—as was the procedure with the existing air-gapped experience (see diagram at top of page). In response to one customer request and observed behavior among others, the team began exploring how to export files directly from the SecureDrop client’s VM into other VMs, within Qubes, where a sanitization playbook could then automagically do the work for the journalist—so our non-technical users could potentially do file sanitization on their own. While this had of course been brainstormed as an opportunity early-on, COVID needs re-prioritized this feature from “Wow, cool!” to “Yep, essential.”

The below video was captured from a UXPin prototype I created, to demonstrate one potential file sanitization workflow the Workstation could build-in to support journalists 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 partners in user research, however, remains a team favorite adaptation of in-person processes.

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.

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.

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.

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.

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 to support my work with them in a deeper capacity. 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.

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, we were able to affirm with evidence what all Mac users already know: that in fact, multiple updaters is a completely sucky experience for users, no matter how they’re sliced. The evidence helped us secure funding, however, to work with the Qubes team in prioritizing a longer-term fix to make their own updater app more extendable, which with addressing other known pain-points, will benefit all Qubes OS users.

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—some mountains have yet to be climbed, to realistically reach GA readiness. The global supply chain shortage has also made hardware acquisition for the Workstation incredibly difficult, and the team does not foresee that resolving soon.

Bigger picture however, the Workstation project increasing FPF’s exposure to journalist users has surfaced many opportunities to improve training, documentation, usability and user error reduction for all newsroom users of SecureDrop. While I am leaving the project to pursue new opportunities, I’m incredibly excited for the future of SecureDrop: user research informed feedback cycles & ux design processes were introduced to the team with this project, iterated upon to include the developers as collaborators, and later extended to work in service to the Source user’s experience. There’s a lot left to do, and whomever takes on that work will have me cheering like mad for their success from the front row, while also looking to learn from how they tackle the same challenges I’m looking forward to handing off, in the weeks ahead. 

A more detailed version of this case study is available as a GDoc.