A neat idea would be if you encoded the information on your server with a secret key, then put that key in the URL in addition to the unique identifier. This way you never store the information on your server. The secret key should never be put in your logs until the information is accessed and destroyed. If this policy is followed it would alleviate some fears of giving all my secrets to a third-party site.
In order for this to work, the key would have to be generated client-side and the secret encrypted client side. And you're still trusting that the site doesn't send the key when you submit the form.
While I think that this is a good idea, I hink that this would unfortunately result in URLs that would be much too long to be user-friendly - especially if we are talking about sending information to non-technical people.
An AES key is 128 bits, or 22 BASE64 characters. That's reasonable, and you can switch to BASE96 or Unicode.
This doesn't help if the server is malicious, but it does help if the server is honest but is later hacked/subpoenad/whatever. Generating a key entirely in RAM/encrypted swap is reasonable, and securely erasing RAM is easy (securely erasing individual files is nontrivial to say the least.)
I do like the idea though of keeping the secrets safe with a client-side (or non-stored) key. So long as it's known that it isn't about keeping the server honest, since you have to implicitly trust that they won't be storing the key.
This is what I'm thinking. They could reasonably be unable to divulge your secret to a fourth party. The decryption could even be done client-side. They just generate a pair of (encrypted-secret, key). They store encrypted-secret and send you a pointer to it and the key, then destroy the key on their side.
There is no difference between storing plaintext on the server and storing encrypted text on the server if encryption key is (was) known to the server.
