aaron42net

I believe that Aaron Swartz might've been the activist mentioned in Wired (http://www.wired.com/threatlevel/2010/06/wikileaks-documents...) who bootstrapped WikiLeaks with over a million files intercepted from Tor.

One thing I haven't seen mentioned elsewhere is that it looks like aaronsw was running tor2web.org, as it has the same IP and is running in the same Linode instance as aaronsw.com and at least two of his other projects, blogspace.com and jottit.com.

Tor2web is an interestingly risky service all by itself, being the only public interface into Tor hidden services. And the Wikileaks submission system at least in 2010 was running on a Tor hidden service (http://suw74isz7wqzpmgu.onion/ at the time accessible as https://suw74isz7wqzpmgu.tor2web.org/).

While the sniffing could've happened on any exit router, tor2web.org would present an interesting extension of that capability.

That site will require that you are a Bank of America customer, though the link is unfortunately broken. If you are an AMEX, USAA, PenFed, or Consumer Reports customer instead, check out their respective car buying sites. They are variations on the same program.

Alternatively, https://www.truecar.com/ can be used by anyone, is mostly using the same data and dealer network, but the prices might be slightly higher.

(Disclaimer: I'm a TrueCar employee.)

If you'd like to see what it contains without the 4GB download, I've mirrored the contents: http://mirror.die.net/misc/defcon-20/

There's an important optimization that Nginx is missing around real-world TTFB, however that would benefit Cloudflare users.

Even though it is streaming compression, zlib normally packs compressed content into larger than 1500-byte blocks. Browsers can start parsing gzipped content as soon as they can decompress a block, but they have to wait for a whole block to arrive, which means for gzipped content they will often have to wait for more than the first packet to arrive. (Due to TCP slow-start, this may be another round-trip.) This means they are also waiting longer to start fetching <head> contents.

There's a simple fix for this, which is to call deflate(..., Z_SYNC_FLUSH) on a chunk that is likely to compress to under 1500 bytes, like maybe all of <head> or the first 4k. The total compressed size will be slightly larger, but the tradeoff is usually worth it. Nginx doesn't currently do this, but would be a nice optimization to make available.

It's possible to work around this in Nginx by using the embedded perl module and SSI. After </head>, I use SSI to call perl's $r->flush, which Nginx correctly translates into Z_SYNC_FLUSH. The improvement is small, but measurable.

If the author really wants this on disk, would application-level encryption of the files it is writing to /tmp be overkill?

The standard trick with encrypted swap on Linux is to pull an encryption key out of /dev/urandom on boot and never store it anywhere. I suspect libVTE could do something similar without a lot of code, though it would be a bit strange for a terminal emulator to depend on crypto libraries.