Just curious. I’ve no need but is there is there any email that deletes automatically after the recipient opens it i.e. they cannot save or forward or print.
I don’t see how. One can always take a screenshot.
[ Apart from the more sophisticated softwares such as my go-to KSnapshot, I’ve been looking for a Tabbed Image Viewer for years, and now just came across XNView: to my surprise, even that has a desktop capture facility under tools. ]
If they’ve viewed it on a computer, they already have a copy of it. That’s how this works: Computers can only show you what they have, and so they already have a copy of what they show. Someone can, as has been said, take a screenshot of anything, if nothing else, but it’s likely they can save it in a more convenient form, too.
You could have an email which was a link to a website, and that could do most of what you want.
There are mail clients that will limit the receiver’s ability to forward or save the mail, which works if you know what client they’re using and are worried about stopping unsophisticated users from casually copying the email. There’s nothing that will actually do what you asked in the OP, though. If nothing else, someone reading the mail could take a picture of their monitor to preserve the information, and in practice there are numerous other ways to copy or save data like that. Plus most deletions aren’t really permanent immediately, it’s often possible for a technical user or sysadmin to recover a deleted email.
Using a website couldn’t stop them from taking a picture of the computer screen to preserve the data, though. Also couldn’t actually stop someone from intercepting the data between the website and PC screen, though that would be a lot of work.
Confide
Or simply using the built in print function of the browser, or doing a cut and paste to the text editor of choice.
It’s impossible to do securely. If the other person can see it with their eyes, they can see it with a camera. Or a screenshot utility. Or they can pull it out of the computer memory. Or etc etc.
It’s possible to do casually. There are services like Dmail which can prevent forwarding and can delete the message after a certain time.
There are some mobile apps that allow you to send self destructing messages (not emails that I’m aware of but I’ve never looked). Some of these messaging apps also disable a phone’s screenshot capability but that’s probably easy to work around and someone with a camera could always take a photo of the phone.
Yeah, but all that stuff can be javascripted off.
Although that won’t prevent sophisticated users from circumventing your protection.
One can turn off javascript on a temporary basis.
Reading comprehension…
Could you send an audio-message to someone, that can be played and listened to only once?
If you send it on magnetic cassette, you can do it - put a little magnet inside the case near the take-up spool and it erases the tape as it is played (unless the recipient notices before playing it and removed the magnet)
To send a one-time audio message in electronic form, I think you’d have to do something like:
[ul]
[li]Develop your own audio format and your own player application that phones home and will only play any particular file once[/li][li]Send a link to a web player that will only play the hosted linked audio once[/li][/ul]
In either case, if the sound comes out of the speakers, you could just record it using a microphone, or in many cases, the recipient would be able to record the audio inside the computer as it plays (for example using Audacity and setting the source as ‘mixed audio’ - which means ‘whatever noises the computer is making through the soundcard’)
If you just invented a self-destructing file type (they don’t generally exist already), there wouldn’t be anything to prevent the recipient from dragging a fresh copy out of their mailbox and playing that.
… because they’re impossible, in general. Programs can self-destruct, if they’re allowed to, but running the same program on multiple kinds of computer is not trivial. Even the systems which kinda solve the problem don’t, in general, solve the problem, because they require people to install whole runtime environments on their computers, which is not going to happen in many cases, for reasons technical, social, and tech-support-related. Long story short, emailing them something written in Java is right out.
The only way to run arbitrary code on a modern system without the massive hassle of emailing them an executable is to email them an HTML document with Javascript in it. The problem (from your perspective) is that Javascript is run in a sandbox such that it cannot access files in any general fashion, so deleting itself (or even finding out where it is in the local filesystem, most likely) is impossible by design. It’s considered basic security practice for reasons which should be obvious after a few minutes’ worth of sneaky, pretend-you’re-an-attacker thinking.
This is true as well, and I did read it before I composed my post, but I really want to hit the other topics hard as well. The fact is, many people have had thoughts along these lines, and there are multiple lines of defense against such antisocial behavior.
Agreed - in general, a file that is attempting to self-destruct would by definition have to be an executable process, and I agree with your analysis of how hard that would be to implement in a cross platform sense.
I guess it would be possible to develop some kind of secure self-destructing protocol that requires certificates and end to end encryption (in a similar way that end to end DRM has been proposed for audiovisual media) - the clients capable of displaying it will honour the self-destruct part, but the moment that’s done, people will be working on defeating it, and the idea does heavily depend on being in strict control of the domain to the extent that you can prevent a rogue implementation of the protocol that ignores the destruct part.
Encryption and certification could possibly make such a thing practically difficult-to-impossible to reverse engineer, but today’s impossible often turns out to be tomorrow’s easy.
And of course the physical world is difficult to control - how do you prevent people taking a cellphone image of something on their screen? - it’s been tried with clients that display images where moving objects obscure parts of the image at a time, but that degrades the viewing experience, and could probably be fairly easily defeated by sampling and recomposing the whole. There’s no really satisfactory solution to the problem.
I’d say a link to a one-use website comes the closest: of course you can’t prevent anyone from printing anything, but you would not be able to forward or save the actual message.
Of course, this does not prevent the information from being useful to the recipient, however, it does provide plausible deniability in that you can claim that the recipient simply altered the printout / screenshot / html if they forward damaging information.
Yes, once you obey Kerckhoffs’ principle (in a secure system, the only secret is the key) you’ve given away the keys to this particular kingdom, because of the possibility of rogue implementations. On the other hand, Kerckhoffs’ principle is adhered to for a reason: You (the sneaky would-be DRM implementer) are not more clever than everyone who would test their might against the DRM you have implemented. You have to win a thousand times, but each of the thousand people you’re up against only have to win once.
Is it possible to win against not a thousand, but a dozen people? Perhaps, but once you know for a fact that your system will never be used outside a small circle of friends, or a small company, it becomes easier to attack the underlying problem (people making and potentially leaking copies they shouldn’t) in a less technological, more social fashion. Build trust instead of cryptosystems. Or, if that fails, make a few dozen minor variants on the same text, and figure out who leaks stuff by tracking which specific variant got leaked.
Don’t try to pick the lock when the window’s probably open. Encryption primitives like DES and so on are probably more secure than not, so collateral attacks on things like RAM dumps are more likely to be fruitful.
Moreover, the more control you have over the execution environment, the longer your DRM scheme is likely to last. Game consoles should be able to take advantage of this… except game consoles are in people’s homes, where the desoldering tools and logic probes are. Your nice little closed environment inside the game console is embedded in a deeply, arbitrarily hostile physical environment you have no control over. In the immortal words of Bokosuka Wars, “WOW! YOU LOSE!”
There’s a final twist to this: Security and convenience are almost inevitably at odds. For everything you want to ban on the grounds it may serve to leak data, there’s a perfectly innocent reason to want to do that, such that making it impossible would make it harder for innocent people to do useful work. There’s a reason secure environments become insecure in practice.
This is possibly the best response, go all you-said-I-said and try to gaslight whoever you’re emailing if they ever come forwards with information which goes against the current party line. Maybe rats in boxes get involved.
The Computer Is Your Friend.
The server-controlled message comes closest, but there are problems with that too, mainly around how the server identifies the user and determines whether she’s read the message previously. You could use the client’s IP address, but an IP address can change due to DHCP expiration, can be spoofed fairly easily, and multiple users behind a NAT firewall would all get treated as if they were one person. But nothing is going to protect against screenshots or photos of the screen.
Thanks. Most respondents took it as being much more serious than I was. The reference to Dmail was the sort of thing I was musing about.