Freedombone Blog

Freedom in the Cloud

Epicyon and Spam Mitigation

I notice that the Pleroma project (another ActivityPub server) has been having trouble with spam, and there have also been earlier spam problems with Mastodon instances. They've mitigated it by having a captcha by default. Personally, I don't like captchas. I don't like them mainly because I can't solve them (the ones with heavily distorted text). As far as captcha systems are concerned I am a robot. Beep boop.

So how does Epicyon deal with spam?

In its design ActivityPub is quite similar to email, and that means it can potentially suffer from similar problems. There are a few ways that fediverse instances in the last couple of years have dealt with this.

The main one is http signatures. Without getting into the details of http signatures as a cryptographic mechanism this basically gives a reasonable assurance about which account a post is coming from when it gets delivered. But that on its own isn't enough. An adversary can potentially generate arbitrary numbers of separate accounts at electronic speeds.

An additional mitigation commonly used has been registration limits. On a public instance you might open new registrations for a limited time or for a limited number of new accounts and then close it again and allow time for the newcomers to settle. The settling time tends to avoid admins becoming overwhelmed by newbie questions, trolls or spam floods. This seems to have worked quite well, and Epicyon also has this available. You can set registrations to be open and then also specify the maximum number of new registrations. By default new registrations are allowed and the maximum is set to 10. In a Freedombone installation with the Epicyon app installed new registrations are closed and only created via a command in the background when new members are added from the admin screen.

Epicyon also has quotas, with a maximum limit on the number of posts which can be received from an account or a domain per day. So if there's a rogue instance sending out a lot of spam or if one of your friends accounts gets hijacked then the maximum rate at which posts can arrive is contained.

Then there is the infamous DDoS scenario. Suppose that there are a million bad instances out there on different domains and they all send one spam per day. In this case it's down to the firewall, and Freedombone only allows a limited number of simultaneous connections on the https port.

Epicyon also does things in a way which makes life difficult for spammers. As a general rule you only see posts from people that you're following. There is no public or federated timeline. And there is no relaying of posts going on either. To a large extent what you see is what you get, with no additional stuff from random accounts you're not interested in. So unless you are following a spam account they may have difficulty getting into your timeline. An extra feature which is off by default but which can be turned on if you need it is to only receive DMs from people that you are following.

It should also be said that Epicyon isn't designed to run large public instances with thousands of accounts. It's intended to support about ten accounts at the upper limit, for self-hosting or small groups. At large scale Epicyon would probably perform poorly, and this is another reason why it would be unattractive for use by spammers. A Small Tech approach has advantages which would otherwise become headaches for projects fixated upon scaleability.