When we first started the SecureDrop project, we thought it would be very difficult to convince news organizations to adopt a whistleblower submission system platform. The idea had been out there for years, yet not many had tried to create one, and those who did—like the Wall Street Journal and Al-Jazeera—had high profile failures.
However, we soon learned that news organizations of all sizes are very eager to have such a tool—especially after they saw the impact of the Snowden revelations. A variety of logistical factors, rather than philosophical issues, have prevented them from doing so. So we set out to solve all these problems for them with SecureDrop and make it as easy as possible for news organizations to use it.
First, there are costs. A major US organization told us this when asked why they hadn't set up a whistleblower submission system before:"We looked into doing this ourselves before, but if we created something from scratch, it would cost us hundreds of thousands of dollars, and in today’s media environment of declining revenues and cutbacks, that was just not feasible—especially when we would have no guarantee that it would work or that anyone would use it."
Second, there’s the technical hurdles. News organizations don’t necessarily have developers on staff that specialize in security. So it’s possible, after spending a ton of money, their tool would be criticized by security researchers and the public (this happened with both the Wall Street Journal and Al Jazeera), and they will be worse off than when they started. We've also learned news organizations are also a huge target for cyberattacks (a recent study showed 21 of the 25 biggest news websites had been compromised by hackers), and any system should not be vulnerable to the same problems as a news organization's email.
We’ve attempted to solve each these problems. First, we’ve significantly defrayed costs to news rooms. By adopting and supporting our open-source project, they will have to spent a very small fraction of what they would have if they built it themselves. We’re also providing technical guidance in multiple areas: our project is developed by experts who have been working on this type of problem for years, and we have it vetted and audited by professional security firms every time we release a new version. We also help them install it and train their journalists on how to use it. And we've recently made design changes to SecureDrop specifically so it can stay safe even inside a compromised network environment.
I'm not sure this is what they mean by 'assumptions.' To be honest, I have NO idea what they mean by assumptions.
ok I just asked for clarification. Here's what I got. I think it's much more general that what we have. I can fill this in.
What we are looking for is for you to identify and challenge the assumptions (or, put another way, educated guesses) on which your project rests. For example, if I were building a supermarket, one of the assumptions would be “People want to physically travel to a store to shop for groceries.” Another might be “People want to buy all their groceries in one store, rather than visiting separate stores for each type of item.” Another might be “A supermarket can provide groceries more efficiently than individualized shops.”
Those are some of the core assumptions about people (our users), the business (us), or the market that have to be true for the idea we’re proposing to succeed. Thus it’s important that as we built a project we are testing those assumptions to make sure they’re true. If they’re not (say, we’re finding people wanting to order from us online), it indicates we should consider changing strategies.
All of that is the longer-tee implication of the question. At this point, though, what we’re really looking for is to understand how you look at the context within which your idea exists, and how you challenge and define your own work. We’ve found it to be a strong indicator of a team’s likelihood to learn something interesting in their project.
We have a policy of getting every new version of SecureDrop vetted by a professional security auditing firm, and then publishing the results. This inspires confidence in both news rooms and sources that we are being as transparent as possible about the technology and work to fix any potential bugs as quickly as possible.
Both employees and board members at Freedom of the Press Foundation already have significant contacts at virtually every major newspaper in the United States and many around the world, given our work requires regular contact with the journalism community. We also have a very large social media reach, which will allow us to spread information about how news organizations can install and use SecureDrop.
We are blessed with the fact that SecureDrop is already in use at five high-profile organizations (with two more on the way), which also lends credence and name recognition to the project. Right now, The New Yorker, Forbes, The Intercept, ProPublica, and the San Francisco Bay Guardian operate their own instances of SecureDrop.
Besides finding the requisite amount of funding, we have two big obstacles: one technical and the other scalability.
SecureDrop is already an ambitious project, but attempting to implement truly end-to-end encryption in the browser, while not making the source’s job harder, is a difficult task that requires a lot of expertise from different technical fields. Fortunately, both our director and SecureDrop lead developer both previously worked at EFF, giving us significant contacts with the security community. The project has a big enough profile to be able to attract the requisite expert help that comes with developing a high-risk project. Couple this with our ability to ask our supporters for help has created a vibrant community on Github where we are able to go to experts for help on particular issues.
Right now, we have assisted almost a dozen organizations with installing SecureDrop, and continue to provide technical assistance to them if and when they have technical difficulties. We have the capacity to continue this with a dozen more organizations. However, expanding beyond that—especially internationally—will require us to expend more time and money traveling to far away places, and potentially running into language barriers. This is where have having a dedicated team would help.
Another obstacle, not for us both those wanting to use SecureDrop is is the cost of the hardware involved in setting it up. While the SecureDrop software is completely free and open-source, it currently it costs about $2,600 to buy all the equipment off the shelf. But in the coming months we are planning a major crowd-funding initiative to help organization who cannot afford the equipment and defray their costs even more.
A particular obstacle with the Next Generation SecureDrop is ________ is placing the browser plug-in in the Tor Browser by default. We have had preliminary discussions with Tor about doing this and we believe it is feasible if the plug-in is made to their specifications. [Garrett fill in, turn it into a positive though]
5. How much do you think your project will cost, and what are the major expenses?
Our major costs right now are employing those who do development work on the project. While we rely on a volunteer base to help with specific issues, we need full-time, dedicated developers with a variety of advanced skills, given the breadth of security and usability we try to provide with SecureDrop.
To fund fully fund SecureDrop for an entire year while building out the next generation version—and helping as many news organizations install it as possible—it will cost somewhere around $400,000. We need three full-time developers on the project to create the Next Generation SecureDrop. One installation and security specialist to engineer the architecture around the SecureDrop code, one lead developer who can manage the code base and make design decisions, and one developer whose sole job it is to create and develop a Tor Browser plug-in to facilitate client side encryption. We also need an additional installation and trouble-shooting expert to make sure we can facilitate as many newsrooms as possible.
There are two ways we can measure impact: by the number and variety of news organizations that adopt and use SecureDrop, and the number of stories that are produced by its use.
We have already set up an informal reporting mechanism to receive feedback from news organizations who are currently using SecureDrop (and how they find sources are using SecureDrop) so that we can better improve the software in subsequent version releases. We ask a variety of questions, like 1) How often do you check SecureDrop, 2) what is the volume of submissions, 3) what percentage are worthwhile sources 4) what tools are needed to search and verify submissions 5)what features do you currently have trouble using, 6) what features would you like to see in the future?
TL;DR: Grab your personal computer, Tails USB, and documents—but leave your phone at home. Use cash and take a bus to a coffee shop that you've never been to. Avoid shoulder surfers and CCTV. Using the Tor Browser, or preferably the Tails operating system, access your preferred news organization's SecureDrop onion URL from the coffee shop's open WiFi. Always be aware of the info you are submitting, obvious or not. If you use SecureDrop again, access it from a new location. Protect your codename. Don't tell anyone about what you are doing or have done, and never answer questions from investigators without a lawyer present.
First, you must be careful to nevercontact a SecureDrop site at work. Most corporate and government networks log traffic at at least some level, ranging from "netflow" (a record of what computers are contacted) to full intrusion detection logs which record every URL visited on the network. A network administrator at work may easily be able to determinewho has been using Tor on your work network. Any attempt to use Tor within a monitored network may arouse unwanted suspicion.
This means that if you wish to submit documents that exist in your work environment, you must remove them and submit them to SecureDrop usingyour personal computer, or even better, a new computer at a location other than work.
By now it should be clear that you can not safely use Tor from work or even from home, as even the lightest monitoring can often identify Tor users. Thus if you wish to leak documents to a SecureDrop instance, you should go to a third location with public WiFi, like a coffee shop. Ideally, you would not go to a coffee shop that you've been to before or which you plan on returning to. Avoid bringing and using items that can be used to track your location, like your cell phone. Buy your coffee in cash; do not use a credit card.Oh, and wear a hat.
While accessing and using SecureDrop attempt to sit with your back to the wall and use a privacy screen to avoid shoulder surfers and video cameras.
Don't re-use the same location to access SecureDrop.
Any shared computer, for example a public library or internet cafe computer, also increases your risk of surveillance as well, although in a different manner. These computers may have network monitoring, and may also have access logs. Your personal device for daily use may be infected with malware that also has this capability as well. To mitigate this risk, you should boot yourcomputer from a live operating system like Tails. This requires some sophistication, as the initial installation of Tails (onto a DVD or USB stick) is fairly complex. However, Tails offers detailed instructions on how to download and use Tails here.
The Tor Browser, the privacy-conscious web browser that masks the IP address of your computer, is an integral part of SecureDrop and one of the keys to keeping your identity a secret.
If you try to access the SecureDrop site from Tor2Web you will receive a warning telling you to open Tor first.
Protecting Your Codename
A 7-10 random word codename that is only sporadically used will be almost impossible for the average person to remember. You will have to record it somewhere until you either remember it or no longer need it. When recording the codename try not to store the whole codename together. Break the codename into a few parts and store the parts in different locations.
If used properly, SecureDrop does not log any identifying information and you can stay anonymous, even from the journalists you are communicating with. However, the document you upload, may contain “metadata” that can contain identifying information such as the author, editor, operating system or programs used, location, and timestamps embedded within them. For extremely sensitive documents, corporations or governments may have placed watermarks or other unique identifiers on them to help identify the source if they are leaked.
The journalists are instructed to scrub this metadata on their end before ever publishing such documents. But if thesource is concerned, they can use the Metadata Anonymization Toolkit (MAT) to do this before submitting. Unfortunately, MAT only runs in Debian or Tails, so you will have to go through some extra steps to use it.
Right now, the Tor network encrypts your document in transit, and then the document is encrypted with a GPG private key for storage on the SecureDrop server (the private key is stored offline). However, the message is momentarily in plaintext when it hits the server, and you are trusting that the web application and environment has not been compromised. We have our web application and environment continually audited to make sure it is as safe as possible. But to be 100% sure the plain text of your message or document never touches the server, you can encrypt your message or document before sending.
To do this, you can download the journalist’s public key from the SecureDrop main page. On Tails Then follow these instructions on the command line:
Press enter, compose your message and then press Ctrl+D when you are done. Copy and paste the entire block of encrypted text into the comment box on the SecureDrop main page. When you hit submit your message will already be encrypted once, and will be encrypted again once it hits the server. Your message will never be seen in plaintext by the server.
To encrypt a document which you can then upload through the SecureDrop interface:
The resulting encrypted file would live in the same folder and be called document.pdf.asc or document.pdf.gpg. The "armored" (--armor) output option can also be used, but the ASCII output will be larger if you're encrypting a binary format like images, PDFs and media as opposed to text.
In a situation where there are a limited number of people who had access to the document, and where it was an important enough document to spark an investigation by the FBI, you will likely be questioned by investigators even if you've done everything correctly. It's also possible they will know you have connected to Tor at some point if you did so from your home or work Internet connection. They will use this as leverage to try to get you to admit what you did. Using Tor does not prove you have committed a crime. If you say nothing, they cannot prosecute you if this is their only evidence.
Many people believe in using the postal service to get documents to journalists because of unambiguous warrant protections involving physical mail. Although it takes a warrant to open mail, the US government photographs the outside of every letter and package sent. This can be used to identify the mailbox for any letter of note, and potentially provide the government with knowledge of the outside of every letter sent to a target recipient long after the fact. Therefore:
* Make sure there is no valid return address on your package; consider putting a fake return address on the package to avoid suspicion.
* Do not enter any post office to mail anything, since they also take photos of the faces of everyone who mails a package with them. Instead, mail from a sidewalk public mailbox.
* Make sure you do not leave any fingerprints on the package in case it ends up in the hands of the authorities (at least one source has been convicted in part because his fingerprints were found on the source documents).
SecureDrop is only as secure as the environment that surrounds it. To keep sources safe, the news organization's website must employ a set of basic security best practices or else you risk losing any source protection provided by SecureDrop.
Trevor TWhile SecureDrop itself is located on a Tor hidden service, news organizations also need to create a SecureDrop landing page that will explain how SecureDrop works, give sources instructions on how to access the Tor hidden service, and disclose the risks.
It is important to keep in mind that implementing SecureDrop will bring more attention to your organization by security researchers, hackers, and other like-minded people. If theyour landing page minimum requirements are not implemented, these people will be sure to loudly point this out on Twitter and other blogs as a #SecurityFail. This will discourage potential sources from using your version of SecureDrop. However, it can easily be avoided by following the below best practices.
Freedom of the Press Foundation will soon list all of the SecureDrop onion URLs as "verified" on its website that meet the minimum requirements for deployment best practices. If your organization cannot follow the minimum guidelines we cannot recommend to users that your SecureDrop is safe to use.
In addition to implementing the below best practices, it is strongly recommended that you have a reputable security firm perform a security review of your organization's public website prior to launching an instance of SecureDrop. Upon request, we can help put you in touch with a few security firms if you need more assistance.
Most news organizations, in fact almost all, do not use HTTPS encryption by default. This is the number #1 minimum requirement for the SecureDrop landing page on your website. Without HTTPS, a source can easily be exposed as a visitor to your site.
If you do not serve ads on any of your site, you should also consider switching your whole site over to HTTPS by default immediately. If you do serve ads, consider pressuring your ad networks to enable you to switch to HTTPS for your entire website in the future.
Both the New Yorker and Forbes were heavily criticized when launching their version of SecureDrop because their landing page contained trackers. They were claiming they were going to great lengths to protect source's anonymity, but by having trackers on their landing page, also opened up multiple avenues for third parties to collect information on those sources. This information can potentially be accessed by law enforcement or intelligence agencies and could unduly expose a source.
Security headers give instructions to the web browser on how to handle requests from the web application. These headers set strict rules for the browser and help mitigate against potential attacks. Given the browser is a main avenue for attack, it is important these headers are as strict as possible.
Minimum requirements for the SecureDrop environment
The Document and Monitor servers should be dedicated physical machines, not virtual machines.
A trusted location to host the servers. The servers should be hosted in a location that is owned or occupied by the organization to ensure that their legal can not be bypassed with gag orders.
The SecureDrop servers should be on a separate internet connection or completely segmented from corporate network.
All traffic from the corporate network should be blocked at the SecureDrop's point of demarcation.
Video monitoring should be recorded of the server area and the organizations safe.
Journalist should ensure that while using the air-gapped viewing station they are in an area without video cameras.
An established monitoring plan and incident response plan. Who will receive the OSSEC alerts and what their response plan will be? These should cover technical outages and a compromised environment plan.
For publicly advertised SecureDrop instances display the Source Interface's hidden service onion address on all of the organization public pages.
Mirror the Tor Browser Bundle so sources do not have to visit torproject.org to download it.
Possible ability to correlate whistleblower traffic when learning how to submit to SD accessing the media website from a list of given suspects provided by the organization who's material has been leaked
What a global, active adversary (one who can observe and arbitrarily modify/block Internet traffic) can achieve (in addition to the abilities of a global, passive adversary):
What a local network (where "landing pages" of the media has been deployed or where the whistleblower use to connect to the internet, such as work proxy or home connection, to read landing pages) attacker can achieve:
Log access from whistleblowers learning how to submit to SD, with possible ability to correlate whistleblower's IP/identity from a list of given suspects provided by the organization who's material has been leaked
SecureDrop 1.0 will be a complete re-architecture, designed to achieve two primary goals:
Each SecureDrop server should offer a simple API for clients to use in submitting information and conversing with journalists. Multiple client designs should be allowed, to satisfy a variety of source threat models and operational environments.
All encryption between sources and journalists should be end-to-end, accompanied with a variety of countermeasures to prevent or at least detect malicious tampering with the SecureDrop server.
Additionally, we should consider a design where both the server and client can cooperate to implement mitigations for traffic analysis.
A local observer (in the context of an anonymity network, any eavesdropper between the client and the first hop router) should only be able to determine that the user is using the anonymity network, but not that they are using SecureDrop.
A first step could be to randomly pad requests and responses to obfuscate the traffic fingerprint. Unfortunately, it is difficult to achieve certainty in effectiveness.
"Bucketing" requests and responses, in the manner of Pond, is unfortunately insufficient: the traffic pattern is still identifiable (which is acknowledged by Pond's design document).
We could use a more sophisticated scheme, such as Wright et. al's traffic morphing. Unfortunately, this is difficult to implement and has also been called into question. In general, the jury is still out on any "efficient" traffic analysis scheme.
Ideally, we would also implement mitigations for global adversary traffic analysis. We obviously cannot stop them from learning that a given user is using SecureDrop due to correlation, but we might be able to prevent them from associating a SecureDrop user with a specific submission or set of submissions.
In general, resisting traffic analysis may be better served by removing the assumption of a low latency anonymity network (e.g. Tor). We could consider something high latency (e.g. Mixminion). Unfortunately, there is no existing network with a large anonymity set (comparable to Tor's) and bootstrapping one is decidedly non-trivial.
Given the difficulty in implementing and ascertaining confidence in comprehensive traffic analysis mitigation, it may be better to treat it as a goal for a future (1.x) release, and implement simple mitigations for 1.0 (e.g. random padding, maybe bucketing).