4 ms·

This comment is kind of baffling to me. I agree that first party end to end encryption is not a silver bullet and it is over sold. But in use cases where it mak

This comment is kind of baffling to me. I agree that first party end to end encryption is not a silver bullet and it is over sold. But in use cases where it makes sense, like messaging, it is a virtue and absolutely is worth the connivence security trade offs. Yes, the first party can secretly undermine the end to end encryption for a single customer without alerting the customer. However, this would be exceedingly hard to do for an attacker (insider or outside) compared to there being no end to end encryption. You would need to have the first party on board with this which would be very illegal unless directed by a government. So you might still be vulnerable to state level attacks, but the company might be able to resist it by pointing to end to end security vs encrypting it self. It still strictly better than no end to end security where the government will request everything that was ever sent. What is most odd is that you say that end to end encryption is not worth the convenience trade of but you think everyone hosting their own stuff would be better? This would be a disaster for both convenience and security. There zero chance that 99% of users would be able to securely self host their data. Even for the 1% that can and will secure their data, their data is likely also hosted in the other 99%. You just need to exploit the other side of the conversation and you are still screwed.

chrismorgan 3y ago
You’re underestimating the costs of E2EE even in messaging. There are plenty more that cause trouble (e.g. lack of recoverability, no content-based spam filtering, various key sharing problems), but I’ll focus on one that’s probably the easiest cost to talk about: no server-side search. If you want useful search, you have to download the entire collection, and be bound by your client’s performance. (In theory you can just download/store/upload an index, but in practice I gather that isn’t workable and doesn’t help anything.) This is generally tolerable for something like iMessages which is designed to be used on one or a very few physical devices where it’s persistently stored, but is very impractical for things like web access and larger collections, things like email. By most people’s threat models, E2EE for email is a terrible idea.

chrismorgan 3y ago

You’re underestimating the costs of E2EE even in messaging. There are plenty more that cause trouble (e.g. lack of recoverability, no content-based spam filtering, various key sharing problems), but I’ll focus on one that’s probably the easiest cost to talk about: no server-side search. If you want useful search, you have to download the entire collection, and be bound by your client’s performance. (In theory you can just download/store/upload an index, but in practice I gather that isn’t workable and doesn’t help anything.) This is generally tolerable for something like iMessages which is designed to be used on one or a very few physical devices where it’s persistently stored, but is very impractical for things like web access and larger collections, things like email. By most people’s threat models, E2EE for email is a terrible idea.