Earlier this week, my new app SeeOnce was rejected (hopefully only temporarily) by the iOS app store for allegedly misleading users into thinking that it could make self-destructing messages. Leaving aside what exactly “self-destruct” means for a digital message and whether or not SeeOnce actually achieves this, a number of current and past apps have claimed precisely this. In this article, companion to the one on Privnote vs. SeeOnce, I go over these apps, how they work, and how they can be used most profitably.
First off, my sources for this. Here they are:
8 Online Services to Send Messages that Auto Delete after Reading (2012)
This Message Will Self Destruct. Or Will It? (2013)
With Tor Mail gone, how will the Dark Web communicate? (2013)
Going through those articles, you discover that there are a lot of apps and websites that purport to supply self-destruct messaging, usually in the form of a link that leads to the message when clicked on. Here are some examples:
Privnote (https://privnote.com). This is the one I discussed in detail in this other article. They have been around for at least eight years now (2015). Very simple interface (with ads). The message is encrypted and sent to their servers. The link produced by the app contains the location of the message in their servers, plus the decryption key if this was not supplied by the sender.
Temp PM (https://temp.pm). Very similar to Privnote but without ads. No read receipts, though. Messages don’t seem to be encrypted in their servers in a way that the server administrators cannot read them.
TMWSD (https://thismessagewillselfdestruct.com). No ads, no receipts, but you can generate several links for the same message, presumably so several people can get it. Same problem with server privacy as temp.pm.
Crypt-a-Byte (https://cryptabyte.com/SelfDestruct). Same as temp.pm, except that you cannot add another encryption as in the other programs. It will email the link for you, though.
They all operate in more or less the same way. The user enters the plain text in a web form, and after clicking a button the program sends it to the server, where it gets encrypted (using the user-supplied key, or a random key if the user didn’t specify one) and stored in an indexed location with a temporary random address. At the same time, it creates a link containing the location in the server and the decryption key, if it is not user-supplied. When the recipient clicks on the link, the encrypted data is fetched from the server and then decrypted locally. Then the server deletes the data it possesses, so that clicking the same link again results in an error because the data isn’t there anymore.
First, we have to understand how this isn’t really secure. If the link is compromised, and we must assume it might be if we send it by email or regular texting, then those obtaining the link can get the confidential plaintext as easily as the intended recipient if there is no user-supplied encryption key, because there is nothing in the process that can identify the right recipient. This is why the majority of these services offer the option to specify the encryption key, which then is not included in the link. Of course in this case the sender has to send the decryption key by some secure channel, but that doesn’t seem to bother these services.
Now, if we were to combine these services with some kind of public-key encryption code, then we’d have a system that possesses both security and a good amount of forward secrecy. For instance, try this:
- Open PassLok and enter your personal Key. Then enter the message into PassLok, select your recipient from the list, and lock the message in Anonymous mode.
- Copy the result and paste it into any of the services mentioned above. Don’t worry about additional encryption or the administrators being able to see your message, since it is encrypted anyway. Click the button and get a short link, which is what you send to your friend.
- The recipient will click the link and retrieve the PassLok-encrypted message, thus deleting it from the server, then copy and paste it into PassLok in order to retrieve the plain text.
Perfect forward secrecy is still elusive, however, since the self-destruct service may still have a copy of the encrypted message. They say they deleted it, but they cannot prove it to you. In any case, this is likely better than sending the message by regular email, which keeps your data forever.