Slashdot Mirror
Gmail Messages Can Now Self-Destruct
New submitter Amarjeet Singh writes: Dmail is a Chrome extension developed by the people behind Delicious, the social bookmarking app/extension. This extension allows you to set a self-destruct timer on your emails. You can use Dmail to send emails from Gmail as usual, but you will now have a button which can set an self destruct timer of an hour, a day or a week. Dmail claims it will also unlock a feature that won't allow forwarding, meaning only the person you sent your message to will be able to see it.
Please explain.
I know this is ancient technology by today's newfangled social media buzzword bingo, but have those devs ever heard of copy/paste?
BS.
"it will also unlock a feature that won’t allow forwarding, meaning only the person you sent your message to will be able to see it"
Then I'll copy and paste the text to another Windows and foward it.
What the article describes is not e-mail. It's an messaging app with a different protocol using e-mail only as a transport mechanism.
OH LOL!
Look at the screenshot in the second article!
Look at it!
OH LOL! OH LOL! OH LOL! OH LOL! OH LOL! OH LOL! OH LOL! OH LOL! OH LOL! OH LOL!
If this works like I think it works, then the email the recipient gets only has this "View Message" link in it? And then the recipient must maybe view the actual content of the email, which I presume is stored on some other server somewhere? And that's how access to it is limited?
OH LOL! OH LOL! OH LOL! OH LOL! OH LOL! OH LOL! OH LOL! OH LOL! OH LOL! OH LOL! OH LOL! OH LOL! OH LOL! OH LOL! OH LOL!
Can anyone confirm this? Does this just send an email to the recipient, linking to the actual content which is stored somewhere else, on a web server somewhere I would presume? Maybe even somewhere in THE CLOUD?
Can anyone confirm this is what is happening in this case? Anyone?
OH LOL! OH LOL! OH LOL! OH LOL! OH LOL! OH LOL! OH LOL! OH LOL! OH LOL!
I think the idea is that the e-mail itself just contains HTML that makes a request to the Dmail server, and the server doesn't send back the actual message if it's been too long.
But yeah, that doesn't mean that the person can't copy/paste/screenshot something when they see it. It's self-destruct for the lazy/ill-informed.
It's only enforceable because it isn't email.
All this stupid thing is, is a system where the recipient gets a link to click on, which lets them go view the "email" (message) on some server somewhere, subject to a bunch of restrictions. I think there's also a browser plugin that basically does the same thing, but making it appear more like you're reading an email instead of just being redirected to some server.
This isn't email in the traditional SMTP sense.
Of course, it still is impossible for them to prevent you copying it somehow, even if you have to resort to screen capture.
It has nothing to do with Gmail really, it's just a link to let someone view a message on some website. It isn't actually email.
Um... "Print Screen" or "Screen Capture" kinda makes the whole premise of this pointless.
I already have this feature, it's called "Comcast"
Table-ized A.I.
I recall reading about something like this on Slashdot 15 years ago or so. IIRC, that one was an image on a webserver. It was advertised as deletable email.
Didn't work that time. Sounds like more of the same.
That would mean not being able to use pop.gmail.com anymore. I like Sylpheed. I'll just keep doing what I've always done.
I will admit I never get to see the ads that Google peppers their webmail with. I don't feel cheated, however.
If only it were actually Dmail, that would make the whole premise a lot more interesting. Do they also build microwaves?
If you can see it on the screen you can print it to an image, or record the entire interaction with your email client using a screen recorder. If you have the required credentials you can record somebody else's remote desktop too. I would not be surprised if Google block the extension on the grounds that it is deceptive.
It has to only work gmail to gmail, in which case it's entirely dependent on how the receiver is accessing their gmail account. If they are accessing their account through an application like outlook using imap or the native extension then it's probably not going to work. Also there's the obvious problems of screenshot and copy paste. All in all this is probably a terrible idea as it will do nothing more than offer a false sense of security to people who don't know any better.
If it ain't broke, don't fix it.
If it's long you'll need screencasting software. Or are they using some DRM-like technology that'll prevent folks from even photographing the screen. Not much security by obscurity as security by inconvenience.
Their extension can't affect the recipient's end of things if the recipient isn't also running that extension. In that case nothing Dmail can do can prevent the recipient from saving the message, forwarding it or doing anything else with it. Dmail can play tricks with HTML e-mail by replacing the body of the e-mail with a dummy wrapper that fetches the message via HTTP from a Dmail server and they can use some Javascript tricks to try and block "Save as", but those are going to run into problems with anything that blocks remote content or disables Javascript in e-mail. Even if the recipient's using Gmail in Chrome that's going to be an issue considering how that sort of blocking's basic to blocking malware. And of course if the recipient's running a non-browser client using IMAP4, Dmail's completely out of luck.
As far as being able to restrict viewing to only the recipient, that's easy. Every standard mail client today supports it. The hard bit's getting the recipient to generate a public-key certificate and install it as a personal certificate and key in their e-mail client. Then you just encrypt the e-mail using their public key and send it as an S/MIME message, their mail client will automatically decrypt it for them. I could even make that work in web-mail with a browser extension that recognizes the message text block, grabs it and decrypts it and stuffs the results back in the text block for the user to see. The obvious advantages here are that a) you wouldn't need to use any particular service provider to send the mail and b) not even the service provider or e-mail servers would be able to see the cleartext. The hard part's the PKI, and really all that needs is an extension for the mail client to automate generation of a certificate and installation into the client like we have in browsers. Depending on the browser and OS that might be simplified by taking advantage of shared OS cryptography features.
I've kicked this idea around as a commercial possibility, but it all comes down to two basic problems:
The best part is, when you want to send a message to someone that cannot be forwarded and self-destructs, you first have to send it to this Dmail company's server in the cloud where it will exist forever.
And since most of the people using this "non-forwarding self-destructing message system" will be people sending threats and harassment to ex-girlfriends, I wouldn't be a bit surprised if this entire thing is one big honey trap.
You are welcome on my lawn.
Yeah, it was a cute name. The folks running it had a clue, knew what they could and couldn't realistically do.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
http://webcache.googleusercont... or http://cc.bingj.com/cache.aspx...
Back in 2000, a company called Disappearing Inc. made a presentation to the Bay Area Cypherpunks meeting about their product, which was pretty similar except that back then most people used real email clients instead of webmail. When the guy walked in, and we were expecting him to be pushing some kind of snake oil, he started out by saying that their threat model was to let cooperating people have some guarantee that their email would go away when they wanted it to, not to keep uncooperative people from doing that because you just can't stop screenshots / cameras / sender saving a copy / etc. and anybody trying to sell you that is selling snake oil. And suddenly he had a friendly audience, instead of one that was going to beat him up, because he'd defined a problem that could be believably solved, which was cool.
So the trick is that the file's in an encrypted format, and Disappearing Inc's server keeps the keys and a delete date for them, and if the sender and recipient are both using their product, the reader program/plugin/etc. fetches the key from DI's server; if not, you drop the file into an SSL-encrypted web form on DI which decrypts it for you. When the delete date hits (or earlier, if the file's set for read-only-once), DI deletes their copy of the key, so the recipient's mail box now has an encrypted binary blob file with no decryption key. Yes, if the server gets compromised, it's all toast. Yes, if the recipient's email client or browser is compromised at the time they read it, it's all toast. But if nobody's trying to subpoena or crack the message until after the key's deleted, then it's too late to recover old messages, though you can always try to attack new ones.
It was a nice system, and they stayed in business a couple of years before getting bought by somebody who got bought by somebody and disappearing into dead-dot-com-space. Similar systems have been sold by various other companies, often under category names like "Data Loss Protection".
If you wanted to do a "no forwarding" version, you'd do it by setting rules on who could access it, whether by IP address or some ID in the reader plugin or delete-after-one-read or whatever.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Nothing to see here. Move along. Don't feed the samzentroll.
Yes, you could implement it by storing the message contents on a server, but the non-LOL version that Disappearing Inc implemented back in ~2000 sent the encrypted message to the recipient, and only kept the key on the server. If you had a client at the recipient's end, it would fetch the key, otherwise you'd paste it into an SSL form on a web browser that would decrypt it. DI would delete the key after whatever business rules you liked (typically N days, or read-N-times, or "recipient clicks Delete", or sender clicks "Ooops.", etc.)
Does this keep the whole message on the server or just the keys? Hopefully the latter, because it's more secure, but I don't know.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Will this work for people sending messages to other random people? Probably not. But imagine a corporation deploying this system to all of their computers. Suddenly, the boss can tell their employees to do unethical things, make illegal threats, and so on without any chance that the FBI is suddenly going to show up and arrest him with evidence of his misdeeds.
-1 disagree is not a modifier for a reason. -1 troll, flaimbait, redundant, overrated are NOT acceptable substitutes.
I found this from the reviews on the chrome extension site as I didn't bother installing it, WHICH IS STILL MORE THAN THE ARTICLE AUTHOR MANAGED TO DO.
Can't look at it:
http://www.hostinger.in/cpu_ex...
hostinger.in says that the cpu limit has been exceeded.
Remind me never to host anything there since it apparently becomes unreadable under a slight load.
If you're a zombie and you know it, bite your friend!
But that's the whole point. You aren't sending those bits. You're sending a link, and if you decide to remove the message before the person follows the link, they never will get those bits.
Many corporate, "non-Internet" email systems have had "message recall" and "do not forward" features, but these are there just to "keep honest people honest" - they are trivial to defeat.
Even the most sophisticated systems can't easily defeat the "analog hole" of photographing the screen with a film camera (yes, that can be done - movie theaters do it - but it's not really practical in a non-controlled environment).
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
If the email is here, it is here, and nobody is going to delete it.
Oh, it's actually HTML you say? Great, I didn't want to read that crap in the first place.
CLI paste? paste.pr0.tips!
You can keep them by screenshot. You can forward them by screenshot. The security value of this feature is zero. At best it represents a mild annoyance to the receiver that wants to keep or forward them. Snake-oil "security" at its best.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
This. Links in email are dead to me. I don't follow them, my mail client doesn't follow them, it's just so many wasted bytes. And that includes e-cards from friends/relatives. You want to send me something, send it to me, don't ask a third-party to.
(Sure, I make an exception for links I'm expecting (have asked for) but even then I'll copy them to my browser. HTML in my email is turned off.)
-- Alastair
In essence, the email can "self-destruct" if the receiver allows it. I think there might be a slight security problem here, such as the "designers" of this thing not having even a basic understanding of IT security.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
I disagree. It it quite clear that the decrypted email can easily be copied in digital and analog form. This thing is utterly worthless as a security feature.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
And works best on smart watches made from Unobtainium (the bullshit element).
I could be wrong though, and I invite the creators to email me proof to my mail server, where I'll view their proof via IMAP on Icedove. I'll even ensure I view it in the Rich Text subset of HTML and forward copies in mixed format to other interest testers.
In other news Ted Turner spent his whole day smoking joints instead of just one before breakfast. Jane must of locked him out of the bedroom again.
This approach to special-handling-required email is pretty common - if the recipient has the right software (client / app / browser extension / whatever), their email client can read it directly, otherwise they have to use a web link to the provider's server. The more secure and scalable versions store only keys of some kind on the server, and include the encoded or encrypted message in the email, the simpler but less scalable and less secure ones keep it on the server and just include a link in the email.
Disappearing Inc did that back in 2000 for a self-destructing email application, and I've seen similar things for encrypted mail (e.g. Voltage Secure Mail) and other applications (often marketed as "Data Loss Prevention" or whatever), mostly for corporate users.
And yeah, if I get email from some random stranger saying "You've received a Whiffly-Mail Message, Click Here to Download", it's going in the spam bucket, but if I get it from somebody I regularly deal with I'm fairly likely to open it. Can't be much worse than opening a Microsoft Word document from a stranger. And of course, if it's from Paypal or SomeBigBank or Microsoft Technical Support, it gets junked as well.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
No, I disagree with it being "unclear why the decrypted version cannot be saved or otherwise copied in some manner". It is quite clear that it can.
Some reading comprehension required when trying to tell other people what they mean to say....
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Once that email is in the wind... its free... you're not calling anything back unless you control the receiver's email server.
I've decided to stop wasting my time responding to AC trolls/sockpuppets... so if you want a response from me... login.
Certainly in work situations a part of me dies whenever I'm sent emails with documents attached - doubly so when it's an Excel 'form' to be completed and sent back (presumably to some poor soul who ends up copy/pasting multiple replies into a 'master').
Consider this exchange between the canonical pair, Alice and Bob:
Alice works for ACME
Bob works for BizCo
They work out a scheme to make trade between the two easier and more efficient.
Alice sends the details in a document attached to an e-mail to Bob.
To cover her back she also sends a copy to her manager Agnes and Alan in commercial and possibly Alberta in procurement. These could also forward it on to Alison, Agatha, Alfred...
When Bob receives it, he also wants to protect himself so sends copies to Bill, Betty and Bertha at his office; similarly Brian, Barbara.... could receive copies.
There are now at least EIGHT copies in existence.
Alice and Bob may want to make minor changes, so may Alan and Betty ....
What odds would you give that in a few weeks that all are working to the same document version ? If you believe that all will be aligned, I have a nice bridge I can sell you at a knock down price. Embedding documents in e-mails can increase data but destroy information
By having just one copy and exchanging links, the confusion can be avoided.
All that said - for personal e-mails, this is less of a worry.
That's spam or phishing in my book -- stuff I delete within after a 0.1 sec scan.
they can claim whatever they want, but it won't work on any other mailclient (unless the specific mailclients are going to implement the feature, and guess what, don't count on it)....
I don't remote load anything in email. Spyware and other malware is all too common.
An SQL query goes to a bar, walks up to a table and asks, "Mind if I join you?"
The second like in the article is spam.
An SQL query goes to a bar, walks up to a table and asks, "Mind if I join you?"
a good use for the HCF instruction
This would not work that well with gmail; images are cached by gmail's servers, and I'm pretty sure any form of "intelligence" in an html mail is sure to fail too on their interface.
The "view your message here" link hypothesis seem more realistic (and sillier but meh).
... that's not how any of this works!
Atari rules... ermm... ruled.
Not for me then. I'll be damned if I'll click on an executable, a script, follow a link somewhere else, when it's in an email. I learned long ago, you just don't do that.
cool newssite you linked. "cpulimit exceeded" Muhahahahahaha
I have seen systems that prevent screen capture as well.
We have some standards documents which must be purchased. In order to prevent copyright theft, the distributor of the PDF files requires software on your computer which will actively disable the native clipboard and screenshot capabilities while the PDF is open. In addition, the software will look for common screenshot software like snagit and greenshot and force them to close before you can launch the PDF.
Despite all of that, a user could still abuse the spirit of the rules in this case by using the 1 allowed hard copy to print out the entire standards doc and then scan it back into the system...
So, I guess my point is, you could lock down the screenshot bit... perhaps you could also lock down the picture capability too by interfering with interlacing and/or refresh rates somehow.... but I guess it just depends on how far you are willing to go...
My eyes reflect the stars and a smile lights up my face.
This is a valid concept so long as both parties agree to uphold the privacy. However, that's a big "if."
Chewbacon
The Bible is like Wikipedia: written by a bunch of people and verifiable by questionable sources.
perhaps you could also lock down the picture capability too by interfering with interlacing and/or refresh rates somehow.
Interlacing? Refresh rates? This is 2015, those things don't apply any more: everyone has LCD now. Software has no real control over the display.
We have some standards documents which must be purchased. In order to prevent copyright theft, the distributor of the PDF files requires software on your computer which will actively disable the native clipboard and screenshot capabilities while the PDF is open. In addition, the software will look for common screenshot software like snagit and greenshot and force them to close before you can launch the PDF.
This sounds like malware to me.
And there are a bunch of similar applications for which you might want to be able to verify that the mail's only going where it should, and that it won't stick around as a legal record longer than you want it to.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
a user could still abuse the spirit of the rules in this case by using the 1 allowed hard copy to print out the entire standards doc and then scan it back into the system...
Can you print to a PDF printer, or print to a Postscript file to be turned into a PDF file later?
I know.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
It's either a web-service that emails a hyperlink to the message (which can be easily extracted), or something that only works if the recipient installs the same extension. In either case, why would a recipient voluntarily restrict their own access?