3 ms·
I think this is neat. I can't imagine a use for it but I like the UI. The fundamental problem with this: There's no way to prove that the secret has been dele
by mbenjaminsmith 12y ago
I think this is neat. I can't imagine a use for it but I like the UI.
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.
- adambutler 12y agoI will be open sourcing the code once I've cleaned it up a little.
- mkohlmyr 12y agoDoesn't solve the problem he's describing since it won't prove that the published code is what's running.
- tuananh 12y agoyou can host it yourself?
- gioele 12y agoNor it will prove that code is not running inside a malicious VM that shares its memory with other applications.
- RealityVoid 12y agoYes, but other people will be able to further develop the ideea in a more satisfactory manner.
- etw 12y agoHey Adam, Would you mind discussing your product over on Product Hunt? What's your twitter id?
- phoet 12y agoyou are pointing out valid concerns. 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?
- mbenjaminsmith 12y agoThose are really good questions. > 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.
- larrybolt 12y agoOffer end-to-end encryption could be solved using a javascript library which encrypts/decrypts the secret in the browser, and passing the key behind a #, kind of the way mega.co.nz does it. Than you can always verify that what you typed actually never get's submitted to the host unencrypted.
- mbenjaminsmith 12y agoBefore I get to far into a topic I'm not an expert in, I'll refer you to these: http://matasano.com/articles/javascript-cryptography/ http://matasano.com/articles/javascript-cryptography/ http://tonyarcieri.com/whats-wrong-with-webcrypto 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.