Flood detection and blocking

Bugs & Features
1

We need something to prevent command flooding.

Both to prevent chat spamming, but also to make DoS type of attacks a bit more difficult.
No problem yet, but eventually it will be.

My idea:

Flood detection rules

  • Each player has a spamScore
  • Every command (say, look, create char, go, etc.) adds a fixed number to the spamScore
  • Each command may add a different score. pose = 10, createChar = 50, etc.
  • If the spamScore would become > 100 (configurable), the command is denied. No score is added.
  • spamScore is decreased with 1 every second.
  • spamScore is never less than 0

This would allow bursts of commands. But if pose adds 10, the initial burst would allow 10 poses. After that, you can only pose every 10 seconds.

Any comments?

/Accipiter

2 Likes
2

I thought flood detection was something that went off when one of those 30 meter dudes took a leak in the park.

2 Likes
3

A sliding-scale throttle makes sense. I’d suggest the cost of each command is relative to it’s processing cost for non-visual commands from the DoS angle, and say/pose/spoof cost a little extra since they can be used to annoy others.

I’d have the slowdown ramp up though. Maybe exponentially. So you can throw out two or three poses fairly quickly but pose 4 has a second delay, pose five two seconds, pose six is four seconds, etc. That accomodates someone reposting a short article of 3-4 paragraphs without being punishing, while also quickly “responding to” someone trying to dump 20 lines and being allowed to get 10 out before being cut off.

This would necessitate a queue of some sort though, with a warning if you queue up more than two or three things and perhaps a hard limit of 4-5 items in the queue, along with a “queue clear” command to ‘abort’ pending stuff once you realize you’ve been throttled, if that changes what you want to say or do.

Sometimes people talk very quickly. I know I do. But if your spamscore decays reasonably every second, that should be less of an issue. I can’t really say anything meaningful more than once a second, certainly, and I like to think I type pretty fast.

Edit: Of course, now that I think on it, the queue would have interesting interaction with the spamScore decay. Would need to either have it decay at half-rate or something if you’re keeping the queue full, or just pause the decay entirely until the queue is empty.

1 Like
4

I agree. And the cost should be easy to tune if needed.

I assume you mean for the purpose of not annoying others?
I don’t think we should limit (or slow down) “normal” usage at all. I would consider it normal to post quickly 4 things in succession. And it would just be frustrating if it started to get queued to be posted later.

I’d rather just ‘detect’ when a behavior is not normal, and then block the call completely.
If the call was made from command, we can tell it in the console:

You are being too active. Wait X seconds and try again.

Of if it is done using the GUI, we can popup a non-modal/non-blocking notification in the bottom right corner.

Of course, you can get false positives. But then the message is at least clear about it, so you know how long you need to wait.

I don’t really think queuing is the way to go. It would also bring in a lot of unnecessary complexity, as you describe :sweat_smile:

But still good to think about the options!

1 Like
5

Yeah, that makes sense. I was sort of thinking that under “normal” usage the slowdown would be virtually transparent, but once you start ekeing into ‘abuse’ territory you slowly slow down to provide a warning mechanism without just flat-out locking someone out. Obviously at some point someone’s going to toss out five or six lines really fast.

like
wow
I mean
wow
geeze
wow

For example. But if you try writing a whole sentence one line at a time you’re gonna start getting slowed down to discourage it.

Yeah, queues would be complex. I like to over-engineer I guess, then back up from there to compromise ideal effect with my own laziness. :slight_smile:

Definitely should have a UI element to warn and one to inform where you’re at and how long you have until you’re good again.

1 Like
6

Yeah, that seems like a pretty smart idea. I appreciate that it won’t cause problems for something like a run script.

1 Like