+1 for disabling CAPTCHs (at least in signup form).
Anyway, sysops already have enougth tools for treating abuse by spam bots
using AbuseFilter (e.g with rate filter).
On Sat, Nov 8, 2014 at 12:19 AM, MZMcBride <z(a)mzmcbride.com> wrote:
Tim Starling wrote:
On 07/11/14 19:17, svetlana wrote:
I would suggest to ask on a village pump and
alter the configuration
per local consencus.
We tried that before and the answer was "OMG no", even though nobody
bothered to look at the logs. It turns out that the captcha we were
using was broken from the outset -- trivially solvable with OCR -- but
apparently that didn't affect anyone's opinion of whether or not it
should be enabled.
According to reports from non-WMF users of ConfirmEdit, FancyCaptcha
has little effect on spam rate. See the table here for a summary:
Anyway, sure, let's ask on some more village pumps.
I think that's unfair.
Wikis have a serious spam problem. People associate CAPTCHAs with spam
prevention. On the English Wikipedia, one of the actions that results in
the user being required to successfully enter a CAPTCHA is adding an(y?)
external link to a page as a newly registered user. This, of course, in
addition to the CAPTCHA presented when registering an account (consider
that many new account creations only come about as the result of the
requirement for an account to make a new page on the English Wikipedia).
Why not disable the extension for a week and see what happens? If you're
wrong and there's a marked increase in wiki spam (account creations and
edits), then you can help devise a better solution than a CAPTCHA.
CAPTCHAs are clearly not a sustainable fix to the underlying problems they
were implemented to address, or so I think you're saying. If you're right
and the CAPTCHA is simply ineffective and unneeded, we've eliminated some
code from production and we can move on. In other words: what exactly is
stopping you from disabling the extension?
Wikitech-l mailing list