The audit that Schneier participated in doesn't sound promising. These things stuck out to me:

http://homes.cs.washington.edu/~aczeskis/research/pubs/UW-CS...

> First, we experimented with leaking data to our DeadDrop deployment. We are not aware of the ways that actual leaked documents are submitted, but we assume that this way of leaking data is at least plausible.

In this controlled test, the researchers found that the app did not protect against sources accidentally including their meta-data in the submitted files (i.e the Properties of a Word Document, for instance)...this meta-data has been a classic source of amusement and stories for journalists when they make public records requests and government officials forget to remove it...so, in other words, given that DeadDrop is meant for tech novices...it did not, in its audited form, protect against one of the most basic human-snafus in document-leaking.

But that can be fixed...what I'm concerned about is that this audit -- and Aaron and his original collaborators -- may not have considered the other less obvious human vulnerabilities. For instance...many (if not most) leak investigation/prosecutions happen well after the publication of a story. It's not the journalist who gets the hammer, but the whistleblower.

At this point, the "attacker" (the government authority) has a short list of candidates for who the leaker could be: i.e. anyone who had access to the info that a journalist published...It's not a matter of intercepting all of the journalist's communications, but intercepting all of these shortlisted suspects' communications, and any prior network activity, either at the workplace, from their work phones, or even at home.

The "attackers" could seize on something as seemingly innocuous as the leaker visiting "newsorg.com/deaddrop/faq" from his office computer. And sure, they can't prosecute on something that circumstantial...but that's not the point...they just have to keep limiting their scope and keep questioning (the suspect, the suspect's associates) until they find the smoking gun.

I think too many tech people (though not Bruce) think that this process fails alone on the technology...i.e. if they can't break 4096-bit encryption, then you're good to go. But they don't have to break the security technology, just the person.

This should be pretty clear from the story of Silk Road's takedown, which was operated by someone who was more technically savvy than most of DeadDrop's audience:

http://arstechnica.com/tech-policy/2013/10/how-the-feds-took...

The Feds didn't get their initial lead by using sophisticated NSA wiretapping. They did the kind of Google work that every amateur researcher can do: look for the earliest mentions of something that was previously unheard of, and find the pattern in those mentions:

> The post directed readers to visit silkroad420.wordpress.com, belonging to the blogging operator WordPress, where further instructions would be found for accessing the real Silk Road site. A subpoena to WordPress Revealed that the blog had been set up on January 23, only four days before the Altoid post. If this wasn't the first mention of Silk Road, it was certainly one of them. Altoid became a person of interest, but who was he? Further research revealed that Altoid had been posting on a board called Bitcoin Talk—further suggesting a possible link to the Silk Road, which operated on Bitcoin. A key break came when the agent found an October 11, 2011 post by Altoid, looking for an "IT pro in the Bitcoin community" and directing all inquiries to "rossulbricht at gmail dot com."

Protecting against this kind of info-leaking before using the app is outside of DeadDrop's purview of course...but that's kind of the problem. The kind of exposure vulnerabilities that leakers face is not typically from encryption cracking, but inadverdent human mistakes...

But perhaps even having a DeadDrop, heavily used or not, will at least put everyone at the news org (and their sources) on a higher level of situational awareness, and that would be valuable enough.