A talk about blocking fediverse instances

Oh boy... time to get writing about the Fediverse again. Well, that's gonna be fun. Let's talk about blocking instances. Or specifically, I want to help people understand what an instance block actually does, what it doesn't do and the method you can use to -completely- block an instance.

Instance blocking

So, as disappointing as it is, the internet isn't just filled with happy go lucky people who just want a casual chat. It's also filled with several bad actors. People who, if given half the chance, will actively promote hateful or inciting content.

These people also, for somewhat obvious reasons flock to decentralized software, such as Mastodon and Pleroma.

To counteract this, both Mastodon and Pleroma offer control over what instances are shown to the user. Mastodon offers domain suspensions or removal from it's global timeline, whereas Pleroma offers the “MRF”, which offers the same features as Mastodon offers, but can also be used to for example enforce CWs or marking images as NSFW on all incoming posts from an instance.

I'm not here to name any instances or what kind of block policy you should enforce. That isn't my duty. There are many blocklists and block advisories out there that you can use to see what instances are awful and which are not.

Instead, let's talk for a moment about how this affects federation.

What an instance block does.

If you block an instance through Mastodon or Pleromas interface, what you end up doing is stopping users on your instance from accessing the blocked instance through yours. In a sense, it's the equivalent of muting a user on Twitter, except it's applied to your whole instance.

This is all it does. It's essentially a firewall against incoming messages from another instance.

What an instance block doesn't do.

An instance block is not a silver bullet against stopping harassment or harassing users. While it prevents their harassment from landing in your users inboxes, it doesn't stop them at all from reading the statuses your users post on their accounts.

As a result, an instance block is entirely one-way. To illustrate this, I think it's best to give a sample situation.

Meet our three users. Alice, Bob and Caroline. Alice hosts an instance on the fediverse that Bob makes use of. Caroline is on another instance. Thanks to the power of the fediverse, Caroline can see Bobs statuses and the other way around.

Now, suddenly, Bob and Caroline have a huuuge fight, and it ends up with Caroline publishing doxxing information about Bob on her account. Alice in response blocks the instance Caroline is posting from, as Caroline's instance refuses to clean up the doxxing.

However... Caroline can still see Bobs statuses and can still keep track and find new information to harass him with.

This is an inherent failing in the way both Mastodons domain suspension and the MRF that Pleroma offers are designed, and one that is nigh impossible to counteract through how Mastodon and Pleroma are designed.

How to completely block an instance.

That said, there is still a way for Alice to completely stop Caroline from reading Bobs statuses through her instance. This is by blocking the IP address of Carolines instance.

Before I'll continue with an example on how to do this, I'll quickly explain why neither Pleroma nor Mastodon implements this in a nice frontend in a somewhat technical manner. If you don't understand it, you can safely skip this paragraph and just assume that they can't do it. It specifically has to do with how an admin is expected to set up applications that these two utilities are written in. Specifically, the intent is to reverse proxy the actual (sub)domain to the port on which Pleroma and Mastodon run on. Under normal circumstances, the IP address that is used to visit your instance is properly passed along to the reverse proxied IP, but if the webserver is improperly configured, this is not a guarantee and the server could end up sending along it's own IP, which if a UI version of this could end up blocking a server from accessing it's own instance. Then there's also the issue that there are a number of fediverse service providers that will set up a Mastodon instance for you if you fork over enough money. These instances often end up sharing IP addresses, which can result in an IP ban overreaching it's intended domain block and banning several innocuous instances.

With that out of the way, let's take a look on how Alice could stop Caroline from reading Bobs statuses. The following instructions are intended for firewalld, the default firewall that comes installed with Fedora server.

  1. Obtain the IP of Caroline's instance. There are a number of methods to do this. For example, we could use the dig command to look at the A record of Carolines instance. There are options for this, which I recommend you look up yourself.
  2. Alice logs in on her instance's VPS.
  3. Alice runs the following command: firewall-cmd --permanent --add-rich-rule="rule family='ipv4' source address='IPADRESSHERE' reject", replacing IPADRESSHERE with the IP she obtained from step 1.
  4. Alice reloads firewallds config: firewall-cmd --reload
  5. Done.

Alice has now succesfully stopped Carolines instance from being able to even access Alice's instance. The firewall stops Carolines instance at the door by rejecting access instantly.

Conclusion

Of course, Alice, Bob and Caroline are fake in this situation, but it does illustrate that it is entirely possible to completely stop an instance from reading your statuses on the Fediverse. It's just not possible if all you're going to do is enable a domain suspension or reject them through MRF.

It takes a little more effort than that, but it's still possible.