Fake lag extensions to deter flooding

[rburchell]

We have a fake lag system already (to help deter flooding), but it's not really sufficient in the face of a distributed attack (which is pretty much all that happens nowadays, and is only going to get worse with the rise of the Internet of Insecure Things).

I was musing on this a little, and I came up with an idea that I think could be interesting: as well as setting penalty based on the action being taken (with high-noise actions like nick change being given a high penalty), maybe we should also consider taking the target into account, such that repeated message flooding from multiple sources would get a higher penalty.

We could also do it the other way around, so that we increase the penalty applied to someone who is being "noisy" for some reason, basically, instead of the existing:

user_penalty += command_penalty

we'd have:

user_penalty += command_penalty + target_penalty + sender_penalty

target_penalty: start at 0, increment by (command_penalty / 10) for every action (we do this division so that target penalty doesn't weigh too heavily on the result, but it will stack up over time.)

sender_penalty: start at 0, increment by (command_penalty / 2) for every action (again, divide to not impact the total too much, but we do it less here as the sender is ultimately responsible for what they send)

Both target_penalty and sender_penalty would need to be decremented (likely on a global timer or something) by some kind of factor, too, of course. Maybe that'd be better done as some kind of exponential decay, I don't know...

The math might need some (or a lot, I'm doing this while quite tired :P) work here, in particular, target_penalty's division may need to be dependent on the channel's population count or something.. but it'd be interesting to see how this would work out.

It would also probably be sensible to exclude anyone with channel status from target_penalty (or sender_penalty) to a given channel, and the usual oper exemption.

[rburchell]

Obvious risk of target_penalty: flooding could be more chaotic (involving more targets); but sender_penalty could help to spread that risk.

Obvious risk of sender_penalty: people who accidentally flood could end up getting whacked with a large penalty (but I don't consider this to be too much of a problem, personally)

[rburchell]

On second thought, I think it's better we don't exclude based on channel status (after all, people of privilege can still make mistakes, or turn out to be bad people).

Another thought: done right, we could consider extending this to an event (OnTargetFlood), too (e.g. to automatically +RimN ... whatever).

[SadieCat]

On second thought, I think it's better we don't exclude based on channel status

You could always just expose it through the exemption system and let the server operator choose.

[rburchell]

Some sketching of ideas, nothing concrete...
m_targetpenalty.txt