problem setting up a feedback form on Web page

[virtualmike]

Second, there are other domains where CAPTCHAs provide an invaluable barrier against automation. Take ticketmaster for example.

There are groups of people who get paid less than $1 per 1000 CAPCHAs to do nothing but type in the text associated with the images.

Scenario? Script kiddie wants to hammer at a web site. Web site has a CAPTCHA. Script kiddie builds his script, which sends the CAPTCHA to the minion (usually working in a third-world country, where $1 is a lot of money). Minion types his interpretation of the image, it goes back to the script, which enters it to the CAPTCHA.

Barrier passed.

[kbenson]

Again, it's not about making it impossible, just about making it a little harder. In the TicketMaster case, time to decode the CAPTCHA can greatly affect tickets received for new sales or popular events. Offloading decoding to a third party introduces a small but important delay, not to mention the development of the system introduces an up-front cost that deters some outright.

[virtualmike]

It deters some, but not all. Similar to the picket fence analogy... if someone thinks the reward is worth it, he will figure a way to get around it.

[jnurthen]

Indeed some don't adversely affect the USER, but that just means the adverse effect is shunted somewhere else, either to the admin, or the the server which has to do extra work, or missed email because of a false positives.

If it can be (and on MOST sites which aren't under heavy attack it can), Isn't extra work for the admin/server exactly where the load should be placed? Our users shouldn't have to put up with proving they are human through a process which has so many flaws as the current CAPTCHAs which are in use.

[jnurthen]

Again, it's not about making it impossible, just about making it a little harder. In the TicketMaster case, time to decode the CAPTCHA can greatly affect tickets received for new sales or popular events. Offloading decoding to a third party introduces a small but important delay, not to mention the development of the system introduces an up-front cost that deters some outright.

I'd wager that the delay for someone to solve a CAPTCHA who is being paid to do so is less than the delay for a blind user who has to listen to the audio CAPTCHA equivalent.

[kbenson]

If it can be (and on MOST sites which aren't under heavy attack it can), Isn't extra work for the admin/server exactly where the load should be placed? Our users shouldn't have to put up with proving they are human through a process which has so many flaws as the current CAPTCHAs which are in use.

it really depends (which is my whole point). If it requires regular upkeep (such as an IP access list that blocks Asia, which may change in the future), then if the admin forgets to keep it up to date, it loses effectiveness. If it's automated, the automation may fail (the service providing the data may stop, or mess up), or return bad data, leading to many false positives.

I'll posit that the willingness of users to put up with extra security mechanisms that put the load on them is ALSO proportional to the usefulness of the service. An annoying captcha on a free service may annoy you enough to stop using it, but if you are already willing to pay $10 a month for that service, I doubt a CAPTCHA is a deal breaker unless it just plain doesn't allow you in. But that's either a site problem or an accessibility problem, and we've covered that ground.

I'd wager that the delay for someone to solve a CAPTCHA who is being paid to do so is less than the delay for a blind user who has to listen to the audio CAPTCHA equivalent.

True. But the damage caused by automated access would (and DOES) outweigh the accessibility concerns. It's not a great situation for any company to be in, but unfortunately that's the reality.

[jnurthen]

I'll posit that the willingness of users to put up with extra security mechanisms that put the load on them is ALSO proportional to the usefulness of the service. An annoying captcha on a free service may annoy you enough to stop using it, but if you are already willing to pay $10 a month for that service, I doubt a CAPTCHA is a deal breaker unless it just plain doesn't allow you in. But that's either a site problem or an accessibility problem, and we've covered that ground.

I would hope that any service for which the user is paying does not need a CAPTCHA. There should never be a need to make sure that an authenticated user is real - simply challenge them for their password in such a situation.

This is about equal access. The web is a great equalizer for many PWD. Things like CAPTCHAs can be insurmountable obstacles.

I'm not arguing that some type of CAPTCHA is never necessary - but 99% of the time they are used in inappropriate situations where some other simple techniques would prove equally effective in preventing abuse such as on blogs / chat forums etc.
By all means challenge a user with a CAPTCHA if they are suspicious (for example if they try to submit a form too quickly after landing on the page, or if they don't have scripting enabled in their useragent) but I don't think we should encourage lazy behaviour on the part of web-admins if this lazy behaviour excludes people due to various disabilities.

[kbenson]

I would hope that any service for which the user is paying does not need a CAPTCHA. There should never be a need to make sure that an authenticated user is real - simply challenge them for their password in such a situation.

Unfortunately there are many cases where a resource needs to be protected from the already limited audience of paying customers. Online medical journals, newspapers, and other content generators/portals that arbitrate access to easily copied material. Anywhere the primary detractor against piracy on a mass scale is the manual labor involved.

This is about equal access. The web is a great equalizer for many PWD. Things like CAPTCHAs can be insurmountable obstacles.

So are things such as geographic IP blocks. Undoubtedly there's some false positives in doing that, and legitimate users may find themselves with a similar insurmountable obstacle.

I think CAPTCHAs get a lot more blame for this than other techniques because it's generally obvious when you've been blocked because of a CAPTCHA, and it may not be obvious exactly why when blocked for other reasons.

As annoying as CAPTCHAs are, I find it much more annoying to try to use a site and be blocked for no known reason. Worse yet when it's not obvious you've been blocked on purpose, leaving it to you to guess if it's a transient failure or long term problem. That just wastes everyone's time.

I'm not arguing that some type of CAPTCHA is never necessary - but 99% of the time they are used in inappropriate situations where some other simple techniques would prove equally effective in preventing abuse such as on blogs / chat forums etc.
By all means challenge a user with a CAPTCHA if they are suspicious (for example if they try to submit a form too quickly after landing on the page, or if they don't have scripting enabled in their useragent) but I don't think we should encourage lazy behaviour on the part of web-admins if this lazy behaviour excludes people due to various disabilities.

So we aren't really in disagreement at all.

[jnurthen]

I would hope that any service for which the user is paying does not need a CAPTCHA. There should never be a need to make sure that an authenticated user is real - simply challenge them for their password in such a situation.

Unfortunately there are many cases where a resource needs to be protected from the already limited audience of paying customers. Online medical journals, newspapers, and other content generators/portals that arbitrate access to easily copied material. Anywhere the primary detractor against piracy on a mass scale is the manual labor involved.

If this content is as valuable as you state it is then the CAPTCHA is not going to stand in the way of scraping the content using paid-for CAPTCHA solving.

This is about equal access. The web is a great equalizer for many PWD. Things like CAPTCHAs can be insurmountable obstacles.

So are things such as geographic IP blocks. Undoubtedly there's some false positives in doing that, and legitimate users may find themselves with a similar insurmountable obstacle.

I think CAPTCHAs get a lot more blame for this than other techniques because it's generally obvious when you've been blocked because of a CAPTCHA, and it may not be obvious exactly why when blocked for other reasons.

As annoying as CAPTCHAs are, I find it much more annoying to try to use a site and be blocked for no known reason. Worse yet when it's not obvious you've been blocked on purpose, leaving it to you to guess if it's a transient failure or long term problem. That just wastes everyone's time.

The difference between a geographic IP block and a CAPTCHA is that one is (potentially) discriminating against a protected class and the other is not.

I'm not arguing that some type of CAPTCHA is never necessary - but 99% of the time they are used in inappropriate situations where some other simple techniques would prove equally effective in preventing abuse such as on blogs / chat forums etc.
By all means challenge a user with a CAPTCHA if they are suspicious (for example if they try to submit a form too quickly after landing on the page, or if they don't have scripting enabled in their useragent) but I don't think we should encourage lazy behaviour on the part of web-admins if this lazy behaviour excludes people due to various disabilities.

So we aren't really in disagreement at all.

Not quite sure if you're serious or not... the smiley is a little confusing here.
I am certainly in disagreement with you. You originally suggested adding a CAPTCHA to a feedback form on a web page. I suggest that this is a really bad thing to do as you are making it really difficult for a certain class of people to provide you feedback. Added to this is the fact that the CAPTCHA could easily be replaced by many other less onerous techniques.

[kbenson]

The difference between a geographic IP block and a CAPTCHA is that one is (potentially) discriminating against a protected class and the other is not.

Should I feel worse about blocking access to a class of citizens of the most wealthy nation in the world because they have hardships beyond the comprehension of most normal citizens, or by blocking access to poor third world residents that may finally be getting access to the Internet, and thus access to global markets and information. I'm woefully under qualified to make a judgement call in either direction, and it only seems to complicate the issue more that there are whole industries dedicated to alleviating or removing obstacles for disabled individuals in America.

In any case, it's not cut and dry for me.

I'm not arguing that some type of CAPTCHA is never necessary - but 99% of the time they are used in inappropriate situations where some other simple techniques would prove equally effective in preventing abuse such as on blogs / chat forums etc.
By all means challenge a user with a CAPTCHA if they are suspicious (for example if they try to submit a form too quickly after landing on the page, or if they don't have scripting enabled in their useragent) but I don't think we should encourage lazy behaviour on the part of web-admins if this lazy behaviour excludes people due to various disabilities.

So we aren't really in disagreement at all.

Not quite sure if you're serious or not... the smiley is a little confusing here.

I'm serious in that I think we're arguing the same point from different angles, but you seem to think we aren't, and this argument has gone on for this long before finally coming to this point. I find this comical in a slightly sad manner.

I am certainly in disagreement with you. You originally suggested adding a CAPTCHA to a feedback form on a web page. I suggest that this is a really bad thing to do as you are making it really difficult for a certain class of people to provide you feedback. Added to this is the fact that the CAPTCHA could easily be replaced by many other less onerous techniques.

No, you're confusing me with another poster. I posted originally asking he use SOME method to secure his form mailer, such as cleaning posted variables, and being careful what is sent out to the user in email, if anything. Someone else mentioned using a CAPTCHA, I simple responded to what I saw as a kneejerk negative reaction to a simple tool, when all that's needed is to understand the consequences of whatever security mechanism is put in place.

To clarify again, as I attempted to do initially here, I'm only stating that I think CAPTCHAs may have use in some instances when used appropriately.