Those checkbox and honeypot captchas look like junk to me.
Firstly the checkbox captcha. It relies entirely on the assumption that
spambots don't have JavaScript. It also assumes that spambots won't simply
get wise and throw a few regexp tests to figure out when the plugin is
sitting on the page inserting a form element. If people actually start
using checkbox captchas they will inevitably become useless.
Additionally it imposes the requirement that the client has JavaScript
enabled simply to make an edit. This is something we consider unacceptable.
honeypot-captchas... yeah, we already have that:
https://www.mediawiki.org/wiki/Extension:SimpleAntiSpam
If it weren't for the fact that it's useless for login-only and private
wikis I'd bake it right into core.
honeypot-captchas aren't actually captchas. As a testament to that a real
captcha and SimpleAntiSpam can be installed at the same time.
And I do recommend you do that. SimpleAntiSpam trips up the trivial bots
while the captcha deals with the non-trivial link inserting bots.
But that's all they do. Beyond the most worthless of spambots,
honeypot-captchas have absolutely no value. If a bot is capable of
breaking any normal captcha it is already sophisticated enough that a
honeypot-captcha will do absolutely nothing.
Need I remind people we have bots walking around that know how to register
and login to MediaWiki. Know how to deal with image captchas. Know how to
wait for autoconfirmed status. Know how to confirm an AbuseFilter warning
page. And even know how to upload an image and use it in wikitext.
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
On Mon, 30 Jul 2012 06:28:13 -0700, Pau Giner <pgi...@wikimedia.org> wrote:
From the UX perspective, a captcha is always an obstacle for the
interaction flow.
Reducing the complexity of user interaction when solving the captcha can
benefit all kinds of users but also solve problems for non-English
speakers.
Checkbox and honeypot-based captchas avoid most of the problems of
text-based captchas since interaction is simplified to the minimum for
the
user:
http://uxmovement.com/forms/captchas-vs-spambots-why-the-checkbox-captcha-wins/
Simple questions where the user can select an answer (not type) will
solve
some of the input-related issues for non-English speakers.
These questions can be of different kinds (e.g., "Which one does not
belong
to the group: Red, Green, Skateboard, Blue?", "Is fire hot or cold?") and
they can be based on text or image selection.
An example of image-based captcha is available at
http://www.picatcha.com/captcha/
Tagging media can be also used as a captcha. Google has been
experimenting
with asking users to tag videos as a captcha:
http://cups.cs.cmu.edu/soups/2009/proceedings/a14-kleuver.pdf [PDF]
In any case, some experimentation would be required to determine any of
the
above approaches (or combination of several) provides an appropriate
security-usability balance for the specific needs of the Wikipedia.
Pau
On Sat, Jul 28, 2012 at 8:29 PM, Platonides <platoni...@gmail.com> wrote:
On 28/07/12 16:55, Everton Zanella Alvarenga wrote:
> In the conclusion:
>
> "Contrary to the common belief, text-based CAPTCHAs can be difficult
> for foreigners."
>
> It is worth reading and likely the same for references there in. The
> first sentence is similar to what I have experience in 3 classes. And
> people begin to get anxious and usually say "If I type wrongly again,
> I'll give up". I've seen 3 students saying this to me.
>
> Even if hypothetically had in an experiment that only 1% of foreigners
> will face difficulties with CAPTCHA in a foreign language (I bet it's
> much more from real life experience), how much users this would
> represent in one of the most accessed sites in the world?
>
> Tom
There are two types of "foreigners" here:
- One are speakers of another language written in latin1 (such as
Brazilians).
- Another are those who use a diferent writing script, such as Russians
or Greeks.
In the first case, they should have little problem. Native speakers of
the language used for the wordlist have an extra help, because they are
more likely to recognise the words and it can also help them perform
error recovery.
It would be nice to provide a captcha with a native wordlist, but by
limiting to ascii characters, it can get pretty universal.
Distortion where a letter looks like a different one is still
problematic. Even people with English knowledge can have trouble with
it, so being a native speaker doesn't magically make you invulnerable to
captcha errors.
On 16th July of 2007 Arnomane reported a case where "o" distortion made
it look like an "a", on August I reported another where an "s" looked
like a "g".
I expect that using random characters would make it worse, though.
People with other scripts are a different matter.
* They may not be able to recognise the latin characters.
* You may be forcing them to change the language layouts for solving the
captcha.
* Foreign visitors may not be able to pass your captcha.
** Lack of appropiate keyboard layout.
** Unable to differenciate the characters (you want me to differenciate
ت and ث distorted in a noisy background?)
** No fonts installed for viewing the characters (eg. 𓀝 vs 𓀞) such as
if you were trying to browse the in character map the script characters
of the language (potentially hundreds!) looking for a visual match.
Yet, there are reports such as this by Liangent (native Chinese speaker)
on this list on 5th February 2011:
> I hate the case that I'm asked with a Chinese captcha when I'm surfing
> some Chinese websites without IME available.
>
> Besides I don't prefer Chinese captchas personally because Chinese
> characters usually require more key hits.
At least for those languages I think we would need a switch to get a
captcha in the different "language".
We should also add the "button to get a new captcha" (bug 14230), which
should help when you get the wrong captcha.
And I think we should also add a "Problems solving the captcha? Mail us"
link for those cases when people can't pass the captcha.
Not that it would solve their problems, but it would at least provide a
way to lighten their frustration.
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l