Hacker Newsnew | comments | show | ask | jobs | submit login
Show HN: Emails that Self-Destruct and Notify You When Read (ghostmailapp.com)
27 points by rxl 929 days ago | 44 comments



I'd be leery of this.

Once someone sends me an email, barring any prior agreement, it's mine. I may not own the ideas therein, but I certainly can claim enough ownership that the sender destroying the email irrevocably, without my consent, should raise some flags.

I'm seeing parallels with those useless "this email is confidential, private property, etc." footers that people stick on their emails.

-----


It's called a screenshot. Even my mother knows how to make one – it's built into OS X, Windows, iOS, and Android. So really this is a step backwards from the "light the paper on fire" level of security 007 had back in the '60s.

-----


Not sure what you guys are defining an email as these days, but all I get is the following text:

"NOTE: This email's content (shown below) will self-destruct after being viewed. -Sent w/ ghostmail <http://www.ghostmailapp.com/>

And nothing else. Plus when I re-open the message I get the same thing.

-----


What email client are you using? Are you rendering the html in the email? There should be an image displayed below that text.

-----


You may want to read through this - http://www.campaignmonitor.com/resources/will-it-work/image-...

Not loading remote images is a norm for email clients.

-----


Bit more than just ‘not loading’ — certainly any email I receive that attempts to load remote resources is presumed to be malicious. (In this case, that presumption is correct.)

-----


Thunderbird, with HTML disabled (because its a mail client, not a web browser)

-----


I see some criticisms (that I agree with) of the "security" model here.

Implementing the self destruction protection on the client is problematic (even in the case of SnapChat) because the end user is in control of the client. So if users are motivated enough they'll be able to circumvent any protections you implement.

The nice thing is that most users are not motivated enough to do what's necessary to retrieve the self-destructing messages. It's a lot easier to save the message when sent to a web client but it's still beyond the ability of most users.

So no these applications aren't providing real security but it's close enough for the types of messages that I assume people are sending.

-----


This has been done before, in many variations. There's always a way for the recipient to save a copy. At least this scheme doesn't require special client software.

Note that this depends on the recipient's email client making a request for the image, which, thankfully, most clients provide a way to turn off.

-----


It's an interesting concept, and I will always give a lot of credit for the sheer act of building something. But talk to us about the need and the use case here. Snapchat I understand -- but is there really a big need for self-destructing emails? If anything, the real problem in the email space is long-term storage and management.

I see the email space and the SMS/text space diverging into very separate use cases: email for long form communications that, if anything, are to be saved and filed; SMS for short-form communications that are disposable (literally, in the case of Snapchat, or figuratively). I get that there are long-form communications that are sensitive, and that we sometimes wish wouldn't stick around forever. But what proportion of all email conversations do we think this use case represents?

-----


You bring up a valid concern - I'd say that this isn't something that you'd use all the time with your email, but it has its time and place (just like off-the-record gchat), and when it is needed, it really comes in handy.

-----


I don't think there should be such a drastic boundary between SMS and email, IMO the separation between the two should be more freeform and vague.

-----


This has been done several times. The first that I can remember was "Disappearing Inc" http://www.wired.com/science/discoveries/news/2000/02/34171 IIRC they were shut down by the feds/spooks.

-----


Nah, they changed their name to Omniva and used their technology for corporate email/document management (read: delete those emails before they are subpoenaed). Then they were bought out by Liquid Machines, and the product lives on as Liquid Machines Email Control.

I think the money just wasn't there for public use.

-----


Use case: when you don't want your email hanging around on the other guys server. Ex. sending credit card information to a hotel. You want them to get it, ie. you trust them enough, but you can't trust their email security for the next 4 years.

Think how someone like General Patreaus could have benefited! He trusted Broadwell (perhaps his main mistake), but unfortunately for him the email hung around long enough for the FBI. :))

