Need: The basis of SecureDrop’s legacy design was both its threat model, and its use of free and open source software. While game-changing, its experience imposed a Rube Goldberg’esque use and maintenance burden upon the high-risk individuals and organizations dependent on its unrivaled security protections.

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. FPF hired me in 2018 to lead the design and research for their next generation newsroom experience, since named The SecureDrop Workstation.

Approach

How to shape an “intuitive” Linux based hypervisor experience for Mac-native users who lack both the time, and the interest in studying the written user documentation required of most open source software experiences, was the jumping-off point into my first open source project.

Our users were journalists—often under-resourced, always pressed for time, cognitively “trained” by proprietary software ecosystems, and more curious about matters of the world or their own craft, than either command-line mastery or adapting to irregular experience environments that intentionally eschew consumer appeal.

SecureDrop’s legacy experience had been designed from a threat model, by hactivists—a true MVP—as many innovations are, in their earliest forms. I was the first UX practitioner to do any work for SecureDrop, and the only practitioner to ever work on SecureDrop until I left and my replacement was hired. I worked with developers, and very closely with our Product/Project Manager; over time, developing collaborative co-design practice rituals that the team has continued to use, following my departure.

No structured user research had ever been done on SecureDrop before the Workstation project. Likewise, true to its open source ethos, no business or operations models had ever been created, and product management as a discipline had never factored into SecureDrop’s product development. Much of my work over my 3yr tenure with FPF, was subsequently partnering with our PM—himself a seasoned open source product leader—to gently ease the team into proDuct thinking & delivery cycles; an imperative to centering real, known human needs in our work’s outcomes.

I began my work on this first project of mine with FPF, by collecting basic data about use of SecureDrop from existing customers; a task unlike regular B2B2C analytics gathering, because of the acute privacy needs for all of SecureDrop’s users. Even simple time stamps on user communications are considered too risky to allow anywhere in SecureDrop. As with most constraints, however, the discipline that imposed to radically prioritize which data had what value to inform which decisions in order to shape the the intended user’s experience of SecureDrop, brought a new focus to all SecureDrop efforts the full team got behind. For a product built by security engineers whose primary job is learning about adversaries and how to defeat them, prioritizing the intended user’s needs was a maturity milestone the team was ready for.

Early sketches and prototypes felt deceptively simple. At its heart, SecureDrop is just a communication platform. With so much already alien to Journalist users in a Linux hypervisor, we didn’t want to stray too far from paradigms in desktop messaging and email clients—and yet so much about SecureDrop is still very different. A little bit like vegan sushi, or a symphony performing Metallica songs.

I spent the first several weeks working closely with our PM and development leads, ideating around what sorts of workflows, capabilities, UI affordances and information our users might desire; of those, which would deliver the most value. New prototypes were generated weekly, and we ran bi-weekly remote RITE sessions using Invision prototypes over Google Meet, with recruited existing-user and non-user journalists as our participants.

Embracing Lean UX methods quickly brought findings to the broader team for discussion and ideation, and engaged my PM as a partner and advocate for observed user needs in ways that reports and fancy presentations would have left behind. At the conclusion of our discovery work, simple data visualizations were created using the graphing functions in Google Sheets, but by that time everyone knew the data and those artifacts existed for ongoing reference—not learning.

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.

Mid-project it was learned that a second client, an updater app for Qubes OS, also needed to be created (for the same reasons Adobe has its own updater app in Mac OS). In the process of building that, a very different and more stringent set of technical constraints was discovered, that blocked our use of design system components that had already been designed, iterated upon, and developed. Maintaining the visual language of the main client, but without access to design system components, fonts, or the ability to customize OEM QT components, was a fun wrench to navigate. Unlike past projects I’d worked on, the SecureDrop team was as new to the Workstation’s tech stack as I was—and learning about the QT SDK as they went along—so flexibility on my part to roll with that, was important.

Pilot rollout + study.

Only a few weeks into the pilot’s first phase and with only one customer (thanks, COVID!), the Workstation’s ~2/3 reduction in active-time-on-task for journalist users emerged as its high point. The reduced cognitive strain and distraction from no longer having to juggle multiple devices, and journalist users now having visibility into conversations (versus a series of non-sequential, encrypted files) with their anonymous sources (whistleblowers) 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 both supporting internal newsroom teams, and to not losing important sources. Human factors the team was now liberated to learn more about and explore supporting, now that the basic value of protection through isolation-by-compartmentalization no longer overshadowed the experience as a human-facing burden.

COVID Impacts

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 required to safely matriculate items from SecureDrop, and onto the everyday machines of journalists (usually Macs).

In response to observed behavior among participating organizations, we began to explore how to combine exporting and sanitization through Qubes’ multi-VM capabilities. While this had of course been brainstormed as an opportunity early-on, COVID workplace shifts re-prioritized those capabilities from “Wow, cool!” to “Yep, essential.”

The above 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.

Conclusions + shifting focus to Qubes OS

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, and before the pilot’s structured, ongoing evaluative user research program had been put into place with customers.

~18mos into piloting the Workstation and its adoption 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 and user needs have surfaced. The team was also able to learn about how features of the SecureDrop experience were used in newsrooms, that overlap between the legacy journalist experience and the Workstation.

Deletion as a general capability, and the mental-models journalists develop about how Sources (whistleblowers) exist as data class within SecureDrop, was a highlight of what we’d learned. No rocket science whatsoever (we just threw-in the word “Account,” even though that was oh-so-technically not accurate), but familiarizing security engineers with how non-nerd humans see the world by involving them in user research as partner observers, was invaluable. Outcomes from that included updating deletion nomenclature, making a few small technical changes, and creating new interaction patterns and content that were consistent between the legacy web experience and the Workstation.

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

For Linux and OSS enthusiasts, platform level governance to “make everything look the same” is seen as a walled-garden overstep made by makers of proprietary software. For Mac and Windows users, it’s all we know. It also makes our lives easier, which is why it’s done. For folks only using a Linux based computer to get a few select real world tasks accomplished, an expectation that we recognize where one software product from one company ends and another begins forces thinking that’s just not a priority. Which is where usability and politics intersect, and I won’t lie—has been a tough balance to strike.

Helping the Linux-committed development teams for both SecureDrop and Qubes OS gain visibility into the frustration and confusion experienced by users from that disconnect, and the lost opportunity to actually delight someone with free software, was incredibly rewarding to facilitate.

The final question that bookended my time on the Workstation project: “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.