On the “Libera Chat” Spam
This blog post was originally a wall of text on GNOME’s Discourse to discuss of the impact of IRC on GNOME’s community safety.
First, of course, we know that despite what the spam indicated the spam did not actually come from Libera Chat teams. It comes from imbeciles who obviously wanted to give Libera Chat a bad image by flooding all sorts of disgusting messages.
What happened?
Let’s have a clear look at what actually happened.
- Many IRC channels were flooded with spam messages. Given our Matrix instance and the IRC network we rely on are bridged, the flood messages were forwarded to Matrix
- Those IRC channels were not in
+R
mode. This is the mode that only allows people who are registered on IRC and have cast the NickServ spells to join - Most of those channels were not set on
+R
mode during the flood - Since the flood matched simple expressions, it would have been easy to prevent it at server level but it didn’t happen
- Several people have been granted privileges on Matrix and have been running scripts to clean up all the garbage left by IRC spam
- New versions of our Matrix instance have been deployed an hour after the spam started, with more agressive spam filtering so the messages didn’t make it through anymore. Spam kept happening on IRC but didn’t make it through Matrix.
What can we learn?
As one of the persons who had to manage all the cleaning of the spam on the Matrix side, this was a very frustrating evening. It really felt like bailing out water of a boat with huge holes in the hull. And to be completely honnest: this was not a very sophisticated nor massive attack, making the struggle even more infuriating.
The easy solution could be to blame the computer. I could ragefully blame IRC, and actually did during the flood, out of exasperation. But the problem is not IRC. The problem boils down to two major issues:
- The registration/authentication experience on IRC is really cumbersome: as a result, most IRC channels don’t have a lock on the door
- We don’t have a proper moderation team with sufficient privileges to react quickly on IRC, and worse: we don’t have sovereignty over the IRC network we use to be able to set-up spam filters at server level. People who run it are volunteers who do their best on their spare time, and there is no real decision-making process nor way to enforce decisions on all servers of the network. It leaves the door open for spam on both platforms and is an effective risk for our users
The key takeaway after discussing with the GIMPnet administrators is that GIMPnet is running in maintenance mode. The administrators are keeping the network running, but don’t have the time or energy to carry out significant evolutions.
What is our way out?
The first solution that comes to mind would be why don’t you just put a lock on the doors then? And of course, like many of the why don’t you just questions the answer is not as simple as it seems. Today, GIMPnet is not making any exception for the IRC/Matrix bridge. Setting blindly all channels in +R
mode on IRC would degrade the experience both on IRC and Matrix:
- IRC users would need to cast the NickServ registration and and authentication spells
- Matrix users who didn’t register on IRC and taught the bridge to play their credentials could just not join the conversation
- It would require every existing and new channels ops to set-up the
+R
mode
Not great.
But I still have pretty high hopes that we can do better together. I had a very short and informal conversation with GIMPnet administrators who told me:
this recent upheaval has pointed out that there might be some need for a bit more modern processes and maybe getting some more active staff in that might have new and bright ideas
We still need to have a more formal conversation with the GIMPnet administrators and @averi to push the idea forward. If we can manage to have special privileges for the IRC/Matrix bridge on GIMPnet, we can find solutions to automate spam management without degrading the experience.
It is possible to set more agressive anti-spam settings on IRC, all while putting the bridge on an allow-list. This would require a bit of tweaking on the IRC side, but would definitely make the experience better at both ends.