The most effective anti-vandalism measure is an active community. We have a team of people (the Recent Changes Patrol monitoring all edits made, and vandalism and spam are quickly reverted.

We are also looking at other measures such as bots (as used with great efficiency at Wikipedia) to monitor and quickly revert vandalism.

See also the talk page, for further discussion.

Settings[edit | edit source]

Restricting permissions for page moves[edit | edit source]

Page moves are harder to revert than other changes, so we added this to our LocalSettings.php: 

# To thwart vandalism these adjustments (intended)
# to limit move permission to "autoconfirmed" users
$wgAutoConfirmAge                             = 3600*24*10; // 10 days
$wgAutoConfirmCount                           = 10; // 10 edits required
$wgGroupPermissions['user']['move']           = false;
$wgGroupPermissions['autoconfirmed']['move']  = true;

(Note: the variables are linked to relevant resources, above, but you can ignore that in LocalSettings.php and just paste in plain text.)

Suggestions[edit | edit source]

  • implement a bot or bots taken (with permission) from Wikipedia spam & vandal-fighters. E.g. Tawkerbot.W These could run on the server, for faster, 24-hour operation.
  • ban page creation by anons & new accounts (like Wikipedia) - On Appropedia, it is likely that some readers will never sign up until they are ready to create a page based on their project.
  • implement soft-protection for pages that are spam targets
  • reverse Turing tests
    • Currently implemented in some cases.
  • Implementing the semi-protectionW function [DONE - this option is now available to admins], to use when existing, legitimate pages become repeat targets for negative behavior of any kind. For technical details, see:

Extensions[edit | edit source]

Patterns[edit | edit source]

Patterns of spam (e.g. particular forms of url, HTML markup, or words) can be noted on the patterns subpage. This can then be used to tighten our spam url blacklist and AbuseFilter settings.

Patterns in pagenames can be blocked too - admins can edit these patterns at MediaWiki:Titleblacklist.

See also[edit | edit source]

Interwiki links[edit | edit source]

Retrieved from "https://www.appropedia.org/w/index.php?title=Appropedia:Anti-spam_and_anti-vandalism&oldid=463994"

Discussion[View | Edit]

For old comments see the Archive.

RE: Suggestions[edit source]

I do not think we should ban page creation by new accounts. On wikipedia that makes sense, but on appropedia, I am sure that we will have some readers who never sign up until they are ready to create a page based on their project. Unlike an encyclopedia, many of our community will have specific interest and expertise that may not have a corresponding page (even more true since we are still only a few thousand pages big). I think the main next step for spam abatement are:

  1. Install and customize a simple Reverse Turing test.
    • Non-logged in users must solve a simple addition problem to comit an edit.
    • To create a username a user must solve a simple addition problem.
      • We can also set it up so that only when entering a URL is a Reverse Turing test administered.
  2. Consider installing a blacklist extension that prevents edits that contain certain spam URLs, or spam patterns in a URL, as listed in a blacklist.
  3. Much later consider http://meta.wikimedia.org/wiki/Talk:Bad_Behavior_extension
    • This extension seems to have many counterindications

See http://web.archive.org/web/20160806051151/http://wiki.evernex.com/index.php?title=Blocking_Spam_in_Mediawiki for a much more detailed and clear approach to spam abatement. The plan laid out there is very sound and would work for Appropedia, with the following exceptions:

  1. I think we should avoid implementing Bad_Behavior as it may interfere with submission, especially from more spam-ridden computers (often the case in older internet cafes).
  2. We may consider adapting the ConfirmEdit Reverse Turing test to the specifications I listed above.

--Lonny 09:53, 17 April 2007 (PDT)

Email check for new registrations[edit source]

I found this suggestion that catches and stops some spam registrations.

Require a valid email address of at least 7 characters long, and block some spam-generating domains: 

vi /html/wiki/includes/SpecialUserlogin.php

In function addNewAccountInternal just add the additional "or" statements:

if ( ( strlen(trim($this->mEmail)) < 7 )
or preg_match ("/@mail.ru$/", $this->mEmail)
or preg_match ("/@list.ru$/", $this->mEmail)
or ! preg_match ("/^[a-z0-9._-]+@[a-z0-9.-]+$/i", $this->mEmail)) ) {
$this->mainLoginForm( wfMsg( 'noemail', $this->mEmail ) );
return;
}

The other option is for registrations to be done through filling out a form, and then approved manually. This is possible (and is done on Greenlivingpedia) but this could be good in the meantime, or as one of the measures to use if we want to keep registrations more open. --Chriswaterguy 23:11, 22 January 2012 (PST)

Add topic
Cookies help us deliver our services. By using our services, you agree to our use of cookies.