Frequently Asked Questions

How secure is this service?

We have taken many steps to make this service secure for its intended use. Before we go over those steps, its important to understand the following:

Our goal is to offer this service in a manner that offers options to enhance your privacy and security. Here are some steps we have taken to safe-guard your information:

Why did I receive a link here with an option to decrypt a message?

This service simply passes an encrypted message from one point to another and you are the recipient. The message will soon be deleted. The operators of this service have no way to read the message contents. Usually someone uses this service when they do not want the contents of a message to remain inside various databases/devices/services/files/etc. as is typical when sending an email/instant-message/text/etc. Should you decide to decrypt, please keep the following in mind:

You delete everything submitted to this site?

True to our trash can logo... everything gets deleted shortly after receiving it. Deletion of everything is automated - its written into the server. Think of it this way - there are two classes of information submitted:

In the case of messages, you can control when we delete them by specifying: By default, everything about a message is deleted after it is retrieved once or is 1 week old - whichever happens first. When it comes to deleting all the other information inherent in submitting anything on the web (i.e. your IP address, etc.), we do not give you any control over when or how it is deleted - we just delete all of it every 24 hours.

Why use this service?

This service is a tool to help make messages you send/receive less permanent. Most of what you communicate on the Internet (chats, texts, emails, etc.) is stored and rarely deleted. Oftentimes, when you do delete something, it's not actually deleted but rather marked as deleted and no longer displayed to you. Your aggregate communications accumulate year after year in databases and on devices you have no control over. Inevitably, one or more of the organizations/people/devices storing your communications is hacked and your information is leaked. This problem is so pervasive that there are now many web sites which track the organizations that have been compromised and leaked user data. End-to-end encrypted temporary messages are a simple solution to help make some of your communications less permanent. Every message submitted to this site has a time-to-live ranging from 1 minute to 2 weeks - once that time has passed the message is deleted. Furthermore, the default setting is to delete any message once the recipient has retrieved it. Additionally, all messages are encrypted from your device all the way to the recipient's device. The main goal in utilizing end-to-end encryption is to remove our ability to read any submitted messages thereby removing some of the trust requirement. The end result is that it is now easy to send an encrypted message via a simple link. That message is deleted either shortly after sending or upon retrieval. You don't need to install/configure special software. You don't have to create an account or provide any personal information. The recipient does not have to be in your contacts or even know about this service - the only requirement that they can click a link.

Is this a messaging service?

No. This service is designed to complement existing messaging services like instant-messaging/email/text/etc. by adding the ability to prevent sent messages from being stored for a long time. We do not deliver the generated link to the recipient.

What are the intended use cases?

So what are some scenarios where it is appropriate to use this service? While everybody has different needs and requirements when it comes to their privacy and security, I personally have found the following scenarios as appropriate use cases:

What should this service not be used for?

This service should not be used for very sensitive information for all the reasons explained in this FAQ. Below are some examples of what not to do:

Why not just use PGP/Signal/OMEMO/Matrix/etc.?

If you know the person you want to send secure temporary messages, send them often, expect a chat-like interface, and/or can expect the recipient to have the required software and know how to use it, this web site is probably not the best solution. There are great options out there that are open source, support E2EE, not web-based, and even some like Signal that also support temporary messages. I personally use a private XMMP server and OMEMO to chat with close friends and family. Using this site may only be optimal if you don't know what software the recipient is running, don't know their phone-number/contact-handle, don't know their technical proficiency (but assume they can click a link), or you just prefer to keep the message you send outside of the underlying communication transport.

What requirements exist?

A modern and up-to-date web browser that properly implements standards including the Web Crypto API is required. Examples include: Chrome, Firefox, Edge, and Safari (circa 2020 or after).

Can the recipient make a copy of the message?

Yes. Even though the message may delete itself upon retrieval, the recipient can still view the message. Anytime the receiver can completely view the message, a copy can be made - this applies to all communications. There is an option to make it more difficult for the recipient to make a copy. In this case three impediments to copying are implemented:

However, these copy protections are weak because they can be bypassed. Also, the recipient can always just take a screenshot or a photo of the message.

Is any personal information collected?

We don't support user accounts (i.e. username/password). We don't gather any information that can identify you (i.e. name/address/email/phone). It's possible that some personal information could be in the message you are sending, but that is encrypted and we have no way of reading it. Please review our privacy policy for complete details.

What information is logged?

Our web server keeps up to 24 hours of common log format on all web activity. This includes logging the full IP address of HTTP clients. After 24 hours, this logged information is deleted automatically. All requests sent to /api are POSTed meaning that no message specific information is ever logged by the web server. Additionally, any information saved to the database is effectively logged. All entries in the database, including anonymized and hashed IP addresses, have an expiration time (TTL) after which they are automatically deleted. The TTL expiration times vary between 1 minute and 2 weeks.

What are you doing to secure the servers?

Server security is an obvious concern. There are two main areas we focus on to keep it secure:

What security risks are present when using this site?

