#39688 [NEW]: CAPTCHA threshold is way too high

From: codeslinger at compsalot dot com Operating system: Any PHP version: Irrelevant PHP Bug Type: Website problem Bug description: CAPTCHA threshold is way too high Description: ------------ There are multiple problems of the CAPTCHA system that require a substantial redesign. The CAPTCHA image is far too difficult to interpret. If cookies are not enabled the CAPTCHA image is not visible. The current implementation is in violation of the "Americans with Disabilities Act". etc. Reproduce code: --------------- in bug http://bugs.php.net/bug.php?id=33247: wez@php.net says: "Look, it was illegible about 45% of the time. There certainly is a problem; it rejected my entries twice tonight (out of 6 page loads)--and the text I entered did match what appeared to be on the captcha." That comment was from over a year ago, today my experience was much worse, it took me at least six tries to get one success. That bug (33247) was closed but the problem is not fixed yet, or perhaps it has regressed to a previous bad design? (since I don't appear to be able to reactivate it, I am entering this as new bug). It was exceedingly frustrating to get past the CAPTCHA earlier today while entering a bug/Feature Request, and required many many attempts. I have experienced a lot of these CAPTCHAs on different web sites and this one is by far the worst I have ever had to deal with. I looked at it carefully and was sure that I was entering the correct text, and again and again it was rejected. And I am not an unsophisticated user. It's not even clear how many letters are needed, mostly it seems to be four letters, but then when nothing else worked I ignored the squiggle that looked very much like the letter "L" and entered only three letters, which to my surprise was accepted. Now how the heck am I supposed to tell the difference between an "L" and a squiggle, when the system is in fact designed to make "L"'s look like squiggle's? And especially when I am expecting that it wants four letters when in fact it only wanted three that time, but later it did want four letters. Yes, the problem with spammers is a very bad one, and I can certainly appreciate that you are feeling a little bit burned out on the endless battle against both spammers and poor bug entries. But since when does that justify changing the website design to be intensely user hostile? There are quite a few bugs in the database, all saying the same thing, this CAPTCHA is unusable. And all receiving the same response "Bogus" or "Irrelevant"; with the exception of this one lone bug which is claimed to be fixed, but most certainly it is not. ----------------------- in bug: http://bugs.php.net/bug.php?id=33247 wez says: "The lines are too overbearing to the point where I'm unsure if I should be entering U's or J's." I agree with this assessment and would would further point out that, the way that the colors are used is incompatible with people who are color blind. With regard to the oft repeated and cavalier advice that a person only needs to "refresh" their browser in order to get a new CAPTCHA; this advice ignores the fact that a browser "refresh" will throw away all of the form data which has been entered. Therefore "refresh" is not a valid action; at least not if you have any concern at all for the effort of the people who are trying to use your system. And then there is the tedious issue that being validated once is not enough, if you have made a mistake which needs to be corrected such as trying to specify "Irrelevant" for the build version, then you must pass the CAPTCHA all over again. I would expect that once I have successfully proven that I am a human, that I would be allowed to remain a human :-) for at least 10 minutes before being again challenged. ---------------------------------- in bug: http://bugs.php.net/bug.php?id=33247 dufuz@php.net says: "I see no reason to lower the fuzziness when you can get a very readable captcha [by doing retrys]" I think there is a fundamental misunderstanding here of what the goal is for a CAPTCHA program. The goal should be to prevent spammers from using automated methods to post messages. Nothing more and nothing less. The program therefore needs to be designed such that it achieves the goal of preventing spammers, while at the same time placing the minimal burden necessary upon the legitimate users of the system. This CAPTCHA design does not meet that need, it does not fulfill that requirement; this CAPTCHA as currently implemented places a huge burden upon the legitimate users. The question which should be asked when considering the design of this CAPTCHA program is: Has it been demonstrated that any spammers are using any type of pattern recognition system whatsoever? And if so (which it hasn't been), what is the *minimum* level of complexity/fuzziness of the image that is needed to ensure that automated spammers do not gain access, while at the same time ensuring ease of access for the legitimate user? Yes it is true, that bright people at MIT and other places have created image recognition systems which are truly quite remarkable in their abilities. But as a practical matter, no spammer that I am aware of, has deployed any such system and furthermore the compute resources required to do this on a large-scale are prohibitive. On the other hand, what I have seen instead, in one specific instance; is where a spammer had hired a crew of -- undoubtably low-paid, barely literate workers, to sit there in front of a computer and enter comment spam into a forum. (see also www.amazon.com's experiment with the "Mechanical Turk"). So you see, you really cannot win this battle by CAPTCHA alone no matter how difficult you make it. But you can certainly generate a lot of ill will and alienation of potential contributors, in the process of trying to protect your web site. in bug: http://bugs.php.net/bug.php?id=33449 sniper@php.net says: "This way we get only reports which are real reports. :)" There are better ways to achieve this result, ways that do not involve alienating people. If it is such a huge problem, why not switch to a fully validated registration system? Currently user notes posted to the manual pages go through a moderation process before becoming visible; clearly this takes extra work, but it is what PHP.net has decided to do. Since the bugs must be reviewed anyway, it does not involve any extra work at all to subject them to a similar moderation process. If the goal is to prequalify the person entering the bug; perhaps a much more useful approach, would be to ask some knowledge based questions about the PHP language, this at least would be a relevant criteria and would probably also succeed in eliminating the semi-literate "Mechanical Turk". But if you are going to do this, you ought to do it before you allow people to type in the bug report. It is very discourteous to allow someone to go to all the work of entering a bug report and then reject that entry because they did not pass some test. The test should be given first. ---------------------------------- And then there is the issue of blind people. Standards compliant CAPTCHAs support audio or use a simple question and answer format such as "What is two plus 3?". Making public websites be accessible, isn't just something that is nice to do, it also happens to be the law! And if you wish to be excused from compliance then you had better be prepared with solid justifications for your design decisions (exceptions are made but must be justifiable). See the "Americans with Disabilities Act" for more information. In bug http://bugs.php.net/bug.php?id=37104 David Spector Has generously offered to assist you with this task. And he appears to be well-qualified to help you with this. Such offers of help should not be disregarded casually. David Spector Webmaster, Massachusetts ***Alliance of Visually Impaired*** Students -------------------------------- And then there is the mystery of various people not being able to view the CAPTCHA image on their browser, see for instance these bugs: (which were marked bogus or otherwise ignored) http://bugs.php.net/bug.php?id=32831 http://bugs.php.net/bug.php?id=36717 http://bugs.php.net/bug.php?id=33101 And then in this bug (which has also been ignored AFAICS) the answer to the mystery is revealed: http://bugs.php.net/bug.php?id=37170 sd at sven-drieling dot de says: "CAPTCHAs requires enabled cookies to report bugs but no warning is shown if cookies are disabled. Without cookies the CAPTCHA image is empty." -------------------------------- http://bugs.php.net/bug.php?id=33247 As a separate issue: Other people/bugs have commented on the fact that you are forced to specify a PHP build number. And they were told that this was not the case, however when I tried to enter a bug/Feature Request, this is exactly what I experienced. Although there is a build option to specify "Irrelevant", when you select this value, it is in fact rejected and you are then forced to choose a different value and you must once again fight with the CAPTCHA. ---------------------------------- Expected result: ---------------- All in all, PHP is a fabulous language, and the web site is exceedingly well done. But this problem with CAPTCHA is pretty big in its potential to alienate. And it puts up a substantial barrier to people who are trying to make a contribution. The excellence of the PHP language and the PHP web site, provide ample proof that you people know a lot about good design. But this CAPTCHA program, as currently implemented, is the antithesis of good design. Actual result: -------------- Endless battles with CAPTCHA verification I'm looking at the CAPTCHA for this bug entry right now and I cannot tell if that letter is supposed to be a mangled "I" or a "T". or should I be ignoring that line and entering the "J" which is merged with the "G" ? I shall make a guess and see what happens, but it is totally ambiguous and not at all reasonable. I have saved a copy of this picture, if this bug supports attachments I will add it. ...................... Well, I guessed HIVG and was rejected: trying again. Guessing NHN but it probably is NTHN Trying MABY - this at least looks readable ..... Oh yipee, it liked that, but now I get to do it again. To confirm my report. ..... Trying UVPV -- but that last V could also be a truncated Y or is it a lower case "v" is this thing case sensitive? with rare exceptions all of the letters I have seen from it appear to be upper case.... ...... Trying YJUD -- but is that a lower case "u"? can't tell, it is slightly smaller than the "D" but not by much. -- Edit bug report at http://bugs.php.net/?id=39688&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39688&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39688&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39688&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39688&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39688&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39688&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=39688&r=needscript Try newer version: http://bugs.php.net/fix.php?id=39688&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39688&r=support Expected behavior: http://bugs.php.net/fix.php?id=39688&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39688&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39688&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39688&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39688&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39688&r=dst IIS Stability: http://bugs.php.net/fix.php?id=39688&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39688&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39688&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39688&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=39688&r=mysqlcfg