[dokuwiki] Re: Anti spam brainstorming

  • From: Chris Smith <chris@xxxxxxxxxxxxx>
  • To: dokuwiki@xxxxxxxxxxxxx
  • Date: Fri, 10 Nov 2006 01:39:58 +0000

Hi,

First off, I don't like the idea of any anti-spam mechanism that makes wiki contribution more time consuming. For me that rules out captcha.

I'd like to think we can provide a number of improvements to reduce the impact of automated dw spamming, these are some ideas...

1. Tools to quickly undo the effects of spam. The revert plugin is a great start. I think we can also: - add a changelog entry type of "S" for spam. Entries marked with an S aren't shown in the recent changes log or in rss feeds. - automate the revert based off a search string, including changelog and recent changes amendments (perhaps already done)

2. Improved tools for detecting/blocking spam attacks:
- add badbehaviour plugin to dw codebase, extending it to be a complete toolkit
- allow editing of blacklist (adding ips),
- sharing of blacklists (e.g. participation in vipul's razor) & automation of sending notification of new spam attacks to blacklists - add events to allow plugins to include information in main edit form (e.g. for captcha plugins).

The recent attacks on DW were characterised by huge increase in edits performed over a short period of time. Detecting that sort of change in behaviour shouldn't be too difficult. On detection DW could email the "notify" contact and disable editing/registering by non-trusted users for a limited period of time (e.g. five minutes).

3. Addition of a new membership level, trusted editor. Would work like a moderator in a forum with access to restricted number of items on the admin menu, like banning users, adding ips to blacklists, running spam reverts. This would speed up the process of responding to a spam attacks and spread the editorial load on busier wiki's without giving complete superuser control.


Cheers,

Chris

PS. Some idle thoughts on preventions:
- A simple prevention mechanism, may be to place a secret time dependent token on each form. Reject any post with an expired token. Also reject any edit with a "not yet valid token", say with a token that doesn't become valid for 15 seconds and expires after 2 hours (instead of outright reject, require a captcha). - On Harry's point and assuming the bots aren't real full-featured browsers under bot control (and going against my first point). You could implement a captcha by default and cancel it via javascript/ajax (by requesting the answer or someother varying token from the server). This assumes the bots aren't capable of running javascript and would only penalise those visitors who didn't have javascript enabled.







--
DokuWiki mailing list - more info at
http://wiki.splitbrain.org/wiki:mailinglist

Other related posts: