[e12e]

From the FAQ:

> Your private key is encrypted with your password and then stored on our servers in encrypted form so that only you have access to it. In this design your login password receives the status of the private key. Your password is salted and hashed on your device before being transmitted to Tutanota. With this method we guarantee an integrated confidentiality and we allow you to access and decrypt your emails from desktops and mobile devices instantly.

And:

> Your private and your public keys are generated locally within your browser upon registration. Your private key is encrypted with your password. This way your login password receives the status of the private key. The key is encrypted so strong that only you can use the key for encrypting and decrypting data. This is why a strong password is essential. An automatic password check on the client makes sure that you use a strong password. Your password is never transmitted to the server in plain text. It is salted and then hashed with bcrypt locally on your device so that neither the server nor we have access to your password. We can not reset your password. With this innovative design you can access your encrypted inbox from any device (desktop, mobile) easily.

I've not looked at their "automatic password check", but generally passwords such as "Password2014" are considered secure (Three character groups, long password...).

At any rate, if you host your own client, and one can turn off loading of images and other in-line resources -- this looks better than most "secure web mail" clients I've heard of.

But if you allow them to host the client, I don't see how they can't just change the js to log your password. And they only have to do it once, because they then have access to your private key (they store a copy, and only need your password for access).

[MatthiasPfau]

I am one of the founders, thanks for your discussion. We only load the app into your browser cache upon an update of which the app notifies you. However, we are very aware of the challenges that come along with making browser-based encryption secure. We are looking into ways how to easily verify that the JS executed in the browser matches the published open source code on Github. If you have any recommendations here, let us know!

[e12e]

As long as it is only a client-side app, why not refactor it so it can be hosted directly from github? What you're saying is that users can a) verify a release and host it themselves, b) trust you to serve up good code, c) trust the code you release on github. In b) they trust you're not complying with demands from a covert or overt agency, in c) they're trusting that you are not publishing subtly subverted code, or that github is complying with demands from a covert or overt agency (and in a) they're trusting that their host/colo isn't complying with demands from some agency.

In all a), b) and c) users are also trusting the transport layer, which in general means trusting the CA systems -- which of course means that the whole thing is moot -- the system is hopelessly insecure.

At least with a) you can host the client inside the firewall/security boundary -- and so a) can be as secure as any other solution.

It'd still be a lot more interesting if you at least published an API, so that other's could implement and run their own server (network) -- and not need to rely on a single company for access to their data.

[MatthiasPfau]

Thanks for your feedback! Hosting directly from github might be a good idea for the ones that regard github as a trusted third party. However, github would gain the possibility to manipulate the code to gain access to your accounts...

We plan to create an API and already started brainstorming on it: https://github.com/intermail/api/wiki

Regarding trusting the CA systems: We use DANE to secure your connection to our servers.