I've seen this before, but I don't remember if they just allow this headers and you have to use client which supports it or they do this in web too?
I have a technical question about Autocrypt Support here. What is the point of this feature, if Tutanota messages are already encrypted end to end by default? Isn't that more of a concept to secure unencrypted email providers & emails?
Seems to be related to #527 as well.
@4jNsY6fCVqZv this is for encryption to other email providers
@charlag I don't quite understand what this is for. Tutanota to Tutanota is encrypted by default end to end. And for an email exchange with other providers, you have the solution with the extra web interface and the shared password, which also allows an end-to-end encryption, right?
@4jNsY6fCVqZv yeah but that's really more like duct tape rather than a real encryption feature, it's nowhere close to efficient or user friendly... (though it's better than nothing and therefore good to have in the meantime)
Yet another reason for implementing this feature - compatibility with Delta Chat, which is a very popular privacy-focused IM.
https://delta.chat/en/help#is-delta-chat-compatible-with-protonmail--tutanota--criptext
@charlag Why do you want to go for Autocrypt at all, which to my knowledge neither has a trust model nor allows one via protocol?
It's not about relying on Autocrypt, it's about supporting it. Communicating via autocrypt is better than communicating unencrypted, and sometimes those are your only two options.
From a technical point of view, I have some concerns as to whether it makes sense to support a solution that users want and should trust, but which may not be able to fully meet this requirement from a technical point of view.
Also I am critical if only Autocrypt is supported, but this does not seem to be planned for p=p so far. Both standards are not compatible to my knowledge. However, both pursue a very similar intention: To make encryption finally usable for many many people out there.
Tutanota users could then expect end-to-end encrypted messages from only some of their contacts. Although other contacts might be safely reachable via the p=p standard.
Maybe you developers can balance this by supporting both standards out of the box?
EDIT Oh, looks like there's already an issue for p=p integration. https://github.com/tutao/tutanota/issues/812
Hello Tutanota,
You have admitted in a Reddit Post that we are free to start working on the implementation of Autocrypt.
(https://www.reddit.com/r/tutanota/comments/g1jvko/will_tutanota_use_openpgpjs_in_their_forthcoming/)
What directories in Tutanota's source code does Tutanota recommend contributors to review and edit as they attempt to contribute to Autocrypt?
Hi @fosres,
Thanks for offering to help. We had a discussion about this and we decided that it doesn't really make sense to start working on Autocrypt support before our post-quantum mail changes roll out, since this will change the way we handle encryption a lot!
So sorry for misleading you on reddit and thanks again :-)
Ok, thanks for letting me know. Let me know when Tutanota is ready to start developing it.
I will try to work on issue #590 in the meantime. I will comment my questions on development there.
Most helpful comment
It's not about relying on Autocrypt, it's about supporting it. Communicating via autocrypt is better than communicating unencrypted, and sometimes those are your only two options.