Cryptome also has the advantage of mostly serving individual large files, rather than HTML/CSS/JS with a lot of bursty dependent requests. The exponential rath

Cryptome also has the advantage of mostly serving individual large files, rather than HTML/CSS/JS with a lot of bursty dependent requests. The exponential rather than linear padding suggested by that paper sounds like a good idea, as it better reflects the typical distribution of file sizes. Small amounts of junk might be significantly more effective than nothing. I had to remind myself this is not like a crypto timing attack where the attacker usually gets to retry the operation as many times as they want, making even large random padding potentially susceptible to statistical analysis; a user will usually download a particular document from a server at most a few times. However, these days I'd say the bandwidth of good Internet connections is high enough compared to typical single-digit-MB PDF sizes that relatively large amounts of junk shouldn't inconvenience users too much; I just tested and got ~2.2MB/s from Cryptome, which is not terribly high, but definitely high enough that, say, doubling a 5MB PDF to 10MB would be no big deal. For the user, anyway. I have no idea what Cryptome's bandwidth costs look like.