Frequently Asked Questions
- How secure is this service?
- Why did I receive a link here with an option to decrypt a message?
- You delete everything submitted to this site?
- Why use this service?
- Is this a messaging service?
- What are the intended use cases?
- What should this service not be used for?
- Why not just use PGP/Signal/OMEMO/Matrix/etc.?
- What requirements exist?
- Can the recipient make a copy of the message?
- Is any personal information collected?
- What information is logged?
- What are you doing to secure the servers?
- What security risks are present when using this site?
- What are you doing about man-in-the-middle (MITM) attacks?
- What advantages do the browser extensions offer?
- How can I know for sure that anything submitted is encrypted end-to-end?
- How does end-to-end encryption work on this site?
- The decryption key can be in the URL?
- But the decryption key does not have to be in the URL?
- This service does not deliver the link to the recipient?
- How can I protect my privacy as much as possible while using this service?
- What if I do not trust the United States?
- What are you doing to prevent spam?
- Why is there an option to require the recipient to complete a CAPTCHA?
- Who is running this service and why is it free?
- How can I trust the answers to the above 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:
- While we are unable to read your message due to end-to-end encryption, the default link generated contains the decryption key; and therefore, anyone in possession of the link can read your message - including anyone able to intercept it.
- This service is just a tool to allow sending of less permanent communications (i.e. encrypted messages that are deleted upon retrieval) via traditional transports that are more permanent (i.e. email/text/instant-messaging/web-site/etc.). This means that any security/privacy issues inherent to the chosen transport (i.e. email) are inherited when you use this tool.
- There are other solutions available which offer better security depending on your needs and environment. The main advantage this service offers compared to others, is much lower requirements for the recipient (i.e. they just need a web browser and the ability to click a link).
- While the default setting is to delete messages upon retrieval, there is nothing to stop the recipient from making a copy. Keep in mind that this applies to all temporary message solutions - if the receiver can see the message, it can be copied.
- All Internet communications can compromise your privacy - you are trading some security for convenience.
- The web is a challenging environment when it comes to security due to some fundamental issues - this applies to all web-sites. However, being web-based does make verifying our claim that we cannot read your message much easier.
- This web site and its database are hosted in the United States. We utilize Cloudflare, a company based in the United States, as our content-delivery-network (all web traffic traverses this network).
- Using the service does not require any personal information (i.e. name/email/phone/etc.). There is no account system (i.e. login/password/etc.); therefore, any data breach cannot leak this information.
- All message content is end-to-end encrypted. In other words, the decryption key is never sent to us. Therefore, we, or anyone else in possession of the database, have no means to decrypt and view message content.
- Every entry in our database has a time-to-live ranging from 1 minute to 2 weeks (defaults to 1 week). Once this time has passed, the record is automatically deleted. Therefore, any information in our database will be deleted shortly after its creation.
- We only maintain the last 24 hours of web server logs. Any IP information stored in the database is securely hashed making it impossible to extract the original IP.
- All of the code powering this service is open source and available for review. You can easily see the code which runs the encryption - which is purposely short, concise, and commented.
-
A number of technical precautions are taken to help strengthen security - some of which include:
- This entire web site other than /api is static and does not support server-code in pages (i.e. PHP/JSP/ASP/etc.)
- The Web Crypto API, which is part of the browser, is used to encrypt all message content.
- TLS is used to encrypt communications between your browser and our servers. It helps ensure that code cannot be intercepted or modified in transit. TLS 1.3 is supported, but we also support TLS 1.2 for older devices. Older versions of TLS are disabled because they are not as secure.
- Certificate Transparency logs are monitored for certificate misissuance. Additionally we publish a Certification Authority Authorization (CAA) policy to reduce the risk of unintended or malicious certificate misissuance.
- We utilize HTTP Strict Transport Security (HSTS) to ensure that browsers always communicate with our servers using the TLS protocol. Additionally, we include our domains in the preload lists.
- A strict Content Security Policy is enforced to prevent Cross Site Scripting (XSS) attacks.
- By using a Cross-Origin Resource Policy, a Cross-Origin Embedder Policy, and a Cross-Origin Opener Policy, we forbid cross origin code in order to help mitigate against speculative side-channel attacks like Spectre and Meltdown. This also offers protection against potentially malicious requests from other origins by isolating the browsing context exclusively to same-origin documents.
- We employ a Permissions Policy to prevent the browser from loading resources which could compromise your privacy such as your location, web-cam, microphone, etc.
- DNSSEC is utilized on all of our domains to help mitigate DNS-based MITM attacks.
- We take a number of precautions to secure the server.
- No 3rd party code is loaded (i.e. jQuery) and very few resources are loaded (go ahead and open the Network tab in Dev Tools to check) - this minimizes the effort required to audit. The one exception is if a CAPTCHA is required - that loads 3rd party code from hCaptcha. However, the hCaptcha code loads on its own URL inside its own CSP rules and at no time has any access to anything having to do with a message.
- As a means to help safe-guard against MITM attacks, browser extensions are available.
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:
- It is likely that the message will be deleted immediately after it is sent to your device for decryption. This means that after you click the button to decrypt the message, we no longer have a copy to send you again later.
- We systematically delete all information received. Messages will be deleted anywhere between one minute to two weeks after it is created - regardless of if the message is ever decrypted. In other words, if you need to read the message, don't wait too long to decrypt it.
- The sender likely believes that the contents of the message should be handled with care. They may have even indicated that they want no copies made. Please respect their wishes.
- If you are prompted for a password to decrypt a message, do not close the browser window/tab. Per the first bullet point in this list, it is likely we cannot send another copy later. Just leave the browser window/tab open until you can enter the password. If you enter an incorrect password, you will be prompted again. The password must be entered in precisely. Keep in mind that in order to accommodate different languages and password requirements, we accept many different characters in passwords.
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:
- Encrypted messages for which we have no means to decrypt the contents
- Other information inherent in submitting anything on the web (i.e. your IP address, etc.)
- How long we should keep the message if nobody retrieves it (ranging from 1 minute to 2 weeks - defaults to 1 week).
- How many times the message is retrieved (ranging from 1 to 100 times - defaults to 1 time)
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:
- You have been communicating via a local web forum about mountain biking trails in the area and sometimes meet up with people on the forum to check out new trails together. Someone from the forum wants to pick you up at your place to carpool to a trail this weekend. You don't want your home address sitting in this web site forum database forever. Simply send the address via this service - the link is what resides in the web site forum database, but once its read by the recipient, the message/address is deleted.
- You need to send your brother your Netflix login because your niece is driving him crazy due to COVID lockdown and he still does not have his own account. You don't care too much about this login, but your brother is particularly bad at what I will just call "digital hygiene" and has had many trials with compromised logins and malware. Subsequent attempts to get him to clean up his act and even installing secure messaging for him have failed to stick. Simply sending it via a text message is probably the best option (sadly), but you are uncomfortable having that login sit in his message history due to past experience. Using this service to send the login via a link in a text message satisfies not letting the login hang out forever in his chat history.
- You sometimes work at an office that has many shared tenants who come and go at all hours. There is WiFi available for use, but the password is rotated every week since there have been problems with abuse. Many tenants email/text asking for the WiFi password even though it is at the front desk because most do not enter via the front main entrance. Using this service, the office manager can send the WiFi password via a link in an email/text reply satisfies not letting the password linger, and also allows the recipient to immediately copy the password via a copy button which is less clumsy on mobile devices.
- One of your hosting providers is asking you for details about a server which you have reported is showing signs of a hard drive that appears to be going bad. Some of the information they need is a bit sensitive - you don't want it sitting forever in the 3rd party ticket system they use. Using this service, you can send the information to the support technicians without having it reside in the ticket system. Since multiple technicians may need to refer to the information multiple times, set the reads-to-live greater than 1 (i.e. perhaps 20) so that the message is not deleted on the first retrieval.
- You need to private message another user on Reddit to let them know your phone number so that they can call you. Reddit, like many other providers, has leaked user information in the past and you don't want your phone number just sitting in Reddit's database for years until the next leak. Simply send your phone number via this service.
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:
- Do not use this service to make an inappropriate message transport "more secure". Because the default setting is to include the decryption key in the URL that can read the message, anyone with the link can read the message. As mentioned above, any security/privacy issues inherent to the chosen transport (i.e. a text) are inherited when you use this tool. So, for example, if you would never consider using email to send specific information due to its senstiive nature then you should not use this service to "secure" that part of the email.
- Do not use this service to ensure that no copy is made of the message. Just because we delete our copy of the encrypted message immediately upon retrieval and we make it more difficult to copy, does not mean the message cannot be copied. What if the recipient takes a photo of their screen? What if they just write the message down? Ultimately, if the recipient can read the message - a copy can be made.
- Do not use this service to ensure that a message cannot be traced back to you. This service is dependent on another message transport provider (i.e. email, chat, etc.) to get the message from one point to another. The message transport employed could very well trace the message back to you.
- Do not use this service to send anything you wish to deny sending. Just because the message itself is deleted, doesn't mean the link pointing to the deleted message is deleted. If you send an email to your friend and part of that email has a link to a message from this service, a casual reader will know there was something else in the message. Even if the message referred to by the link is long gone - it is clear that something else was sent and that it was sent by you to your friend.
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:
- The Copy button is removed. This button defaults to allowing the recipient to copy the entire message into their clipboard.
- The Download button is removed. This button defaults to allowing the recipient to download the message as a text file.
- The ability to select text inside the message text box is removed.
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:
- First, we store as little as possible for the least amount of time possible so that if the server is ever compromised, any information leak would not be damaging to our users. All messages stored in the database are encrypted with no means to decrypt them. There is nothing stored linking any message to any of our users since we do not gather any personal information from our users. All records in the database have an expiration time (TTL) ranging from 1 minute to 2 weeks - after this time has passed the record is deleted automatically. Therefore, the vast majority of information that has ever been in the database was already deleted a long time ago.
-
We take a number of measures to prevent compromise and contain any compromise that does occur:
- The web server, nginx, is run in an isolated container as an unprivileged user without write access to anything other than logs. The container runs within its own SELinux context further preventing any file system changes or easy escape from the container. There is no support for PHP/ASP/JSP/etc. - just serving static resources.
- The code running /api is written in Go which should make it fairly resilient to buffer overflow vulnerabilities (a common attack vector). The Go process also runs in an isolated container as an unpriveleged user without write access to anything other than the database. The container runs within its own SELinux context further preventing any file system changes or easy escape from the container. The database, badgerdb, is a part of the Go process (no external database dependency/process).
- The main danger of a server compromise is that the attacker could modify files in a way that would compromise the privacy/security of our users. A dedicated process monitors all web site files for any changes and alerts us immediately in the event there is any change.
- All administrative access is protected and limited to authorized networks.
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:
- Perhaps the biggest risk and the one most unique to this service is that our users will not use good judgement when discerning between what is appropriate to send and what is not appropriate to send. Sometimes the distinction between "I am comfortable emailing this information - I just wish the email would be deleted after reading" and "I am not comfortable emailing this information - email is an inappropriate transport" can be pretty subtle.
- There is always the threat that the operators of this site are actually bad actors luring people into using the service to obtain some dark end-goal. We come across a plausibly trustable - make everything easy and free - get lots of people using the service - all the while with sinister intent. Bwhahahahaha! How could you possibly trust us?
- There is the chance that our code has bugs that impact security or we just didn't think things through well and our shortcomings are now exposing our users to unecessary danger. We sure hope not - but we cannot rule it out.
- Unlike the tech-titans (i.e. Google/Facebook/Whatsapp) that have terabits of encrypted data constantly flowing in and out of their enormous networks, where it is easy to have private communications blend in with other traffic, standalone centralized services (i.e. Signal, Telegram, and us) stand out. Its easy for a network operator or even large organization/government to see that IP address x.x.x.x is using XYZ service.
- While not really specific to this site, since it can be used against any web site, man-in-the-middle (MITM) attacks are a valid concern.
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:
- HSTS is used to force browsers to only connect via TLS. Our server is configured to ignore non-TLS communication other than to redirect. Only TLS 1.2 or higher are supported.
- DNSSEC is used to sign our domain's zone. This could stop DNS spoofing implemented MITM attacks if the user is employing a DNSSEC aware recursive resolver.
- We use a service to monitor certificate authorities issuing any unauthorized TLS certificates referencing our domain.
- We have published browser extensions to support message encryption using code stored on the end-user's device.
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.
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:
- The end-user enters a text message and can specify several options, including a password.
- 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.
- An API call is made to obtain the number of required PBKDF2 + SHA-512 iterations (this step is required for spam control)
- A 32 byte salt is generated
- A key is derived from the salt and password
- A 12 byte initialization vector (IV) is generated
- The message is encrypted using the key and IV.
- The iteration count, salt, IV, and ciphertext are sent to the server (along with some other information such as TTL, RTL, etc.)
- The server returns a random ID referring to the message
- 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.
- The link is shared with a recipient.
- The recipient is prompted if they wish to decrypt and view the message.
- When the recipient chooses to view the message, the browser makes a request specifying the message ID.
- 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).
- The server sends the encrypted message and will by default delete the message at this point if the reads-to-live (RTL) is one.
- The recipient will decrypt the message and be prompted for a password if required.
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:
- Encrypt the password in a message with the default settings and send this link to the recipient.
- 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.
- 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.
- Using the password the recipient confirmed they possess, you can now send a message using the same password for encryption.
This service does not deliver the link to the recipient?
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 hate CAPTCHAs - they take time and are annoying
- Loading 3rd party javascript can be invasive to privacy and security
- Running our own CAPTCHA means we are signing up for a never ending game of whack-a-mole
- Eventually people might want to be able to interact with this service via the API
-
Increasing the number of required PBKDF2/SHA-512 iterations
All messages can only be retrieved a small number of times - an unattractive attribute for spammers since they rely on sending a lot of messages. Since a spammer would have to create a lot of messages for any given spam campaign - we have opted to make this task so computationally expensive as to make abusing this service for spam an unappealing endeavor. This is accomplished by keeping track of the networks posting messages - measured in terms of total possible retrievals. The network information itself is securely hashed so that we cannot infer the real network from the hash. As a given network posts more messages, we raise the number of PBKDF2/SHA-512 iterations required to post the next message. This very quickly results in a lot of CPU time being required just to post a single message. Hopefully this method will be adequate to curb spam abuse and at the same time, not affect real users. -
Gather spam reports from users when they retrieve a message
There is a "Report Spam" button right below the message when a user retrieves a message. If a message is spam, hopefully some will take the 3 seconds required to click that button. When we receive a spam report, it alerts us and it also factors into impacting the required PBKDF2/SHA-512 iterations for a given network.
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.