
Tutonota: An end-to-end encrypted email client and hosted service - livatlantis
https://github.com/tutao/tutanota
======
DavideNL
Beware, does not support local (encrypted) backups.

If their servers disappear for whatever reason (legal issues or hardware
problems), you end up with 0 e-mails. Nothing.

------
Flimm
> Tutanota is the end-to-end encrypted mail client that enables you to
> communicate securely with anyone.

Is this promising end-to-end encryption over email even if one of the two
parties is not using Tutanota?

~~~
mr_sturd
If you send an email to someone without Tutanota. They email the recipient
with a link to their server. Allowing the recipient to decrypt the email in
the browser, using a password agreed on, by the communicating parties.[0]

[0]-[https://tutanota.uservoice.com/knowledgebase/articles/470795...](https://tutanota.uservoice.com/knowledgebase/articles/470795-how-
do-i-send-an-encrypted-email-to-an-external-re)

~~~
skrowl
If I'm going to go the route of sharing a password, why wouldn't I just put a
.txt or .html file with my email body in a password-protected/encrypted .7z or
.zip and just send it with plain old gmail? My buddy doesn't have to change
his email provider or click on any special links.

In addition to not having forward secrecy (if a 3rd party gets his crypto
password, they get ALL of my messages to him), this seems to fail the classic
"In order to exchange a secret, first exchange a secret" crypto usability
test.

------
g4k
It seems this is browser only. Would be great to have Thunderbird integration.

~~~
troublord
Please vote for the following feature request:
[https://tutanota.uservoice.com/forums/237921-general/suggest...](https://tutanota.uservoice.com/forums/237921-general/suggestions/7013569-creating-
an-add-on-for-an-open-source-mail-client)

------
mirimir
They nuke accounts created using Tor. That's not very privacy friendly.

~~~
troublord
That is simply not true. We have a very high degree of Tor users.
Unfortunately, some spammers also hide behind Tor. That is why we disable
accounts that are used for spamming purposes.

You can always contact our support if you feel that your account has been
disabled without reason. We check every case... :)

\-- Matthias Founder tutanota.com

~~~
mirimir
Thanks. That's good to hear :)

But I've had it happen more than once, without warning, and without any mail
sent.

Also, contacting support isn't really a viable option, for new personas with
no other email address.

~~~
troublord
That is true for users without an email address. Don't mind to share your
ideas for improving this at
[https://tutanota.uservoice.com/](https://tutanota.uservoice.com/).

We will change this, if there is a better way that provides protection against
spammers...

~~~
mirimir
Thank you.

But is spamming through Tor really such a huge problem? I vaguely recall the
argument that there wasn't enough bandwidth. And maybe there is now, with
faster relays.

~~~
troublord
Unfortunately yes. A single user is not a problem. But if hundreds of users
abuse TOR for spamming via Tutanota, this becomes a serious issue. At least
for the spam recipients and other users of our service, that might get
classified as spammers by the receiving mail servers.

~~~
mirimir
OK, I get that.

But it still seems like overkill to nuke new accounts that you consider
suspicious, before they've even been used. Someone who's seeking anonymity
can't really share anything with you that would distinguish them from
spammers. The only thing will be whether they spam, or not.

------
Already__Taken
What extra do the encrypted messaging services offer on top of say, forcing a
regular mail server to only user tls1.2. Must we all move onto a single
provider?

I'm just curious why that's not good enough where sysadmins collectively
pester whoever they require secure communication with to also have a tls1.2
mailserver. Would that not be job done?

~~~
stephenr
Forcing TLS for the MTA at each end is about network encryption (i.e. akin to
HTTPS) this "solution" is about encrypting the contents of the message
envelope, i.e. restricting who can read the contents of the message regardless
of how its transferred.

As I mentioned elsewhere, it is however yet another non-solution, for the same
reason you queried - it's all reliant on a single provider.

Real end-to-end encrypted email is when your mail client uses either S/MIME or
PGP/GPG to encrypt your message using the recipient's public key(s). In that
situation, it doesn't matter what mail service they use, or what network
transport the MTA's use - it's readable only by them (well technically only by
anyone with the appropriate private key - I'm going to assume people are
protecting their keys).

------
stephenr
So yet another "end to end encrypted" email "solution", where both ends are
controlled by a single vendor.

There are already two, count them, TWO, existing, open, well-understood ways
to both sign and encrypt email between two parties: PGP, and S/MIME.

Currently, the UX around setting up and using each of these tools is.. less
than stellar.

Now. Just go with me here. What if all the people who keep claiming to have
"solved the encryption problem" by locking everyone into their own little
silo, instead of doing that, WORKED ON SOLVING THE USABILITY PROBLEMS?

~~~
vox_mollis
PGP is entirely useless if you wish to hide metadata about origin,
destination, precise timestamps, etc.

Use cases exist in which you need to communicate securely and authenticated,
but can NOT leak the above.

Some combination of Pond( message inboxes, timestamp randomization ) and
Ricochet( authentication, origin/destination obfuscation ) is sorely needed.

~~~
stephenr
> if you wish to hide metadata about origin, destination, precise timestamps

Sounds like email in general is not the transmission medium you want then.

~~~
wccrawford
But by that same token, it doesn't appear that this is actually "email"
either. It's sending messages via the internet, securely, using a custom
client. If you send to someone without their client, they end up with a link
(via actual email) to the website and have to use a password to view it.

I think we're at a point where any long messages sent via the internet are
going to be called "email" regardless of the actual transmission process.
Especially if they aren't meant to be some kind of real-time chat system, as
that is usually called "instant messaging".

~~~
stephenr
First off: _they_ called it email, not me.

> Tutanota is the end-to-end encrypted mail client that enables you to
> communicate securely with anyone.

Secondly: no. Twitter dm's are unlimited in length, and no one calls it email.
Web based conversational systems offer long form messages, and people don't
call them email.

Email is email, other things are other things. Something can be "email like"
and not be email, and if explained that way even the most novice of users can
understand that there is a difference, even if they themselves don't
specifically understand what the difference is.

------
muloka
Curious why they went with Cordova instead of React Native for their mobile
apps.

Are there security considerations between each solution that they took into
account when deciding?

------
steaminghacker
how does this compare to protonmail ?

~~~
stephenr
In that it claims to be 'end to end' encryption, but that both 'ends' are from
the same vendor, it's exactly the same.

So if you use protonmail and your colleague uses this, and you want to have a
secure conversation over email, you're each going to be clicking clicking a
fuck load of "view this message on <service you don't use>" links.

~~~
mookerific
At least ProtonMail is working towards full compatibility with the OpenPGP
standard, thereby allowing non-Protonmail users to encrypt emails using a
standard PGP key - according to their stated roadmap, ProtonMail will
eventually allow you to export your keypair and will also allow you to upload
keys you've generated outside of their service instead of relying on their
service to do the key generation.

Tutanota has implemented their own variation of encryption which is not
OpenPGP compliant. Their justification for this deviation rests on their
desire to be able to encrypt all aspects of communications (metadata, subject,
etc) while PGP doesn't not offer this.

