 The #Kolektiva database seizure (https://kolektiva.social/@admin/110637031574056150) shows the importance of #e2ee. If DMs had been end to end encrypted, seizing the database would have been less impactful, as while the seizing authority could still have seen who messaged whom, the content itself would still be encrypted, even if the db as a whole was unencrypted. If you want to DM more privately, you are welcome to ask for my matrix, XMPP, PGP, or Signal details. 23 comments
@neil I would personally have loved a fediverse in which *everything* is e2e encrypted. Maybe the next generation of federated protocol will work that way ^^ > I would personally have loved a fediverse in which *everything* is e2e encrypted. I am interested in how you’d see that working: - I presume it would mean eliminating “open follow” accounts (like mine), and requiring people to approve follow requests, as otherwise any adversary could follow and obtain access to (future) posts. But… - if A posts something and B boosts it, C, who follows B but not A, could see it? Does e2ee add anything? @neil I don't think open follow accounts like your have the threat model of trying to prevent randos from seeing your posts. To you it would mostly add enforced encryption at rest. For public/unlisted it would mostly add enforced encryption at rest, but follower-only posts can't be boosted. And it protects those against bad actor servers that e.g. index or publicize them. I can see how it would work in the context of follower-only posts from restricted follow accounts. Absolutely. And, just in case, I didn’t mean to be dismissive of those who choose or need to engage in that way - not at all. In other, more public, contexts, I am less sure it would work at all!  I believe that's exactly what Spritely/Goblin is trying to do with Ocaps (but I'm just lurking at their work, I don't really understand it).   > in which *everything* is e2e encrypted. You would have to exchange keys between every combination of author/reader, and probably per-device or even per-app. The computational impact and restrictions (no guests, for example) would trump the benefits. And at that scale, can you really trust everyone in the first place? E2EE makes sense for private conversations and small group chats.  @neil honestly, Fedi isn't built for E2EE and that's fine. "do one thing and do it well" has some truth, and here it is very true. @neil@mastodon.neilzone.co.uk @Yuvalne@433.world  @neil If limited to "recipient+sender" messages only it would be more straightforward, wouldn't it? Wonder if it's worth someone writing something that adds it only for those. 🤔 (Using some kind of external, proven library, I mean, to minimise the burden on fedi devs to start from scratch and get it right) @tokyo_0 I think I'm still erring on the side of "leave that too a security-focussed messaging system", rather than creating another one here. @neil That's fair enough. It probably would be more dangerous to give people a false sense of security. |
Gregory's Server
That said, I have changed my view on whether fedi software should implement #e2ee for DMs.
Originally, I thought “yes”.
Now, I’m less sure. Doing e2ee well is hard, and is perhaps best left to the myriad existing alternatives, rather than being Yet Another Thing for overworked fedi developers to get right, particularly given the consequences for getting it wrong.