Re:How to leak to the press
by detaro on Friday January 27, 2017 @12:20PM
(#13501082)
I wonder how much that actually gains for this specific case ("which article did IP $x view?"). With more effort, it should be fairly easy to match the traffic pattern to the article, e.g. by matching the size of subsequent requests for the images. But more complicated than a simple filter that just grabs all URLs from HTTP.
[ Parent
| on HN ]
> With more effort
That's the new key point for 2017 pro-privacy architectures.
Proof of work surveillance doesn't scale because requiring it leverages the disparity between the total level of Internet traffic and intelligence agency resources.
Kill the dragnets as step 1, then worry about step 2.
It would be helpful to have a website to display a random image of differing sizes for every page load. This would prevent fingerprinting https.
Um, I don't believe that would help. You either inline the images as data, or better, get rid of all images and have random length non-printing text to hide the real data. This kills caching and performance though.
https://github.com/technion/mod_randpad (an Nginx module that injects padding as a comment into returned HTML documents) is likely the correct layer to add random padding; the performance hit would be negligible.
SD dev here. You might be interested to check out https://github.com/freedomofpress/fingerprint-securedrop (note: still in experimental stages). We're going to be using the framework/ ML pipeline to evaluate server-side defenses (e.g., https://petsymposium.org/2017/papers/issue2/paper54-2017-2-s...), and are also working w/ Tor dev Mike Perry who is working on a solution or set of solutions to the problems of website & circuit fingerprinting with regards to Tor at the protocol level.
Edit: What Mike is trying to implement is based on https://arxiv.org/pdf/1512.00524.pdf.