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

Fediversity
1

Disclaimer: I am not a security professional, just a greying Direct Action activist, and this is not security advice. Just some information to add to the mix when you’re evaluating your options.

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, so people can safely share the most intimate details of their lives with specific people, and only them, is a huge project. It can’t be done properly by just bolting stuff onto existing fediverse software.

It can be done, as demonstrated by apps in the Hubzilla branch of the fediverse, although they tend to be hamstrung by confusing interfaces. If people are posting private stuff, the controls need to be even easier to understand than for public posting apps. Projects like Bonfire Social, and the SocialCG’s work on MLS encryption so we can encrypt private posts, 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 using the Matrix protocol (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.

1 Like
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.

7

No need to get upset. I should have extracted the points from HN in my top post. I was on mobile and hasty, but that is no excuse. Then you wouldn’t have posted something giving the impression to outright reject just because it was said on HN (I know people get emotional about that site), and I wouldn’t have followed-up with further explanation.

8

Hubzilla and Streams are examples of fediverse software that is primarily built for private communication. Privacy in ActivityPub is very easy, actually – every activity is private by default. Server operators should be trusted, but that is less of a problem if your closest contacts are self-hosting or are located on the same server.

1 Like
9

Not upset, just a little frustrated. But thanks for the concern :smiley: If you have any remaining questions about security concerns in private comms, batter up!

1 Like
10

True. this family of software is an exception to the public-first rule of thumb, including private communication features from their earliest versions. But it’s arguable whether any of them were or are primarily intended for that. Do any of them use E2EE for S2S message passing?

Firstly. OStatus - the original fediverse protocol - was the opposite. It didn’t support private messaging at all, which is why Diaspora created their variant.

Secondly, there’s a difference between private and reliably-private, which is why I specified that. As with email, there’s absolutely nothing stopping messages being intercepted and read as they’re passed from server to server. E2EE doesn’t prevent all possible uses of surveillance, but if it’s configured properly, it does at least stop bots passively keyword-scanning the contents of all messages, for juicy stuff to pass on to humans.

This is a good example of why thread modelling is important. The security implications of sending unencrypted private messages are very different, depending on whether or not you’re all using the same service (with C2S connections encrypted with TLS), and whether you know the admin(s) to be trustworthy and competent.

11

According to their documentation, yes:

optional password protect content via crypto-javascript browser-to-browser encryption (needs to be enabled in settings)

– Help: Encryption

12

Good to know there’s some level of encryption, but it’s explicitly not E2E. From the linked page;

every non-public post is automatically encrypted but persons who have access to the site’s database and files may be able to decrypt everything

Which means that as with any other fediverse service, you have to trust not only your admin, but the admins of any other services you send private messages to. But if your threat model only requires you to avoid passive mass surveillance, this definitely ticks the box. As do Signal and other centralised encrypted messaging services not run or proven compromised by known DataFarmers.

Other services store your messages in plaintext, therefore we regard this approach as a significant improvement for your privacy

100%.

But if you have reason to worry about being targeted by Bad Actors with the ability to social engineer admins, or otherwise obtain admin access to services you use or communicate with? For that kind of threat model you want independently auditable E2E encryption. Depending on your level of risk, you might want audited E2EE.

I’m planning a blog post laying out all my concerns about Signal, and how to debunk them. It will be intriguing to see what sort of response it gets.

1 Like
13

The part that I quoted is about “browser-to-browser encryption”, which sounds like E2E. Mike Macgirvin also talked about this feature on several occasions (but it is possible that I misunderstood something).

14

It seems like you didn’t read past that first sentence. Following that is another quote from your linked text, and an explanation of why that’s not E2EE.

There’s no correctly functioning state in Matrix, OMEMO or AutoCrypt where;

persons who have access to the site’s database and files may be able to decrypt everything

That’s specifically not E2E.

15

The article describes two kinds of encryption: encryption at rest (where keys stored on the server) and optional “browser-to-browser” encryption (for which, I assume, a one-time password is used).