Open-sourcing Tutanota: Why it was important to us

> clunky

Just curious. Are you referring to the classic interface, or our super slick Ajax interface?

I have tried it out. As a user, it seemed ok, and it is free (pricewise).

Mailpile does not host mail, it is just the front end - you still need an email account elsewhere.

I use runbox.com as my main email provider - not free (pricewise), but is doesn't cost much.

Ok - I initially misunderstood that you were saying FastMail does the same thing as Tutanota. When I reread your comment I see that you aren't saying that - just that you secure transit with TLS, etc.

Do one thing and do it well... I like how simple the interface is and how trivial it is to toggle between sending encrypted emails and non-encrypted.

Great move opensourcing this. I respect the devs stated ethos and reasons for doing this. Hopefully this project will benefit from 'Linus' Law' and will get help to address the sec issues noted in the full disclosure.

I would like to be able to integrate this with something like keybase - but where i hold the private key (which you can do with keybase but it is not the default).

An interesting project and seemingly moving in the right direction.

Highly secure messaging, email, and Internet services has a long history in military and defense sector with issues well-understood. I mention here [1] the framework I used in high assurance security engineering. The system must be built using strongest engineering techniques with the right requirements. It must run on an endpoint with specialist security engineering techniques resistant to talented hackers. The protocols, parsers, networking stacks, and so on must be carefully implemented to prevent problems. Modern attackers are hitting various firmware, too, so protection is needed from devices. Then, we must be sure the software displayed to us for all this is what's actually running, on non-subverted hardware, and with non-malicious insiders.

The whole thing is beyond tricky to the point that no hosted service is rated to high security in any honest way (eg outside hand-waiving arguments). The only proven model has standalone apps (eg PGP, Nexor Sentinel) acting as proxies between trusted mail/messaging apps and untrusted side. Ideally, user-controlled, vetted code handles secrets with untrusted side (eg Internet host) simply a transport or storage layer that has no influence on endpoint or security past availability. The trusted software must also run on strong endpoints that don't run any other risky software. Given target market, that disqualifies most users of email and messaging software in general.

So, about this one. It seems to not meet many of these requirements and its users don't either. That puts it in Low-Medium assurance category where it might still be helpful against regular black hats, snoops, and attackers without 0-days in what their users have. That will necessarily require decent design & implementation. I commend them on having it pen-tested & open-sourced for review to that effect.

Meanwhile, users wanting to increase resistance to High Strength Attackers should use air gapped, hardened NIX boxes with GPG or Markus Ottela's Tinfoil Chat. Snowden leaks showed using GPG correctly, esp with Tor correctly, gave NSA hell. Markus has also improved TFC many times in response to our critiques to the point that many attack vectors are impossible, risk is lower in others, and endpoint risks are possibly lower than all solutions if right hardware is used. Still work to be done but he's way ahead of the competition.

Note: I second rossjudson that the site, although with beautiful artwork, should be redesigned so it's clear what the app does without a lot of digging. I've seen competing apps where they were clear on the specifics upfront while still not drowning readers in technical detail. The technical detail was a link or so away if I needed it. Right not, it looks too much like a marketing team's work.

[1] https://www.schneier.com/blog/archives/2013/01/essay_on_fbi-...