Hooray, Tutanota turned six today! 😀🎉 Check out how we improved your encrypted email client in the last years.
https://tutanota.com/blog/posts/encrypted-email
@Tutanota Your client has worsened things for the users. A few months ago we could use #ElectronMail to access both #Tutanota & #Protonmail accounts. Now you've done something to cause ElectronMail to drop Tutanota support, so that users are forced to maintain yet-another-single-purpose app just for Tutanota.
@Tutanota you say "At Tutanota we are a small team so we have to focus on how to develop the best product with miminum effort" -- so why not support this project: https://github.com/vladimiry/ElectronMail Effortless for you and better for the users. It's also easier for users to trust a tool that has 3rd party developers.
@resist1984 No, if we officially supported a third party client, we would have to audit each client for security, and this after every update. We prefer to focus our ressources on our own clients and make sure these are absolutely secure. Also you can verify the signature of our clients to make sure it's the same code as published on GitHub.
ok "absolutely secure" is the kind of phrase that shoots "nope!" levels through the roof
Thanks for that clarity, @Tutanota
@deejoe @Tutanota @resist1984 would wish not this "absolutely secure" talk. It doesn't exist and certainly not on your desktop..
But, eh off the cuff talk by unknown Tutanota employee.
if only that were the only problem
@Tutanota the difference between auditing two tools and auditing one tool is double the effort. Your effort could be focused on auditing rather than both auditing and coding a redundant tool, which is a waste of resources. Signature verification is always an option. If you audit #ElectronMail, you can sign it.
@Tutanota
Checking your own code is not an audit. An audit, by definition is conducted by third-parties. Users will decide who they trust to audit the client they use with your service, whether it's yours or a third-party one. If what you're doing is transparently secure, rather than depending on #SecurityByObscurity, surely it's based on common protocols, and standard crypto not #RollYourOwn, and has clearly documented specs that third-parties can follow securely.
@resist1984
@strypey I think this is pretty much touching the same issue companies like Slack had when staying away from allowing third-party clients: If you want to support a product or service end-to-end, third-party software that is not under your control gets into your way. Even more so if talking about an end-to-end security solution that is only as strong as its weakest component. Challenging problem... 😶
@Tutanota if your client were a compiled native client, you could at least say you've offered something that avoids #javascript. But your client is #electron-based, so the change from ElectronMail is strictly a loss for users.