Vanish: self-destruct your own data


The Vanish project proposes to give web users control over the lifespan of the data they post online, or to cloud computing services. Vanish encrypts your data, and all of it, even cached or archived chunks, become "permanently unreadable" at a date of your choosing, without any action on the part of the service provider or end-user.

For example, using the Firefox Vanish plugin, a user can create an email, a Google Doc document, a Facebook message, or a blog comment -- specifying that the document or message should "vanish" in 8 hours. Before that 8-hour timeout expires, anyone who has access to the data can read it; however after that timer expires, nobody can read that web content -- not the user, not Google, not Facebook, not a hacker who breaks into the cloud service, and not even someone who obtains a warrant for that data. That data -- regardless of where stored or archived prior to the timeout -- simply self-destructs and becomes permanently unreadable.
Vanish: Self-Destructing Digital Data. See also this related University of Washington press release. Vanish authors: Roxana Geambasu, Yoshi Kohno, Amit Levy, Hank Levy.
(via Jake Appelbaum)


  1. Cute tool but not useful for business. Business need to keep track of their communications and store them (IM, Email, etc). Something like this would be in violation of those standards and could get you into alot of hot water.

  2. @Xeno, I was thinking the same thing. Government agencies and any businesses with the obligation to keep copies of communications for discovery purposes, in the event of possible lawsuits — what would be the legalities there, in the USA? It would be interesting to hear any legal experts weigh in on this one.

  3. who’s gone through the code line by line to make sure “Vanish” doesn’t also include “copy and send to Langley”?

  4. @Takuan, that’s a fair question, but spend some time with the documentation. It sounds pretty clean to me.

  5. Speaking as a computer scientist, this is interesting work, but I see no practical application. It cannot prevent copying and retention of cleartext by users or archival of public keystores by others, so it does not deliver any value in any real-world use.

    I’d like to be corrected if I have misunderstood the work, though.

  6. Could this be done to someone else? Is it retroactive, or can it only work on new things you’ve posted? Can you edit an existing post so that it gets vaporized?

  7. @aelfscine:


    No, and only on new things if everyone agrees not to copy and paste content or save publicly accessible keys.

    No, unless you are OK with embedding blobs of gibberish in existing text and telling people to install a tool if they want to read it.

  8. @ Ito Kagehisa:

    Speaking as a non-computer scientist, I can see many practical applications. You’re dead-on with respect to how the thing works… it can’t, for instance, prevent me from installing a keylogger onto my computer, to determine what it was that my teenage daughter wrote to her boyfriend, but text and email aren’t the only things that this service would be useful for.

    MP3s, for instance, could have trial periods. Presumably so could movies, RAR files, PDFs, ad infinitum. This is exceptionally useful if you’re not so concerned with a few people figuring out how to save your data. Let’s say I have a netlabel, where MP3s are sold. A user could preview the file for a few hours, to see if they wanted to purchase the record.

  9. This is a form of DRM. It is doomed to fail in practice for the same reason that DRM always will; it relies on encryption in a scenario where the intended recipient and the adversary are the same person.

  10. It sounds a lot like snake oil but the paper is pretty neat. This is not breakthrough research but I can become pretty handy if the applications take on with regular users (and they care about that it seems).

    Obviously it’s not a miracle solution and you need to understand what it can’t protect you from but for things like documents that are meant to be “semi-public” but that you don’t really wish to be archived publicly in Google Cache or whatever, it sounds good.

  11. @ mcfarland

    From my understanding of URLCrypt, it is similar to the commercially available (since at least 1999 it seems) solutions cited in the “Related Work” section of the Vanish paper. It requires a centralized keys server that you need to trust. Vanish requires a DHT and you don’t really need to trust any node, you “just” need to trust a certain number of nodes (that you can make arbitrarily large up to a certain point) not to collaborate against you (a bit like Tor but with different uses and goals).

  12. Ah, thank you, Takeshi-san! I still don’t see a lot of applications, but there definitely are some. I think my mistake was I wasn’t looking at it from a market perspective.

  13. @takeshi: You have to install a plugin to decrypt the content in the first place – how much more trouble is it to instead install the plugin which decrypts the content and saves it as a permanently accessible plaintext file?

    I could see the system at least making it inconvenient or complicated for people to get at the plaintext if they first access it after the key has “expired”.

    But if an individual decrypts the file as intended, it’s extremely trivial for them to preserve the plaintext for themselves forever. This makes the system pretty useless for scenarios where you want to give a user a file and then have it disappear against their will later.

  14. @#16 Zikzak: “This makes the system pretty useless for scenarios where you want to give a user a file and then have it disappear against their will later.”

    For that, you need a Kindle.

  15. The research paper does address (or at least acknowledge) the problem of untrusted recipients:

    Two key properties of our threat model are:

    1. Trusted data owners. Users with legitimate access to the same VDOs trust each other.


    The former aspect of the threat model is straightforward, and in fact is a shared assumption with traditional encryption schemes: it would be impossible for our system to protect against a uer who chooses to leak or permanently preserve the cleartext contents of a VDO-encapsulated file through out-of-band means. For example, if Ann sends Carla a VDO-encapsulated email, Ann must trust Carla not to print and store a hard-copy of the email in cleartext.

    Given that they know this is a problem, it’s odd that they’ve included in the overview two uses for which it would clearly be unsuitable: facebook messages and blog comments. I guess what it could provide in that case is deniability.

  16. Ito Kagehisa and others:

    I can think of other applications, possibly closer to what the authors have in mind:

    1) The information is un-subpoenable or otherwise unhackable after the eight hours. If I am dealing with a client or fellow secret agent, I am probably less worried about him copying the plain-text than I am of the government demanding that Google turn over its records of my emails. Google could turn them over, but there’d be nothing there.

    Likewise, I may be reasonably sure that both me and my associate are on a secure network for the next few hours, but who’s to say that one of our computers doesn’t get jacked tomorrow? With this system, tomorrow there would be nothing there to see.

    You’re assuming that I want the document to disappear from the receiver’s hands in eight hours (maybe as a “trial period” DRM system), but I think it’s more likely that this is to prevent snooping third-parties.

    2) Deniability. If I send you insider-trading tips by email, and you blab to the SEC, they could verify the email I sent. But if I send it using this system, even if you saved the plain-text, there’s no way to prove that the plain text was the email I sent. The encrypted email I sent could have been anything at all.

  17. It’s an old idea that has been attempted many times, and like all the other attempts, it doesn’t really work. More precisely, it is no different to (a) encrypting all your mail with openpgp, and (b) adding a note to the mail saying “please delete after 8 hours”, except for the detail that it doesn’t require the receiving user to remember to do it.

    It is *not* *possible* for any system to deliver better results than this.

    Since it doesn’t really work, it’s not really useful. I predict that this will have no impact on sales (justifying this prediction with all the “full disk encryption” systems being deployed by large corporations that do not really work and are trivially defeated, yet continue to be purchased and deployed anyway).

  18. asuffield: Can you back that up, or explain?

    Using openpgp, you could be subpoenaed for your encryption key (maybe, I’ve seen claims for and against this), or otherwise voluntarily give it up, and then third parties could unencrypt the files and see the results.

    With this it seems to me that neither party ever knows the key, and it disappears over time, making unencryption many times more difficult.

    I admit I don’t quite understand how the p2p system works that allows the keys to disappear over time, but I haven’t read the paper.

  19. Using openpgp, you could be subpoenaed for your encryption key (maybe, I’ve seen claims for and against this), or otherwise voluntarily give it up, and then third parties could unencrypt the files and see the results.

    Good luck with unencrypting a deleted file – and if you’re going for an ‘interception’ argument, vanish is vulnerable to interception in transit.

    It generates a session key, and encrypts the data with it. It splits the session key into pieces. It then generates an access key, and uses that key to derive some randomly selected locations, and uploads one piece of the key to each of those locations (for unrestricted public download by anybody who knows where to look), then mails the access key and encrypted data to the recipient.

    That doesn’t really buy you anything unless you are dealing with an attacker who is capable of intercepting email but not capable of intercepting P2P traffic – and if you were, you could just upload the regular openpgp-encrypted document to the P2P network and have done with it.

    If you aren’t worried about interception, but only recovery after the fact, then you merely need to securely delete the files (remember that it wasn’t intercepted, so nobody else has a copy). You don’t even need cryptography for that.

  20. Does nobody understand that google’s cache or the wayback machine may make copies?

    The point is that the cached copy is the encrypted one, which becomes useless after the key is destroyed.

  21. like url referers like tinyurl I do not see any benefit from trusting a large corporation (or a small one for that matter) with matters better off handled by myself.

    its like letting other people lick your food before you eat it.


    paying them to do it.

  22. I love it. For the simple fact that up until now, *EVERYTHING* you’ve ever written on Internet has been recorded. Things you wrote back in your University days, or after a night’s drinking, or simply expressing a passing opinion on a non-transcendental subject.. which could get you in trouble with prospective employers or your newly acquired celebrity status.

    I rather Internet didn’t record everything I write and kept a register – forever. If all the comments online I ever made were deleted after five years, I’d be happy with that. And if I could choose which ones to delete, and which ones are actually useful for future generations, even better.

    We talk about ‘big brother’ a lot these days, but sometimes Internet is the biggest, millions-strong big brother.

  23. @ asuffield:

    If you aren’t worried about interception, but only recovery after the fact, then you merely need to securely delete the files (remember that it wasn’t intercepted, so nobody else has a copy). You don’t even need cryptography for that.

    I still think you’re missing the point. If I send you the encrypted file by email, it doesn’t matter if you delete it. You can delete it from your computer, and you can delete it from your email, but there is no guarantee that it has been deleted from Google’s database. That part is out of your control.

    The point is that we are now in an age where we don’t have any control over whether our data remains after it gets transmitted or posted over the internet. It could exist on dozens of different servers or databases, ready to be hacked or subpoenaed at any time. (See e.g. Hushmail).

    So while you could argue over the technicalities of whether the p2p system makes sense, it seems illogical to say that this is “the same” as simply asking the other person to delete the file. The entire reason this was created was because you can’t “just delete the file.”

  24. Most of you don’t understand the technique at all; did you read the fine article or are you just reacting to the title?

    Just start steganographically archiving the keys (which are easily found with a spider) into pr0n images and post them to a newsgroup, where you can get them later from the group archive when you need ’em. Then anything you want to read that has expired keys, go retrieve ’em from your archive.

    Incidentally, the whole thing breaks every time somebody DDOS’s your trackers. It’s frail as well as easily defeated.

    Again, interesting work, but VERY FEW practical applications, all of which involve marketing. It’s TOO EASILY BROKEN to be used for the things you’d assume from the title.

    Here’s a better idea: One time pads written on high acid content paper. Pads degrade, you can’t read the messages anymore.

Comments are closed.