The problem with these is that even if the code is set to be cached forever, there's no easy way for the user to verify that this is the case. How do you defend against an attacker (say, the FBI) taking control of the servers and causing them to serve javascript which sends the messages to themselves unencrypted?
This was on HN previously, but not at this domain, they said the key generation and link formation was performed client-side, at no point does the key get sent to the server.
You send the encrypted message to the server and the javascript serves the url that combines the client side key and the servers uid for the paste.
0bin is not made to prevent the user from being buster. 0bin is made so that it's difficult to sue the host for hosting hot content since he can claim he can't moderate it.
11 comments
[ 4.9 ms ] story [ 34.4 ms ] threadDamn.
Edit: though of course if the javascript is never requested again it limits the window of opportunity to man-in-the-middle.
You send the encrypted message to the server and the javascript serves the url that combines the client side key and the servers uid for the paste.
See: http://sebsauvage.net/paste/
0bin is not made to prevent the user from being buster. 0bin is made so that it's difficult to sue the host for hosting hot content since he can claim he can't moderate it.