[FiloSottile]

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.

[lawl]

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.

[handsomeransoms]

(Securedrop dev here) We often suggest ideas like this to deployment operators, and others as well. For example, we encourage deployments to mirror the Tor Browser Bundle so sources don't have to go to Tor's (monitored) website to get it. We encourage them to use SSL everywhere so the "trail to the landing page" is harder to spot. We encourage the exact "hidden iframes" idea you propose here. And we encourage them to deploy on a path, not on a subdomain (because hostnames are visible even with TLS). At least WaPo is doing the last one right!

Generally, it is very difficult to convince the operators of sites like the Washington Post to do things like this, but we're working on it!

[FiloSottile]

Uuuh, hi there! Thanks for the effort you all put into making leaking safer for sources.

Other possible approach: load the landing page everywhere and show it with Javascript when the user clicks their way to it. I think it's an improvement on the iframe without drawbacks. How does it sound?

[lawl]

Hard to verify that there are no ajax shenanigans.

It's a hard problem :/

[im3w1l]

Downloading Tor from an inofficial source sounds like a recipe for trojans though... I don't think most people will have Erinn's signature to verify.

[dublinben]

It shouldn't matter where you're downloading the TBB binary, since you're going to verify the signature before trusting it, right? Surely you wouldn't just assume it was legitimate, and then install it.

[JoeAltmaier]

Business idea: signature database with web interface. So download from anywhere, and look up the signature on the database to verify its authentic.

[iainnash]

How about some simple cookie tracking an iframe that loads a random number of seconds after the page loads (like 10 - 60)? That might spam the logs randomly enough so that it couldn't be tracked. However, I think measures such as including the Securedrop page as a part of the root domain only under ssl would be the simplest solution in this case.

[FiloSottile]

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.

[handsomeransoms]

Maybe you could use JS to randomize the timing of the iframe load after the article load?

[lawl]

Wouldn't matter, the GET for a particular IP for the article would still show up before the GET for SecureDrop, the actual timing is irrelevant here, if there's always an article visit, and then a SecureDrop request.

I guess you could randomize if you load the iframe or not. Then you couldn't be sure if a visit was an actual visit or an iframe that was randomly triggered (with a random delay).

But for this to be useful you'd still need to instruct sources to randomly browse the page before going to SecureDrop. Which might work if you force them to click a link on the main-page to get to the SecureDrop page.

But if they go directly to /securedrop it will fail again because the GET /securedrop will show up as the first request from that IP, giving away that the visit was intentional.

So my current idea would be to randomly generate the actual /securedrop path in a non-predictable matter per client. Maybe something simple like securedrop-sha1(...). Then link to that from WaPo's main page. Forcing everyone to go trough WaPo.com. But then you still have the problem that you must make sure sources don't access this link from history or something.

Quite a lot of work, for still flawed security.