We use only strong cryptographic algorithms (e.g. AES), randomly generated keys and the Stanford JavaScript Crypto Library (link). There is no way to break the crypto itself and decipher your message.
When the site works as designed, you don't have to trust us. The cryptography is sound, albeit one might argue that the entropy is less than ideal. The problem is: unlike a cryptographic program on your own computer, our website might suddenly start shipping broken crypto without you realising it. That may be because we turned evil, or a hacker (or state sponsored agency) broke into our server. The problem is: you and your intended recipient would have to verify all JavaScript code of this site every time you use it. In practice, this is impossible.
The problem is: even if someone audited all the code, there is nothing from keeping us (or a hacker) to change the site after the audit. There is no guarantee that the encryption code is ok, unless you (and your recipient) check it every time. As already said, this is so impractical as to be impossible.
Not if we use the crypto as advertised, then no. But we (or a hacker) could deceive you and serve you broken JavaScript and then read your message. You have to trust us that we don't turn evil and that we try to keep hackers and others off the site.
This site was built out of necessity. Too many people we deal with sent us passwords and other credentials unencrypted. We wanted an easy way to secure the transmission. We have no interest in knowing your message: if government comes knocking on our door, we can give them the database with all information, without anyone (neither us nor the government) being able to decrypt the stored messages. Furthermore, we delete all messages after they have been viewed for the first time. So actually, the encryption protects us as well as you. As we don't know anything about you or your message, we cannot be liable for anything. This is our motivation for not reading your message: we want to stay out of trouble.
If you find our motivation lacking, then do the only sensible thing: get yourself a real cryptographic program, like e.g. GPG or Enigmail or S/MIME email certificates. Then you don't need to trust anyone. If this FAQ encourages you to encrypt your email, we are very happy. Good for you! Good for everyone! Start encrypting your emails.
Yes. Although we made this site as secure as possible, you really should start encrypting your emails. Until then, e.g. because you have partners who can't be bothered to switch to encrypted emails, you can use this site. Just do us a favour and don't use it to transfer launch codes for nuclear missiles ;-)
The CLI client (transfer_pw.py) is more secure during sending, but not during retrieving messages (which is still done through our website). Security during sending is marginally better, as you can verify the client code once and then run it on your computer without fearing that it has changed since your last check. But as retrieving messages is done through the website, all problems described above still apply.
We don't. This is a non-profit project.
Send an email to info at transfer . pw [GPG key, 171895E14AD4B9BEA79ADC7544DF906F1DE9E22E]