I understand your skepticism. I was skeptical too. I'll try to address your points. Please let me know if I you think I've missed something...
I do hope you encrypt the mail reading session with a separate key - otherwise the clear text is going over the network between DI and the receipient.
That is, in fact, the plan.
And you need to hope that the receipient will not hit the "Save as" button on his or her web browser ("for convenience").
Yes. The sender must trust the recipient to not subvert the system before the key is deleted. This level of trust is implicit in any system of this kind. We can't prevent someone from taking a picture of their computer screen either.:-)
Then there is browser caches,
HTML forms are not generally cached to disk. A more likely leak along these lines is swap files. I discussed those in my original message.
Web proxies
https should address that.
and so on - there are more ways to attack this than I can count on my fingers (in binary).
If you describe the other attack methods, I'll try to address those too.
The whole concept sounds like nonsense to me - if you trust the receipient at all, you can just have him delete the email after being done with it.
I can think of a lot of recipients that I would trust to not intentionally reveal a private conversation, but that I definitely would not trust to be competent enough to completely delete a message after being done with it. Just about anybody non-technical falls into that category. "Yeah, I deleted it. I clicked that X button. Whaddaya mean that isn't enough? I can't see it anymore..." You get the idea.
IMHO, it won't work, as people will either be forced to use a specific e-mail product, or there will be a high risk of the self-destruct system not working.
Any recipient with a web browser can read the email. The ciphertext is stuffed in an HTML attachment and decrypted at the DI website if the recipient doesn't have a DI-enabled client. Since the key is maintained (and destroyed) on a central server, the (poorly named) self-destruct system is not dependent on the client.
Even if the message DOES self-destruct, so what? You can scan a hard-disk and read off the last 10 or so layers of data, which might include the non-encrypted form, or the encrypted form with a valid key. From there, it'd be child's play to get the message.
Only the ciphertext is stored to disk. Both the key and cleartext are held in memory. There is a small risk that the cleartext (not the key) could be swapped to disk while the message is being viewed in a browser, but the swap file would be overwritten more than 10 times in a relatively short period of time.
There are far, far better ways to secure e-mail from prying eyes.
I assume you are referring to PGP and/or S/MIME. IMO, the big advantage to DI's approach is that it allows for temporary trust. To send you a traditional secure email, I must trust you to never reveal it to a third party, either maliciously, accidentally, or under duress (e.g. court order). To send you a DI email, I only need to trust you to not reveal it until the key is deleted.
Slashdot Mirror
I understand your skepticism. I was skeptical too. I'll try to address your points. Please let me know if I you think I've missed something...
That is, in fact, the plan.
Yes. The sender must trust the recipient to not subvert the system before the key is deleted. This level of trust is implicit in any system of this kind. We can't prevent someone from taking a picture of their computer screen either. :-)
HTML forms are not generally cached to disk. A more likely leak along these lines is swap files. I discussed those in my original message.
https should address that.
If you describe the other attack methods, I'll try to address those too.
I can think of a lot of recipients that I would trust to not intentionally reveal a private conversation, but that I definitely would not trust to be competent enough to completely delete a message after being done with it. Just about anybody non-technical falls into that category. "Yeah, I deleted it. I clicked that X button. Whaddaya mean that isn't enough? I can't see it anymore..." You get the idea.Disclosure: I work for Disappearing Inc.
Any recipient with a web browser can read the email. The ciphertext is stuffed in an HTML attachment and decrypted at the DI website if the recipient doesn't have a DI-enabled client. Since the key is maintained (and destroyed) on a central server, the (poorly named) self-destruct system is not dependent on the client.
Only the ciphertext is stored to disk. Both the key and cleartext are held in memory. There is a small risk that the cleartext (not the key) could be swapped to disk while the message is being viewed in a browser, but the swap file would be overwritten more than 10 times in a relatively short period of time.
I assume you are referring to PGP and/or S/MIME. IMO, the big advantage to DI's approach is that it allows for temporary trust. To send you a traditional secure email, I must trust you to never reveal it to a third party, either maliciously, accidentally, or under duress (e.g. court order). To send you a DI email, I only need to trust you to not reveal it until the key is deleted.