3 ms·

I’ve taken to using the phrasing “first-party end-to-end encryption is snake oil”, which I feel is also incidentally a slightly more accurate take on the conte

I’ve taken to using the phrasing “first-party end-to-end encryption is snake oil”, which I feel is also incidentally a slightly more accurate take on the content of the article than the article’s own title, though both are generally true, drawing on different aspects, and both lack a little nuance. (I first used that specific phrasing a bit over a year ago, judging by HN search.) A large part of why I call it snake oil is that it’s generally being sold as an inherent and unassailable virtue, when in actual fact it’s nowhere near as perfect as practitioners of it try to convince you (and most of their marketing claims are flat lies, though some do word things more precisely), and you make significant compromises in usability and functionality, which they don’t tell you about. From a convenience perspective, end-to-end encryption is simply dreadful and that’s all there is to it. I wish we’d ended up with everyone hosting their own stuff instead, with completely decentralised infrastructure, which obviates extra end-to-end encryption (since transport plus storage encryption achieves just as much, and far more conveniently). But we haven’t, and there’s no realistic hope of ever ending up there with how we use tech now—it wouldn’t be particularly practical.

canes123456 3y ago
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.

canes123456 3y ago

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.