TL;DR: Going forward, new features for SecureDrop will be focused on the Qubes OS-based SecureDrop Workstation. We are also developing a next-generation SecureDrop messaging and encryption protocol. This post discusses the motivations behind these new directions and explains what they mean for SecureDrop users and contributors.

This summer marks both the 10th anniversary of Edward Snowden’s disclosures and the 12th birthday of the SecureDrop project, started by the late Aaron Swartz in June 2011. That project now includes the SecureDrop server, Aaron’s original brainchild, used by over 70 organizations around the world; and the beta SecureDrop Workstation, an integrated messaging system currently in an invitation-based pilot program.

The internet has changed a lot since 2011. So has the world, not least in response to the COVID-19 pandemic. In recognition of these shifts, earlier this year we invited SecureDrop users to participate in a research study on their digital security practices and privacy needs, especially when communicating with sensitive sources or working remotely.

Even within a newsroom, SecureDrop’s security comes at a cost to journalists’ convenience and responsiveness. Journalists use an internet-connected laptop to download SecureDrop submissions and then a separate, offline (“air-gapped”) laptop to decrypt them. As more and more newsrooms face serious malware attacks, this type of protection is critical for any system that accepts files from strangers. But this two-step process is time-consuming, and also impractical for fast-paced conversations. It’s yet more cumbersome for journalists working remotely.

In addition, submissions to SecureDrop are protected in two phases: in transit, via the encrypted Tor network; and then at rest, when the server saves them in encrypted form. Because the server is a high-value target, news organizations must run SecureDrop on dedicated and secured on-premises hardware. This requirement also enables a key legal protection for newsrooms: It means that no third party — including Freedom of the Press Foundation (FPF) — has access to any information that runs through a SecureDrop, so a government must send any legal demands directly to the news organization itself. But self-hosting is burdensome for many organizations, and it prevents others from being able to set up a SecureDrop at all.

We’re designing the next generation of SecureDrop to solve both of these problems, in two key ways.

The SecureDrop Workstation allows journalists to receive, review, and reply to submissions from a single integrated laptop. This significantly speeds up the process of checking SecureDrop, including identifying and deleting spam.

This integration is made possible by Qubes OS, which provides “security by compartmentalization” to protect journalists from documents sent by malicious or compromised sources. This approach provides many of the same protections of the physical air gap in the original SecureDrop design in a virtual environment that’s much easier and faster to use. Eventually, tools such as Dangerzone, now also a project of FPF, will provide further layers of protection by allowing journalists to sanitize individual documents.

Later on, a new SecureDrop messaging protocol will use end-to-end encryption to minimize the role of the server, increase its security properties for sources and journalists, and, hopefully, offer news organizations more flexibility in how they can host their SecureDrops.*

End-to-end encryption guarantees that a message can be decrypted and read only by its sender and intended recipients, not by any system or entity in between. For example, people use the Signal secure-messaging app to be sure that only their intended recipients, not Signal, can read their messages. Since newsrooms are required to host their own SecureDrop servers (which FPF cannot access), SecureDrop’s end-to-end encryption will serve a slightly different primary purpose: to further protect news organizations and their servers from compromise.

The new protocol will have two specific benefits. First, it will increase sources’ confidentiality and anonymity as they use SecureDrop. Because the server won’t have to re-encrypt submissions upon receipt, it will track and store less metadata, or data about the encrypted content, which can still be valuable to an adversary even if the content itself remains secure.

Second, this approach will lay the groundwork for making SecureDrop easier to install on generic, readily available hardware. In bringing SecureDrop to more news organizations, we will ensure that we preserve the protections that journalists and whistleblowers rely upon — every step of the way.

To achieve these goals, we’ve begun working on a number of technical challenges, about which we’ll have more to say in the months ahead.

In 2024, the SecureDrop Workstation will graduate from its current pilot program and become the preferred, fully supported way for journalists to connect to SecureDrop to interact with sources. We will start assisting current SecureDrop support clients to set up and begin using the Workstation, and all new SecureDrops will have the option to use the Workstation from the get-go.

Throughout this process, the current SecureDrop server will continue to receive support and security updates. However, development of new features will be focused on the SecureDrop Workstation, particularly to improve the experience for journalists and lay the foundation for the new cryptographic protocols that will be used by the next-generation SecureDrop server.

You can always keep up with our latest development work within our GitHub repositories and projects. And we’ll publish more details on our upcoming work on this blog in the near future.

In the meantime, we want to hear from you! You can write to us via this form or at <securedrop@freedom.press>. If you have questions about specific features for the Workstation or the current SecureDrop server, we’d especially love to talk with you. Support clients should feel free to contact us via our support portal.

* SecureDrop’s current design does not use end-to-end encryption, because the in-browser code necessary to perform the encryption poses unacceptable security risks to the sources it would purport to protect. This is one of the technical challenges we’ll discuss in follow-up posts.