Live data from Hacker News

SecureDrop

ssl.washingtonpost.com

41–50 of 99 posts

Re: SecureDrop

#41
post #35

Earlier quoted context omitted.

Embed the page as iframe and scrub the referrer on every page a viewer visits. That should make it hard enough to correlate any data, I guess they have enough visitors.

I don't see how that would help. The threat model here, the reason to use Tor is that they could be compromised and forced to log, and through Tor they would not know the leaker's IP. You only need the two "leak at time X, IP Y loaded this page at time X-5" datapoints to break this. An embedded page is not fetched by someone else.

Either you misunderstood me, or I don't quite understand how that would not help.

My suggestion is to embed an iframe to the posted URL on every page on www.washingtonpost.com. Every article, everything. I'd assume this would blast the logs enough that if you look at "time X-5" you'll have too many data points to actually make something out of it. Because everyone who reads an article on wapo will have also visited that page. So yes, that embedded page would be loaded by every single viewer of any page on washingtonpost.com.

Edit: I just realized that there is a huge unfixable flaw in this approach. The request for an article in the logs will always show up shortly before the request for the SecureDrop page. Even if you would iframe a random article on the SecureDrop page too you could see from the logs that is was loaded before the actual article. Essentially rendering this thing useless :/

So... Nervermind... I guess.

Re: SecureDrop

#42
post #14

The Guardian has also released a secure drop platform: http://www.theguardian.com/technology/2014/jun/05/guardian-l... https://securedrop.theguardian.com/

This is a different deployment of the same product [1]. Which, incidentally, was originally created by Aaron Swartz. The Wikipedia page[2] has a list of well-known deployments.

[1] https://pressfreedomfoundation.org/securedrop

[2] http://en.wikipedia.org/wiki/SecureDrop

Re: SecureDrop

#43
post #7

Earlier quoted context omitted.

USA is pretty low on the list of countries I could imagine implementing something like this. Given Russia's, China's, and a large portion of SEA countries' internet censorship track records...

I'd put the USA pretty high on that list. They've implemented plenty of their take-downs over the past year, and are more capable of introducing something like this than any SEA state.

I think many people living in the US are unaware of just how bad the rest of the world has it, sometimes.

Re: SecureDrop

#44

If the leaker visits this page before opening the Tor Browser from a regular browser to copy the onion url, the whole thing is as safe as SSL as there will be a trail of the SSL connection just before the visit to SecureDrop. And they don't even explain to avoid it. OPSEC is hard.

The leaker can always visit the SSL site via Tor, which would solve the problem.

Re: SecureDrop

#45
post #42
post #14

The Guardian has also released a secure drop platform: http://www.theguardian.com/technology/2014/jun/05/guardian-l... https://securedrop.theguardian.com/

This is a different deployment of the same product [1]. Which, incidentally, was originally created by Aaron Swartz. The Wikipedia page[2] has a list of well-known deployments. [1] https://pressfreedomfoundation.org/securedrop [2] http://en.wikipedia.org/wiki/SecureDrop

Thanks for pointing that out. I just watched "The Internet's Own Boy", the documentary about Aaron, and it is positively incredibly how many projects Aaron created or played a critical role in creating. An unthinkable shame that he left us so soon — one can only imagine all the things he had left to create.

Re: SecureDrop

#46
post #41

Earlier quoted context omitted.

I don't see how that would help. The threat model here, the reason to use Tor is that they could be compromised and forced to log, and through Tor they would not know the leaker's IP. You only need the two "leak at time X, IP Y loaded this page at time X-5" datapoints to break this. An embedded page is not fetched by someone else.

Either you misunderstood me, or I don't quite understand how that would not help. My suggestion is to embed an iframe to the posted URL on every page on www.washingtonpost.com. Every article, everything. I'd assume this would blast the logs enough that if you look at "time X-5" you'll have too many data points to actually make something out of it. Because everyone who reads an article on wapo will have also visited t…

Ah ok, I didn't get the "on all pages" bit, sorry.

I still believe it would not be enough, since such a thing could be silently disabled by WaPo if ordered to do so.

The point in SecureDrop is that they could not deanonymize the source even if they tried.

Re: SecureDrop

#47

Does anyone know what the codenames are like? If they are easy enough to remember, then they may be easy enough to brute-force? I think this is a great concept, yet perhaps too little, too late (Journalists should know PGP and drop boxes like these should have been common already). I also worry a bit because of Washington Post's track record with leaks, of the top of my head: - Washington Post was Snowden's first cho…

Here's the wordlist. https://github.com/freedomofpress/securedrop/blob/develop/se...

Re: SecureDrop

#48
post #41

Earlier quoted context omitted.

Either you misunderstood me, or I don't quite understand how that would not help. My suggestion is to embed an iframe to the posted URL on every page on www.washingtonpost.com. Every article, everything. I'd assume this would blast the logs enough that if you look at "time X-5" you'll have too many data points to actually make something out of it. Because everyone who reads an article on wapo will have also visited t…

Ah ok, I didn't get the "on all pages" bit, sorry. I still believe it would not be enough, since such a thing could be silently disabled by WaPo if ordered to do so. The point in SecureDrop is that they could not deanonymize the source even if they tried.

[deleted]

Re: SecureDrop

#49
post #27

Earlier quoted context omitted.

>They've done a pretty good job of scaring people into securing their APs How is this even remotely a bad thing? It's trivial to MITM people on unsecured networks - I can't think of a single consumer router that actually does DHCP snooping to prevent it either.

I think the technology confuses two things: 1. Encrypted traffic between device and wireless hotspot 2. Restricted access to the wireless hotspot (you need a password or it won't give you service) I want to allow anonymous access, but let the traffic be encrypted. Is there a technical reason why this is not implemented? I'm very sad by the culture (and moreso, the legal necessity) of restricting wireless access. I wa…

You can run an access point with all the benefits of WPA2/AES, but make the password really simple. Setting your SSID to "PasswordIsBacon" or just using the same SSID and password is a fairly easy way to share access, without running a completely insecure, unencrypted network.

Re: SecureDrop

#50
post #36
post #32

Earlier quoted context omitted.

That's like saying John Smith went to a bank withdrew money at 1pm on Jan 1. Then the bank was robbed at 1:10 Jan 1 therefore John Smith robbed the bank. I don't think you can connect visiting the info page and the very next SecureDrop file upload.

It's not about proving that John Smith robbed the bank, but raising suspicion so that he will be investigated.

The difference between a court of law and a court of force.
Post reply on HN