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.
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
pginer@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-wi...
>
>
> 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
Platonides@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.