You're looking at Less Wrong's discussion board. This includes all posts, including those that haven't been promoted to the front page yet. For more information, see About Less Wrong.

ike comments on Open thread, Feb. 9 - Feb. 15, 2015 - Less Wrong Discussion

6 Post author: MrMind 09 February 2015 09:12AM

You are viewing a comment permalink. View the original post to see all comments and the full post content.

Comments (321)

You are viewing a single comment's thread. Show more comments above.

Comment author: gwern 10 February 2015 07:20:37PM *  8 points [-]

That's both wasteful on bandwidth as everything is downloaded twice, and anything not public needs to be done manually with cookies.

But it's dead-simple and robust compared to some sort of in-browser extension which saves the rendered DOM in the background.

He also can't prove that they came from a site even if it used https.

I've never needed to prove that. My concern is usually having a copy at all, and the IA is trusted enough that it's a de facto proof.

But it's possible:

  1. find a download tool which will save the raw bit-level TCP/IP stream of packets when you download a page and save it to an appropriate format like a PCAP file (maybe Wireshark supports this or it could be hooked into something like wget?); this preserves the HTTPS encryption and allows proving that the content came signed with the domain's key (not that this means much), since the crypto can be checked to be valid and the stream replayed.
  2. This doesn't prove it came from the domain at a particular time, but you can get timestamping using a trusted timestamping service such as the Bitcoin blockchain: as soon as the PCP file is closed and the webpage downloaded, take the hash and send a satoshi to the equivalent Bitcoin address. Transaction fees mean that this might get expensive to do for each web page, but there are a lot of ways you could optimize this (such as batching up an entire day's worth of downloads into a single tarball archive, and timestamping that; big savings but also more granular timestamp; there are other schemes). Now you can prove the content came from someone with a particular HTTPS public key and that you downloaded it on or before a particular hour and date (roughly when the Bitcoin block with your transaction will be mined).

If anyone doubts you, they can take the relevant tarball, verify the hash and timestamp to when you say it was, then extract the relevant PCAP, verify the encryption, and then the displayed content.

Good luck.

Comment author: ike 16 February 2015 05:11:27AM *  0 points [-]

Pfft says that this wouldn't work at all for proof due to how TLS works. Is that true? Is there no hope, then?

If correct, it's impossible to prove that any server sent a specific piece of data, because it's encrypted symmetrically, and the only proof you have a zero-knowledge and non-transmissible. (Assuming I'm understanding properly.)

Comment author: gwern 16 February 2015 08:02:10PM 0 points [-]

I dunno. I'm not an expert on TLS/HTTPS - I assumed that it would be implemented the natural way (signed and encrypted) where my proposal would work. But the devil is in the details...