Before specifically addressing some of these risks, I think a semi-brief analogy might help to summarize the risks in using any Internet communications. Visualize that any system is only as secure as the weakest link in a chain. Now imagine a scenario where there are two people in a sealed room with no means to see, hear, or record anything they do. One will pass a message to the other whom upon reading the message will burn it. If someone outside that room wishes to obtain the message which was already passed, that is going to be tough. What is the weakest link to obtain the message? There are not that many links to choose from - its a pretty short chain. Now imagine that when you send a message on the Internet that there are at least a million links in the chain - many of them weak - many of them completely outside your control - and that is reality.

Using encryption can greatly help with the above million link problem and its easy to get lured into thinking that well designed E2EE systems offer the end-all solution. However, that thinking can get you in trouble, because an attacker will usually just go after the weaker links in the system. For example, its probably far easier to take over your phone or computer and setup an input logger to just read everything you type than cracking encrypted messages over the wire. The bottom line is that if I was tasked with communicating a secret of vital/critical importance, I would only use electronic communications as a method of last resort.

So there are security risks using any communications, but you still use a web browser for banking, buying things, email, etc. It's an accepted risk for the huge conveniences gained. Really the question is... what security risks are semi-specific to this site? A few come to mind:

What are you doing about man-in-the-middle (MITM) attacks?

All users of web sites can potentially be the victim of a MITM attack - this site is no different than all the others on the web in this regard. A MITM attack is when an attacker is able to intercept and modify communications between the user's browser and the site's web server. This allows the attacker to modify any of the site's code/content while still appearing to the end-user to be the site that they are used to. We take some measures to make a MITM attack more difficult:

However, a MITM attack is still always possible - especially if the attacker controls network/public-key infrastructure as would be the case for large/powerful organizations or governments. We offer browser extensions which can help mitigate some MITM risks.

What advantages do the browser extensions offer?

We offer browser extensions as a means to provide extra convenience and additional security. Simply put... The extensions make sending temporary messages faster and easier. Some security is also gained because all code used to encrypt and prepare a message is stored locally within the extension. Because the code is stored locally, this offers the sender some protection against MITM attacks. However, it is worth pointing out that while the extensions offer more protection against a MITM attack that compromises the message contents, a MITM attack could still be effective (i.e. to determine the sender's IP address if not using TOR/VPN/etc.).

How can I know for sure that anything submitted is encrypted end-to-end?

Unlike many other popular end-to-end encrypted (E2EE) chat clients, its fairly simple to see exactly what is sent to us when you submit a message. The below video tutorial demonstrates how to confirm that we have no way to decrypt messages sent to the server.

Also, if you think about it, as long as we are not some secret agency trying to collect sensitive messages, there is no benefit to us being able to decrypt messages since having that ability only creates problems for us. We don't even want to store messages - its a necessary evil to deliver them however.

How does end-to-end encryption work on this site?

At this time, we are utilizing symmetric encryption (AES-GCM 256bit) with keys derived from passwords (minimum of 200,000 iterations of PBKDF2 + SHA-512). Asymmetric encryption is not used because requirements exist for 1) sender initiating the communication 2) sender and recipient not being online at the same time and 3) no information on the recipient and 4) we are trying to keep things real simple and key management is complicated. The standard Web Crypto API is used for all cryptographic functionality including RNG. Basically, here is what happens:

  1. The end-user enters a text message and can specify several options, including a password.
  2. A secure password is generated for purposes of deriving a key. If the user has specified a password, it is combined with the generated password.
  3. An API call is made to obtain the number of required PBKDF2 + SHA-512 iterations (this step is required for spam control)
  4. A 32 byte salt is generated
  5. A key is derived from the salt and password
  6. A 12 byte initialization vector (IV) is generated
  7. The message is encrypted using the key and IV.
  8. The iteration count, salt, IV, and ciphertext are sent to the server (along with some other information such as TTL, RTL, etc.)
  9. The server returns a random ID referring to the message
  10. The browser then presents the end-user with a link which can then be shared with a recipient. All information about the message is kept in the hash component of the URL and therefore is not sent to the server during a standard GET request.
  11. The link is shared with a recipient.
  12. The recipient is prompted if they wish to decrypt and view the message.
  13. When the recipient chooses to view the message, the browser makes a request specifying the message ID.
  14. If the sender requires a CAPTCHA be completed, the recipient is directed to another URL to prove they are human (once they pass they are directed back).
  15. The server sends the encrypted message and will by default delete the message at this point if the reads-to-live (RTL) is one.
  16. The recipient will decrypt the message and be prompted for a password if required.
This setup is extremely simple, and offers message encryption from the sender's device to recipient's device, but of course lacks some of the guarantees that asymmetric encryption can offer. Anyone with the link can open the message in the default scenario - this underscores the importance of using an appropriate transport for the link (i.e. email/chat/text/etc.) - a decision left to the sender.

The decryption key can be in the URL?

Yes. If a password is not used, anyone with the link can read the message. This obviously impacts security because if the method used to send the link can be intercepted, then the message can be intercepted. All workarounds to eliminate this issue introduce additional steps and complexities which impact user experience (i.e. things have to be setup on both ends prior sending the message). Ultimately, if two parties are going to be sending messages to each other frequently, better solutions exist assuming both parties can handle using those solutions.

