Serge Wroclawski discusses techniques to mitigate SPAM and abuse in the Fediverse. The video for this talk can be found at https://archive.org/details/apconf-talks/Talk4_Serge_compressed.mov.

These problems of SPAM and abuse can be found in all online social media, but in a federated, decentralized system there are particular problems because no one is in charge. Serge’s talk was designed to spark discussion more than definitively resolve the problem. So, what are the unwanted messages?

• Abusive messages and notifications – This is pretty self-explanatory, so I won’t give examples. I want to keep my “G” rating
• Follow SPAM – This is when someone makes a follow request, and when you click on it you see a SPAM message
• Archive Trolls – This is when someone says “I am going to monitor and archive everything you do online so I can harass you.”
• Unsolicited Commercial Messages – Again, self-explanatory. This is the classical SPAM message.
• Untargeted hate speech on the global feeds – This is nasty stuff that is not necessarily directed at you, but is definitely hate speech. Some trolls love to infest comments with this stuff.

This is not a unique problem to the Fediverse. Any open communication system will have unwanted messages. And we cannot stop any messages that are outside of our domain of control. In the Fediverse, this means that you cannot control what happens on a different node (i.e. server). You can only block them from your node if you have that control. For most users, that means finding a node that shares your values about these things.

We can learn from the past, though. because none of these problems is new. E-mail systems and Usenet all had the same problems. The answers we have right now are:

• Sender Authentication is essential. If you can hide who you are, it is a lot easier to send abusive messages and SPAM.
• Open Relays are bad. E-mail has proved that, and open SMTP servers pretty much do not exist any longer because that was a prime gateway for SPAM.
• Networks that require pre-established relationships don’t work. It is tempting to say “You can only send me a message if we already have a relationship,” but then how do you find new friends?
• We need decentralized systems with no centralized mediators. That is the whole point of the Fediverse.

This is not a simple problem. When new accounts and new nodes can be created by the thousands in mere seconds, human moderation does not scale. There is no magic solution. What is needed instead is defense in depth, with a variety of techniques, some layered, and some independent of each other.

There are some things that already work. HTTP signatures provide Sender Authentication. We can have Actor/Object validation by checking Object IDs. We can hide who we are following and who follows us to prevent spammers from discovering our social graph. And there is a standard for JSON Web signatures that could provide added protection if it is implemented widely.

But the big idea is OcapPub. Ocap stands for Object Capabilities, and this opens up another fascinating topic for further investigation . For now, this brief quote comes from the GitHub page:

The foundation of our system will be object capabilities (ocaps). In order to “give” access to someone, we actually hand them a capability. Ocaps are authority-by-possession: holding onto them is what gives you the power to invoke (use) them. If you don’t have a reference to an ocap, you can’t invoke it.

Before we learn how to build a network of consent, we should make sure we learn to think about how an ocap system works. There are many ways to build ocaps, but before we show the (very simple) way we’ll be building ours, let’s make sure we wrap our heads around the paradigm a bit better.

OcapPub is a proposal by Chris Webber to bring Object Capabilities to ActivityPub. They should be simpler than Access Control Lists, and can be revoked or transferred. This should lead us to Networks of Consent.

One of the more fascinating ideas is one I have been thinking of for a long time: Stamps! What if every SPAM you receive also paid you some small amount, like 10 cents? The system we have now places all of the burden on the receiver of messages, and none on the sender. This is why SPAM fundamentally breaks things. On top of this we can add a layer or two of traditional content classification to filter, using techniques like Bayesian filtering, sentiment analysis, image classification, and so on.

The System

So, remembering that we called this Defense in Depth, with layered techniques, what does this look like. One possible example might look like this.

A message is generated and sent to you. It first goes through OcapPub, and if the sender is someone you have given appropriate rights to, it goes right to your Priority Inbox. Otherwise, it goes to your Public system, and starts to flow through added layers. If it has a stamp, it gets passed to the next layer, otherwise it is discarded. Then the signature is checked. If the signature passes Sender Authentication, it gets passed to the next layer, otherwise discarded. Then the Object validation is checked, and pass or discard. Then the content filtering is applied, and if it passes all that it goes to your main inbox.

Listen to the audio version of this post on Hacker Public Radio!