Appropedia:CAPTCHA

CAPTCHAs are installed with mw:Extension:ConfirmEdit. The ConfirmEdit extension enables a very simple text Captcha that will probably catch most bots (and has worked so far).

The FancyCaptcha addon extension creates more complex image captchas, if needed (but this raises #Accessibility issues).

Configuration[edit | edit source]

Explanation and defaults taken from mw:Extension:ConfirmEdit.

Suggestions for Appropedia are intended to stop vandal and nonsense bots:

ConfirmEdit introduces a ['skipcaptcha'] for wgGroupPermissions. This is useful for groups that shouldn't see captchas ever. (Bots and Sysops) (For Appropedia, reg users also shouldn't see them; anons should always see them.)

Defaults from ConfirmEdit.php:

$wgGroupPermissions['*']['skipcaptcha'] = false; //all users (including anons)
$wgGroupPermissions['user']['skipcaptcha'] = false;
$wgGroupPermissions['autoconfirmed']['skipcaptcha'] = false;
$wgGroupPermissions['bot']['skipcaptcha'] = true; // registered bots
$wgGroupPermissions['sysop']['skipcaptcha'] = true;

For explanations of user, autoconfirmed etc, see mw:Help:User rights.

Suggested settings for Appropedia - everyone except anons skips CAPTCHA: New ConfirmEdit.php settings:

$wgGroupPermissions['*']['skipcaptcha'] = false; //all users (including anons)
$wgGroupPermissions['user']['skipcaptcha'] = true;
$wgGroupPermissions['autoconfirmed']['skipcaptcha'] = true;
$wgGroupPermissions['bot']['skipcaptcha'] = true; // registered bots
$wgGroupPermissions['sysop']['skipcaptcha'] = true;

Triggers[edit | edit source]

There are four triggers that can generate a captcha and allow for different situations.

$wgCaptchaTriggers['edit'] = true; -- Would check on every edit
$wgCaptchaTriggers['create'] = true; -- Check on page creation.
$wgCaptchaTriggers['addurl'] = true; -- Check on edits that add URLs
$wgCaptchaTriggers['createaccount'] = true; -- Check on account creation.
$wgCaptchaTriggers['badlogin'] = true; -- Check after a failed log-in attempt.

Default triggers from ConfirmEdit.php:

$wgCaptchaTriggers['edit'] = false;
$wgCaptchaTriggers['create'] = false;
$wgCaptchaTriggers['addurl'] = true;
$wgCaptchaTriggers['createaccount'] = true;
$wgCaptchaTriggers['badlogin'] = true;

Suggested triggers for Appropedia - note that any action is prone to vandalism etc, so they are all set to "true":

$wgCaptchaTriggers['edit'] = true;
$wgCaptchaTriggers['create'] = true;
$wgCaptchaTriggers['addurl'] = true;
$wgCaptchaTriggers['createaccount'] = true;
$wgCaptchaTriggers['badlogin'] = true;

Other ideas[edit | edit source]

Hopefully we can set it so that once a user had passed CAPTCHA, they didn't have to do it again for a period (e.g. a week? we could experiment).

Accessibility[edit | edit source]

From Wikipedia:CAPTCHA:

Because CAPTCHAs rely on perception, users unable to perceive a CAPTCHA (for example, due to a disability or because it is difficult to read) will be unable to perform the task protected by a CAPTCHA. As such, sites implementing CAPTCHAs should provide an audio version of the CAPTCHA in addition to the visual method. The official CAPTCHA site recommends providing an audio CAPTCHA for accessibility reasons.

This is currently not a problem for Appropedia as we use a text-based simple maths CAPTCHA. Wikipedia again, under the heading Attempts at more accessible CAPTCHAs:

Even an audio and visual CAPTCHA will require manual intervention for some users, such as those who are both deaf and blind. There have been various attempts at creating CAPTCHAs that are more accessible. Attempts include the use of JavaScript, mathematical questions ("what is 1+1"), or "common sense" questions ("what color is the sky"). These attempts violate one or both of the principles of CAPTCHAs: either they cannot be automatically generated or they can be easily cracked given the state of artificial intelligence. As such, the only security these CAPTCHAs provide is security through obscurity; an attacker is unlikely to have encountered the formulation of the CAPTCHA in question, and unlikely to find it worth the time spending resources to break the CAPTCHA of a small site.

For now we should be safe, with good accessibility. But thinking ahead,

Due to the lack of security provided by text based CAPTCHAs, most sites choose to use an audio and visual CAPTCHA as a way of balancing accessibility and security. Often, email support is used to manually provide access to users who are unable to solve a CAPTCHA.

Audio CAPTCHA plugins are available, and options will no doubt improve.

Alternative simple CAPTCHAs[edit | edit source]

ask to simply enter some text - e.g. http://web.archive.org/web/20160428205527/http://c2.com/cgi/wiki?edit=WysiwygWiki - in theory it's not too hard for bots to overcome, but not much incentive as not many sites use it.