[brongondwana]

Apart from the "users lose their passwords all the fricking time" problem (seriously, before we implemented https://fastmail.blog/2017/12/06/security-account-recovery/, lost password was always in the top 3 most common support requests of the week report)

Impementing per-message-encryption would turn us into a dumb blob store. The whole point of FastMail is the value add - fast search, ability to deal with a lot of email quickly, etc.

That and people's devices are basically always on these days, and fetch new email immediately on a push when messages arrive. So if your provider get a subpoena or gets hacked, then a push request will make your device connect with the password, and boom - access granted.

Finally, we don't let people store master passwords on their devices any more, because they get leaked due to hacked devices, so we require people to create app passwords. This would be in direct opposition to many of the other safety things that are done.

(extra finally: phishing protections and antispam solutions are in pretty much direct opposition to the idea of the server not being able to see the content of emails)

[forapurpose]

Thanks; it's very helpful to know the ins and outs from a practitioner. I am confused by a couple of them:

> if your provider get a subpoena or gets hacked, then a push request will make your device connect with the password, and boom - access granted

If the message is decrypted only on my device, then that wouldn't matter. I'm guessing endpoint decryption is not what you (or maybe the GP) are talking about, but I don't know what you mean.

> we don't let people store master passwords on their devices any more, because they get leaked due to hacked devices, so we require people to create app passwords. This would be in direct opposition to many of the other safety things that are done

What is an "app password"? If it's just a password stored in an app (and then what is a non-app password? one in a text file?), why wouldn't it be as vulnerable to device hacking?

.....

Also, a couple of genuine questions about what's possible:

> Impementing per-message-encryption would turn us into a dumb blob store. The whole point of FastMail is the value add - fast search, ability to deal with a lot of email quickly, etc.

Email messages arrive in the clear, unavoidably; new messages are always vulnerable. Why not do the processing then - spam filtering, build a search index of hash values, etc.? Then permanently (from the server's perspective) encrypt the old, stored messages, and give endpoint/user the only means of decryption.

> users lose their passwords all the fricking time

> we don't let people store master passwords on their devices any more, because they get leaked due to hacked devices

How do the end-to-end secure messaging applications, such as Signal, handle those issues, if anyone knows?

[brongondwana]

> If the message is decrypted only on my device, then that wouldn't matter. I'm guessing endpoint decryption is not what you (or maybe the GP) are talking about, but I don't know what you mean.

Oh yeah, sure - if you only decrypt on your device, then that's reasonable. We could encrypt to a public key on delivery. There's services that do that, but FastMail isn't interested in being one of those services. The tradeoffs mean we could do very little. Certainly not a webmail service.

> what's an app password

https://www.fastmail.com/help/clients/apppassword.html

It's a password that's created by the server and used on only one app. So if you lose your device, you can disable that one password only. Also, there's no chance that you'll reuse it across sites, so it can't leak from other services because you won't be using it there.

It's also limited to just the protocols that are used on that device, so can't be used to reset your password or payment details or install forwarding rules, etc.

> Why not do the processing then - spam filtering, build a search index of hash values, etc.? Then permanently (from the server's perspective) encrypt the old, stored messages

If you can search for keywords and find maching message blobs, that's nearly as good as having plaintext access. If was encrypted to only the endpoint, the usual issues of "you need to download the entire database to search your email" apply, and of course we're doing very little.

> How do the end-to-end secure messaging applications, such as Signal, handle those issues, if anyone knows?

They're not designed to be your long term memory, which simplifies things a lot. You basically lose access to your history. Which might be find if you don't care about the past, but that's not how I see email. Email is your electronic memory, and encryption+lost password means that nobody can get at your memories, not even you!

[bachmeier]

> we require people to create app passwords

I like that, because it at least feels more secure to have a password that can only be used once, combined with the ability to go into the settings and shut off any device if it gets lost.

[brongondwana]

Yeah, it's by far the best of the options that use standard username/password authentication support. Basically make the password be another server-provided factor rather than user-chosen.