But the decryption key does not have to be in the URL?

Correct. The message author can specify a password to protect the message. This password is used to derive a secret key that is not part of the URL. If a secure password is used and is securely communicated to the recipient (or they already know it), this provides protection against intercept. However, the disadvantage is that the recipient must know and correctly enter the password. Here is one way to send the password to the recipient which offers some protection against interception:

  1. Encrypt the password in a message with the default settings and send this link to the recipient.
  2. When the recipient clicks the link and decrypts the message, they know nobody else has obtained the password before them because the message containing the password is deleted upon retrieval. However, if there is an active MITM attack or if your device or the recipient's device has been compromised, then it's still possible another party can obtain the password.
  3. Confirm with the recipient that they have successfully obtained the password. For example, if the recipient informs you that when they went to retrieve the password that the message had already been deleted, then you know someone else obtained the password before the recipient and that the password is therefore compromised and should not be used.
  4. Using the password the recipient confirmed they possess, you can now send a message using the same password for encryption.

That is correct - we generate the link and leave it to the sender how best to deliver it to the recipient. The goal of this service is to provide an option offering less permanence in existing message transports like email/chat/text/etc. Therefore, the expectation is that the link we generate which points to the temporary message is sent via an existing message transport. This does have security implications that users should understand. Let's take an SMS text message as an example since this is a pretty insecure method of communication. When you use this service to send a temporary message, with default settings, anyone with the link can read the message and no protection against interception is offered. This service still provides a more temporary communication which can enhance privacy and security. Additionally, a password may be used to provide protection against intercept.

How can I protect my privacy as much as possible while using this service?

As discussed elsewhere in this FAQ, even though we already do a lot to protect your privacy and even though we do not collect any personal information, some log related information is submitted and collected by us and others by virtue of you using a web browser.  However, there are multiple ways to protect your privacy even more.  One way which is free to use, based on open source software, and works quite well is to use the Tor Browser.  This browser is designed to protect your privacy on multiple levels - including using the Tor network.  Our site is already accessible via the Tor onion network which means accessing our site via Tor does not require the use of an exit node, which negates someone eavesdropping on exit node traffic.  However, keep in mind that even in this scenario, your ISP can see that you are using Tor - though not what for.  You can even connect to a VPN and then launch the Tor Browser for two layers of anonymity; however, keep in mind that your ISP can still see you are using a VPN in this scenario - though not what for.  If you do not want your ISP knowing what protocols your are using, you can connect to a large public WiFi network such as a library, school, etc. and then use the Tor browser.

What if I do not trust the United States?

Our servers are located in the United States.  Additionally, our CDN provider, Cloudflare, is a company based in the United States.  We have tried to remove the need to trust us or the country in which our servers reside simply because we do not collect personal information, cannot decrypt any messages, and everything is deleted shortly after it is received.  However, we can understand some mistrust since it is web-based and especially if you live in certain countries.  We have some plans to offer options in Iceland and Switzerland for people who have a hard time trusting the US.  Please let us know if this applies to you, since we will not be motivated to offer alternatives unless there is real demand.

What are you doing to prevent spam?

Anytime you allow someone to post a message that can relayed via a link, you invite spammers. Curbing this problem is not completely straightforward. We do not want to load a 3rd party CAPTCHA as part of the message sending process for a few reasons:

We could possibly get around the API problem via using some API key system, but then we have to gather user information which we don't want to do. Also, what is to stop spammers from getting lots of API keys? We cannot examine messages to infer their spaminess (which is very problematic at best) since, other than encrypting the messages, we have a hands-off policy on message content. Given these requirements, we employ two methods for preventing spam: If you are aware that spammers are abusing this service, please file an abuse report.

Why is there an option to require the recipient to complete a CAPTCHA?

While it is true that we dislike CAPTCHAs, we do recognize that they serve a purpose and have a time and place (at least for now). This is a simple way for the sender to gain some assurance that the recipient is human and that automated processes are not accessing the message.

Who is running this service and why is it free?

We are just a couple guys who were sometimes faced with the predicament of not having good options to help protect our privacy. Oftentimes this resulted from communicating with friends and family members who not very careful with how they handled their devices and information. Othertimes this came about when using web-based forums like Reddit or using web-based support systems. We found some web-based temporary message solutions, but none offered E2EE which meant we could not trust them. So we just built our own solution and decided to give it away so others can benefit from it.

How can I trust the answers to the above questions?

Really you should not trust any web site just because it says certain things - its typically a good idea to verify any claims. We have tried to remove the requirement to trust us as much as possible via employing end-to-end encryption. For example, its pretty easy to audit that we cannot read any messages since they are encrypted. We also have kept the javascript code running this site very simple so that its easy to read and understand. Making all the code open source allows people to verify what's running; however, keep in mind there is no way to truly verify what the server is running. While it is true that much of the trust requirement is removed with end-to-end encryption, it is still a factor that our users much weigh when deciding to use this service or not.