[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.