Also, docs say email is destroyed as soon at is read. No 7 days (couldn't find that).

-----


This wording suggests you keep the contents of the email around. I would clarify that:

the server makes a note not to supply that image ever again

-----


How does the wording suggest that? All it implies is that an image identifier is maintained, and once viewed, it's marked as stale and never served again.

-----


Exactly. If the whole point of the app is that the email is deleted as far as the recipient is concerned why not delete it from the server too? If you're never going to serve it again, delete it. Then you definitely can't accidentally serve it (or nobody can compel you to provide access to it).

The wording could be more precise.

-----


Related: https://onetimesecret.com

(I am unaffiliated, just like this service.)

-----


Thanks for the mention.

-----


oh hey, you did blamestella as well? nice work!

-----


Thanks. I appreciate it!

-----


The only use case I could think of was those ATM Pins that you receive which always say "destroy this letter after you memorize your pin". So you could email a pin/some sort of sensitive info and have some level of safety.

Obviously the person can choose to save the image but you could also not destroy your ATM Pin Letter and/or even photocopy it.

-----


When a landlord is doing a credit check, you can also send your SSN with some peace of mind.

-----


Wouldn't that fall under the "seriously sensitive information" that is recommended not to be sent? From the FAQ:

"That being said, you should always be careful. We recommend you do not send any seriously sensitive information through Ghostmail and refrain from corresponding with people you do not trust."

That being said, congrats on building something. I still haven't gotten that far.

-----


Agreed, I seriously wouldn't recommend sending that information online at all, but the unfortunate thing is that some people send it through email anyway. A more appropriate use case would be to send a secret that isn't damning, but that you'd just prefer wouldn't stick around in someone's inbox.

-----


You should never send primary account numbers[0] over unencrypted protocol or to any system that will store it unencrypted.

While most email systems communicate over encrypted protocols, very few encrypt their data store.

For security's sake, please never send your SSN over email for any reason.

[0] Your SSN is your Primary Account Number for the United States.

-----


Use https://onetimesecret.com/ instead.

-----


Couldn't you just save the hosted image before it disappears? I don't see the value in this?

-----


You could also record all of your phone conversations and copy all of your off-the-record gchats into text documents, couldn't you? The point isn't for this to be absolutely foolproof, but rather that when you have a somewhat sensitive conversation with someone you trust, you can have some peace of mind that there won't be a hard record of what you are saying.

-----


This service converts your email into an image. You can save a copy of the image, and keep it forever, even though the mail will disappear. It's novel, but I'm not sure I see use-case for it.

-----


Think about gchat's off-the-record feature. Anyone can copy and paste an entire conversation, but the thing is, most people aren't motivated enough to copy every single one, so you have an added element of safety. Further, everyone I use ghcat off-the-record with is someone I trust - I just don't want a copy of the chat sitting in their email.

-----


Does this mitigate screenshots in any meaningful way? And how does it address browser caching?

-----


It's just text in a remotely hosted bitmap. No logic, no protection.

-----


Rendering text as a hosted bitmap that can be viewed only once. Cute. But what is this for?

-----


One word: Discovery

As in, "Whenever we are sued, we have to undergo Discovery, and they find all those email we really wish had never seen the light of day..."

-----


As in, "Dog ate my homework"? That should work with feds, no problem.

-----


"Not only did we not know that we were required to retain these emails, we went out of our way to ensure they /couldn't/ be retained. Whelp, oh well!"

-----


If, as a public corporation, you were to do that you'd end up being sued anyway. Sarbanes-Oxley not only requires e-mail retention, but the SEC can impose significant fines if e-mails end up 'disappearing'.

To put it another way: if you turned around during discovery and told the other party you'd deliberately used a system that caused all your e-mails to self-destruct you could expect to be destroyed in court.

-----


EDS had a 20 Megabyte Email quota in 2002/2003 in order to "conserve resources" - basically meant there was a 30-45 day window before you had to start deleting email.

-----


Their FAQ says they delete the server copy after 7 days

-----


It still doenst solve the problem: many email clients cache images that are downloaded...

-----


Sending pointless emails?

-----


This is such a cool idea. I would email my number to random girls I met on a Friday night haha... "hurry up and save my number orrrrrrrr I will disappear" lol

Nice execution.

-----




Applications are open for YC Winter 2016

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: