Hacker News new | ask | show | jobs
by sandstrom 4371 days ago
A few things that may be helpful:

1. Make the entire site available under `ssl.washingtonpost.com` (ideally without the `.ssl` prefix).

That way, the domain won't be as suspicious as it is right now. I suspect that this is more or less the only content hosted on the domain.

2. Include an iframe for all (or a random subset of) visitors, loading this particular url (hidden).

By artificially generating traffic to the endpoint it will be harder to distinguish these from other, 'real' requests.

Use a random delay for adding the iframe (otherwise the 'pairing' with the initial http request may distinguish this traffic).

3. Print the link, url and info block on the dead trees (the paper), as other has suggested.

4. Add HSTS headers (http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security)

3 comments

Also, if you can swing https://washingtonpost.com?page=securedrop, the request will just look like it's to https://washingtonpost.com since query parameters are encrypted with ssl.
So is the rest of the URL, it could just as well be https://washingtonpost.com/securedrop
Oh right, paths are too. Sorry!
> Include an iframe for all (or a random subset of) visitors, loading this particular url (hidden).

Or, since the content of this page is mostly text, it could be included in the HTML of all washingtonpost.com home page requests with very small overhead, and shown with a non-tracked javascript action (link/button), so it is all client-side and indistinguishable from a normal request to the home page.

Definitely! The challenge is getting the news orgs to change their entire site, which often involves a lot of complex, entrenched infrastructure and sometimes involves reluctant third parties such as ad networks.

We're working on a best practices guide for deployments [0]. I'll make sure these suggestions go in there. Feel free to take a look and comment if you're interested!

[0] https://securedrop.hackpad.com/SecureDrop-Deployment-Best-Pr...