thoughts regarding autoencrypt?

To me the problem with E2EE is that I can't be sure the other end is protected well enough. If it is a node administered by someone who understands FOSS and security, then he might be able to protect a primary key (or other type of secret). Otherwise it is definitely a false sense of security and unnecessary burden.

In any case the best protection is to be mindful of what you share and who you share it with. The level of protection is really the time and effort an expert would need to exercise to break it and usually it is not encryption that is being attacked.

The only problem I see is the false security aspect. If you wanted couldn't you encrypt an email or message prior to inputting it into the client using autocrypt and have 2 layers of encryption?

A layman might however see that it is encrypted by autocrypt and assume their message is hidden from authorities/family/ whatever OPSEC threat level and thus be fooled by a false sense of security.

I do not think it is bad that it exists because, the alternative would be no encryption. The vast majority of people do not encrypt their mails and therefore are vulnerable already.

> The only problem I see is the false security aspect. If you wanted couldn't you encrypt an email or message prior to inputting it into the client using autocrypt and have 2 layers of encryption?

I should have summarized more specifically what Autocrypt compromises on. The method of encryption (which is just standard PGP) is not the problem. The issue is one of trust and key management. If I have a copy of your public key, I can send you a message which can only be read by someone with access to the corresponding private key. If you have a copy of my public key, you can verify that the message was sent by someone with access to the corresponding private key. However, this relies on a couple of assumptions:

The first assumption is that the copies we have of each other's public keys are correct. If you trust the wrong public key, and imposter can send you a message which appears to be from me. If I trust the wrong public key, then my message will be encrypted for an imposter to read instead of you. One way to be certain that were are trusting the correct public keys would be to exchange keys in person. We could also exchange keys over another secure medium, but then we are back to where we started because we would need a way to establish trust for *that* medium. There is also something called the web of trust, whereby if you trust someone's public key, you can sign it, and if they trust someone else's public key, they can sign it, and so on, creating a chain of trusted keys. If you are certain of the first key in the chain, you still can't be 100% certain of the other keys, but you can have more confidence in those keys than if no one was vouching for them.

The second assumption is that we and only we have access to our own private keys. In order to make this assumption, we need to keep our private keys very safe without losing them. You should not store your private key online, but this means that you need to be responsible for making physical backups in case you ever lose your key. You also should have a strong password for your key, in case it ever does get stolen. Strong passwords are generally harder to remember than weak passwords, so this increases the likelihood that you will forget or password or write it down on a piece of paper that can be stolen. If you use multiple devices, you will need to securely copy your private key to all of these devices, further increasing the complexity and inconvenience of key management. There are other pitfalls as well. See [1].

If all of this seems very complicated and easy to screw up, that's because it is. As zigote points out, in order to have confidence in this approach you have to not only know what you're doing, but also be reasonably certain the the person you are communicating with knows what they're doing. Most people don't know what they are doing and lack the time and/or willingness to learn, which is a problem for adoption, and without adoption encryption cannot become the norm. No matter how well you understand encryption and manage your keys, if everyone you need to communicate with does not use encryption, you need to send your emails in clear text anyway.

What Autocrypt does is basically forgo verifying the first assumption in order to simplify key management, making it easier to trust the second assumption. Autocrypt uses a different key for each device, eliminating the need to copy your private key between devices. It also automatically trusts other people's public keys, rather than burden the user with the non-trivial task of determining whether a key is correct. The result is a simpler and more seamless user experience that an average user could probably handle, but at the cost of any sort of protection against man-in-the-middle attacks. MITM attacks are just as much of a risk with clear text email, so autocrypt is a technical improvement over clear text email. However, suppose someone assumes that clear text email is insecure and avoids sending sensitive information over email, and then begins using autocrypt and, assuming that autocrypt is secure, begins sending sensitive information which they would not send otherwise. Although they were just as susceptible to MITM attacks before, now the potential consequences of a MITM attack are greater, so they may actually be less safe than they were before.

[1] https://riseup.net/ru/security/message-security/openpgp/gpg-best-practices