The Challenges of Adding Reliably-Private Social Networking to the Fediverse

Fediversity
1

There’s a reason both the OStatus fediverse and BlueSky started as public-only networks. It’s much easier to build software for public discussions than for private messages.

For a start, there’s a whole lot less to build, especially when your software is intended to work in a decentralised network. But more importantly, there’s a whole galaxy of Trust & Safety and security headaches you don’t have to deal with.

Posting to a traditional web forum is widely understood to be making a public statement. It’s fine to quote it elsewhere, link to it, index it for search, and so on. A system for private messages between forum members can be as simple as just forwarding to their email address. Which is pretty much the only private data you need to secure.

Your interface needs to make it crystal clear to people when they’re posting publicly vs. privately, and your back-end needs to reliably keep the promises it makes. But there’s a hard limit to how badly your forum software can accidentally violate people’s privacy.

Federating forums are a bit trickier than traditional, centralised ones. But you’re only sending public comments - intended to be shared with the world - from one server to another. Unless your email sender starts posting private messages over the federation protocol you’re using (which would be a critical bug!), there aren’t too many other ways it can go wrong privacy-wise.

If you start hosting private messages on the server itself, suddenly there’s a lot of ways it can go sideways. You need to make sure those stored messages are securely stored. You need to make sure the sender and intended recipients can access them, and only them.

You need to balance making them easy to access with a range of browser apps, OS, and devices, with the need to keep them opaque to unintended recipients. Even more so if you start federating private messages with other servers. If you use End-to-End Encryption to do that, it adds a bunch of complicated code to write and maintain, and a whole new range of ways it can all go wrong (see the chronic “Unable to Decrypt” errors that have plagued Matrix 1.0).

In summary, it’s great that the fediverse supports some level of quiet interaction. As long as your server admins are trustworthy and competent, posts using the ‘Only People Mentioned’ are probably private. Probably.

But building a privacy-respecting replacement for something like FarceBook, where people can safely share the most intimate details of their lives with specific people, is a huge project. It can’t be done properly by just bolting stuff onto existing fediverse software.

It can be done, and projects like Bonfire Social and the SocialCG’s work on MLS encryption are big steps in the right direction. But if we want to do it right we need to take our time.

In the meantime, there are folks who need to have reliably private conversations right now. I encourage them to check out some of the decentralised chat options that already support encrypted messaging, using variants of Signal’s protocol. With apps for all major OS.

Delta.Chat: private text messaging, media-sharing, group chats, etc, using your email account (encrypted using AutoCrypt).

Snikket: All of the above, plus public groups, and voice/video calling, using an XMPP account (encrypted using OMEMO)

Element: All of the above (encrypted using MegOLM), plus groups and their messages are stored on every participants’ server, not just the one it was started on.

2

Anyone know why there are no new posts appearing in the Fediversity category since Jan 29, even though there have been at least 2 things posted in the category since then, including this one?

3

Wrt private uses it is good to read the HN submission that is currently on the front page.

4

Pfft. The usual pissing contest between pseudo-security stans. People shilling proprietary services as if it’s possible to know anything about what’s under the hood. People shilling Signal as if they don’t blow a huge whole in their anonymity by using phone numbers as identifiers. Or using Goggle and Giphy dependencies in their apps. . Or pushing people into using Goggle and graApple app stores, by refusing to let F-Droid and other app libraries compile from scratch, or give them a reproducible build. Or hosting their entire centralised silo on AWS.

Worst of all, people who don’t have the first clue about how threat modeling works, and claim no security is better than strong-but-not-perfect security. Even when it might be more than adequate as part of a set of software and practices for a given threat model.

Like most HN threads, a waste of life.

5

That is too easy a rejection. I pointed to people discussing privacy and security shortcomings.

It is irresponsible to advise people a “private messenger” when that is inadequately secure given their threat profile. I am no security expert but the HN mentions some serious matters to take into account, in the top comments. No forward secrecy and metadata privacy is mentioned. I really like DeltaChat as a project, and they are developing fast, making strides. That is not the issue.

:backhand_index_pointing_up: This triggered my response. I am unsure if DeltaChat is production-ready, security audited, and battle-hardened enough to be listed in one breadth with Signal and Matrix, for the audience I think you refer to in that sentence.

6

Yes, and I told you how little the opinions of that peanut gallery are worth, with examples of why. Maybe you think they’ee all l33t hackers because the site is called “Hacker News”? They’re not. It’s just a vanity subteddit run by venture capitalists (Y Combinator).

I’ve been involved in direct action planning on and off since the 1990s. I was running activist infrastructure projects in the 2000s, and writing guides for activists on how to encrypt email with PGP. I’ve studied operational security as a whole, not just digital security. Not out of hobbyist curiosity, but because it was necessary to keep my people safe.

I know the limits of my security knowledge and choose what I say about it very carefully.

Right, but in the absence of anything about how that affects specific threat models, that’s word salad, not analysis. Whereas services being proprietary means that no security promise they make can be independently audited, which affects all threat models. That’s an analysis.

As it happens, being centralised is one of the things that makes a service proprietary. Because no one can independently confirm what the server is doing, even if they publish code and claim it’s what they use in production. In the absence of a fully reproducible build, ToS that oblige usings apps compiled by the vendor make it a proprietary service too.

Signal does both of those, which means that like WhatSapp, their security promises have to be take on trust. Which makes their E2EE promise worthless, because the whole point of E2EE is so you don’t have to trust the service. Even if its promises weren’t worthless, Signal is a SPoF and a juicy target for state-level actors. Since there’s no way to confirm it’s not a honeypot, it’s safest to presume it is.

So with all due respect, anyone holding up Signal as the gold standard for secure communication isn’t qualified to have an opinion on it. That disqualifies most of peanut gallery on HN.

Whereas I wouldn’t even be suggesting it if I wasn’t sure;

“Bringing E2E privacy to the Web: 4th security audit”

In summary, you’re calling me out for discouraging people from using existing fediverse DMs for sensitive comms, and offering some alternatives as candidates for evaluation. But you’re bringing a potato peeler to a gunfight, and I stand by every word in that piece.