Page MenuHomeWildfire Games

Remove clientside lobby spamfilter
ClosedPublic

Authored by elexis on May 17 2017, 2:24 PM.

Details

Summary

Broken:
The spam filter in the 0ad lobby client code is broken, because it blocks users that didn't spam but didn't block all users that did spam (see #3832).
Most recent report was yesterday:

treegb2:?
treegb2: who is pinging me?
treegb2:some history message is lost when I get in lobby again

It is also highly broken because different users see a different subset of spammed messages. Hence some people respond to messages others don't see, then the others ask about message they didn't see and the spam will become reflected and amplified.
The spam filter is also incurably broken by concept, because the filtering must be done in the ejabberd server (otherwise moderators are still spammed).
Spam was rarely an actual problem. If someone spammed and wasn't kicked immediately, he got tired after 20-40 messages in every case so far.

Alternative ejabberd spamfiltering:
Filtering in the ejabberd server requires no controversial changes (like rP17941) in clientside code.
Spam filtering can be improved with the mod_block_strangers module which blocks unsubscribed clients.
The captcha_protected field could fight spambots in case that were an actual issue.
There is XEP-0016 Privacy Lists which allows people to selectively block others. But this seems like something we would want to avoid for the reason stated above.
mod_pres_counter prevents subscribe/unsubscribe spam.
There is the min_message_interval field:

This option defines the minimum interval between two messages send by an occupant in seconds. This option is global and valid for all rooms

and min_presence_interval

This option defines the minimum of time between presence changes coming from a given occupant in seconds.

and max_users_presence

This option defines after how many users in the room, it is considered overcrowded

and members_only

Only members of the room can enter.

mod_metrics can be used to find spammers statistically.

Few more modules are refered to here which partially don't seem implemented on ejabberd yet https://de.slideshare.net/mremond/fighting-xmpp-abuse-and-spam-with-ejabberd-ejabberd-workshop-1
It could also be implemented with a custom ejabberd modbot that kicks or bans people who spammed.

On the other hand:
If fixed, the spam filter is a non-expensive way to filter a part of the spam for part of the lobby users.

Test Plan

Decide for one of the two strategies

Diff Detail

Repository
rP 0 A.D. Public Repository
Branch
/ps/trunk
Lint
Lint OK
Unit
No Unit Test Coverage
Build Status
Buildable 1775
Build 2811: Vulcan BuildJenkins
Build 2810: arc lint + arc unit

Event Timeline

elexis created this revision.May 17 2017, 2:24 PM
Vulcan added a subscriber: Vulcan.May 17 2017, 3:11 PM

Build is green

Updating workspaces.
Build (release)...
Build (debug)...
Running release tests...
Running cxxtest tests (306 tests)..................................................................................................................................................................................................................................................................................................................OK!
Running debug tests...
Running cxxtest tests (306 tests)..................................................................................................................................................................................................................................................................................................................OK!

http://jw:8080/job/phabricator/1237/ for more details.

scythetwirler edited edge metadata.May 17 2017, 6:37 PM

Sounds good to me.

Itms resigned from this revision.May 20 2017, 10:02 PM

I agree it would make more sense to filter the spam from the server side. I don't have a strong opinion about keeping a spam filter at all, but you may want to start a thread in the staff forums.

I don't really like removing code that partially works and might be useful in a situation that has never occured in case every moderator is on vacation or ragequit.
But with this approach is is impossible to keep clientside spamfiltering if we want to have all users to see the exact same set of chat messages.

binaries/data/mods/public/gui/lobby/lobby.js
1133

This is wrong, if someone spammed and it's blocked for users who were present all the time, it should be equally blocked for users who just joined.

1317

So even if we fix the timestamp issue, this is still broken because the last message could have been sent ages ago when returning from a game, so some clients see a different set of chat messages again

1345

Should (have) show a notification if others are blocked too

This revision was automatically updated to reflect the committed changes.