http://matasano.com/articles/javascript-cryptography/
http://tonyarcieri.com/whats-wrong-with-webcrypto
I'd say the main issue with that is sending an encryption package over an insecure channel. While you could verify the package independently (check a hash against a publicly known one) you're already into advanced user territory and the "encryption for everyone" point of this is gone.
in terms of end-to-end encryption, what kind of client-encryption do you have in mind? usually, this involves steps that regular internet-users are not able or willing to handle. that's why i think such a service might be a great thing.
to your second point, how would you ever be able to proof that?
> in terms of end-to-end encryption, what kind of client-encryption do you have in mind?
I didn't have something in mind, but Stanford has a good, relatively hard to screw up (by configuration) JS crypto library. But that's only part of the battle since we can't trust the delivery channel or the browser.
> usually, this involves steps that regular internet-users are not able or willing to handle.
That's right and underlines the single biggest reason crypto isn't really used by most people apart from HTTPS.
> to your second point, how would you ever be able to proof that?
That's a really interesting question. It might not be provable. I wasn't trying to be cryptic (excuse the pun) but that was really the point I was making.
The fundamental problem with this:
There's no way to prove that the secret has been deleted and / or not copied. You have access to the plaintext and the password / url (presumably an encryption key). You (the malicious server operator or the compromised server) can do anything you want with the information.
This would be interesting if you could:
1) Offer end-to-end encryption. This would require encryption in the client which has its own issues.
2) Be able to provide proof that the information has been made inaccessible. This is not the same thing as having the link return a 404 the second time.