Mastodon: Flood Attack on Federated Public Timeline

Created on 17 Mar 2019  路  9Comments  路  Source: tootsuite/mastodon

Pitch & Motivation

I don't know how to describe this problem, so I just tell a story.

Imagine that you own a small instance with a group of friends. One day you find that some newcomers sign up. At first you are so happy and send a lot welcome message, but after a while you are not happy anymore. Well, they just follow an amount of accounts at different instances (or just import a csv file) and your federated public timeline is now full of News/AD/Porn/Religion/Arabic(No offense)/...

Maybe a kind of flood attack? I don't know whether Mastodon has a solution to this situation:

  • mute/block an account: too many accounts to mute/block
  • mute/block an instance: too many instances and side effects
  • regex/keyword filter: no way, only a part of it
  • filter by language: only a part of it. Local public timeline will be filtered, too. Most of us don't specify the default language of toots -> misclassification and side effects
  • Ban these new accounts: only when I am the admin, and they never violate the ToS ...
  • Make the instance invite-only: only when I am the admin, and bad news for newcomers?
  • Cross-instance follows need admins' approvals: problem solved, but not convenient for users.

And another curious problem: will Mastodon have a performance problem when every user has a long mute/block list of accounts?

Most helpful comment

Mastodon has functionalities that are similar to what MRF can provide, but they aren't granular (you get silence or suspend with some augmentations). I believe that the granularity is the key for solving this type of issue, as you may simply want to remove content from the FTL without exposing the users in question to a "default block" state as with silences.

All 9 comments

Pleroma accomplishes this using a system called MRF. Specifically, MRF is used to solve this problem by applying actions to configured instances (such as removing the entire instance's future posts from the FTL), tagged users (such as removing the user's future posts from the FTL), or post content (such as rejecting posts which reference a specific domain or keyword). This may be a good design basis for a similar system in Mastodon which would provide the desired flexibility.

Mastodon has MRF. We just call it domain blocks. Domain blocks don't have to be blocks, they just control what happens to specific domains, such as rejecting reports, media, removing them from FTL, or blocking completely...

Mastodon has functionalities that are similar to what MRF can provide, but they aren't granular (you get silence or suspend with some augmentations). I believe that the granularity is the key for solving this type of issue, as you may simply want to remove content from the FTL without exposing the users in question to a "default block" state as with silences.

Would it be possible to give admins instance-wide spam filters to fix this problem?

For example in the case of the "womenarestupid" stunt admins could have just hidden every toot that linked to that domain or auto-blocked/suspended any users linking to it.

auto-blocked/suspended any users linking to it

that might be overly broad but it should be easy to, say, remove from the public timeline, maybe auto-generate a report and forward it to the originating server. mods can then deal with the reports by suspending the spammers and dismissing erroneous reports.

It would be nice to have a way, in the adminisration, interface to sort instances by the size of their media attachments.
Our instance is seeing a drastic increase in disk usage since the last 48h, caused apparently by media attachments that don't appear in the local timeline (15GB/day, while we where below 1GB/day before). So it's hard to find out where the spam comes from and block it.

Mastodon has MRF. We just call it domain blocks.

How can we use Mastodon's MRF functionality to, say, drop all messages containing a particular text that's being widely spammed from many many Mastodon instances with impunity?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

This is not fixed

Was this page helpful?
0 / 5 - 0 ratings