0 Moderation Tools: Votespam detection
ryexandrite edited this page 10 months ago

Outline of votespam detection and mitigation techniques

Throughout this document, "posts" will be used as a shorthand for "posts and comments"

The current swarm of votespam bots we are dealing with act very predictably. They seem to be scanning the new post feed for any post matching a certain criteria and instantly dispatching the swarm to vote on them. While some of these criteria are obvious, probing the botnet by posting garbage on our own platform is not an ideal solution to dealing with the problem.

Members of these botnets can be identified through different heuristics (as helpfully demonstrated by comrade Pavlichenko). For the current crop, two methods come to mind:


SwiftBoat is a planned Actix middleware which aims to add heuristic anti-spam capabilities to Lemmy. In otherwords, it is a pre-processor for API calls that can maintain its own state and take action without needing to change the core API implementation. Actix implements an Actor system which allows these "middlewares" to transparently alter or reject requests, as well as translate one request into many. Hopefully this will allow us to decouple the core application from the "meta" bits like session management, anti-spam, and error handling, among other things.

Per Post Strategy

These bots are seemingly triggered into action immediately upon the creation of new posts. When posts are created, the SwiftBoat service will add their IDs to a watchlist stored in memory. Then, as vote requests are processed, the voters will be added to a bucket assigned to that post. Posts on the watchlist will be assigned a short timeout, and when the timeout expires, the SwiftBoat service will check the bucket to see if the number of voters exceeds a reasonable threshold. If so, the users in the bucket can be flagged or banned, and their votes can be bulk-reversed. (We should be careful not to punish the post creator, who may also be in that bucket)

A 10 second timeout with a limit of 10 votes seems like a reasonable place to start, but we can play with these variables, or even compute averages from our production data and set the limit in terms of standard deviations from what is considered to be ordinary activity - perhaps even on a per-community level.

There is a chance the spammers may begin to delay the activation of their botnet. This could potentially be mitigated by making it so any vote returns a post to the watchlist (with a new, empty bucket) until the timeout is reached again (note: individual votes should not extend the timer, only trigger the post to be watched again if it isn't on the list). However, this approach might be defeated if vote spam is programmed to trickle in over an extended period of time.

Per User Strategy

Putting instant voters into a bucket can catch simple votespam botnets, but there are other cases of abuse this may miss. For instance, the botnet operators may become aware of the threshold and aim just below it. Or they may target individual users with a small number of votes. There are probably other examples too. Here are some potential strategies for identifying these accounts.

  • If a user account only votes on brand new posts
  • If a user account makes a lot of votes, but only votes on a small group of users (and perhaps, consistently the same way per user)
  • If a user account makes a lot of downvotes but never comments