/* meander off topic */

Personally I like the honeypot solutions. The most transparent approach uses hidden form fields with default names like “url” and “website” to entice the bots into submitting spam data on a flagged query id, thus resulting in an automated IP ban (usually just a proxy block). Meanwhile the visible UI is unaffected. So far these solutions have been VERY effective at keeping the bots out even on phpBB (i.e xrumer).

/* on another note */

Most bots have a pronounced signature in the page order they visit and the lightening fast times between page accesses. IMHO, identifying and blocking particular traffic patterns would be more effective than any type of UI based scheme. It seems to me that Google uses a similar approach to pro-actively protect against worm query floods.

/* back to the point */

Regardless, I’ve seen more than a few macro bots (ghostkeys) that use recorded mouse events to yield a quick/n/easy workaround to complex navigation, honeypots, serialization and tokens.. an approach that’s light years behind the modern multisocket bot but effective none the less and likely to resurface given a continued demand.

Ajaxian’s anti-spam attempt, although not terribly great, has worked surprisingly well; I haven’t seen any spams in the posts I’ve read so.. guess it works.

I’ve tossed around the idea as using the mouse position as the authenticating aspect of the user. Most bots are automated and don’t use the mouse or keyboard (generally) so I thought if you’d watch the mouse for a bit and see “human like” movements, then a flag should be set to allow the comment.

Of course there are still things to work out and even then I’m sure it’d get bypassed but, perhaps it’s another proof of concept that I’m working on.

Spam bots will usually attempt to.. um.. spam.. text and input fields, meaning that if the ‘hidden’ text field contains any data, you can assume that message is spam.

Granted, for users of screenreaders/text browsers and the like, you cannot effectively hide the field – so just use a label to tell the user not to fill that field in. Voila…

We have an effective solution for distinguishing between humans and spam bots, which is also accessible.

Guys.. it is just a new way of looking at things..

The “drag and drop” thing is just some UI verification… the server API hasn’t verified that it’s all good. So to the spammer, it’s just as easy to implement their bots as it ever was… sniff for the server API, and mimic it.

Captcha’s work only because the server API says “guess this”, and there’s an unknown that has tom come back in through the API. With this, the script is just saying that it was run… the API had no control to start with.

Suppose I don’t know the answer, then what?

Then you’re very likely not reading Ajaxian. Human-detection questions should, to be most effective, target the site’s audience. If you really don’t know, but want to post a comment, you, as a human, have the advantage of using wikipedia or google or a good ol’ book to find out.

But I think it’s good to experiment with concepts and Ajaxian is a great place to publish proof of concepts and bounce ideas around.

Yes, and while I wish folks here would be a little more respectful when criticizing, the benefit of having a place to post proofs of concept is to get them criticized so you can make the concept effective, secure, valuable and the best it can be as a solution to real problems.

The best, most accessible, solution to the problem that I’ve found is to ask human-logic questions. This fails when users don’t speak the language the questions are written in, so if your site has a multilingual audience, another solution (image, arithmetic) might be more appropriate.

Another solution, if you’re lucky enough to be able to require Javascript, would be to leave <form> tags out of your markup and wrap your forms in the DOM. Well, until the spambots have better scripting support.

As long as you change it up you will stay ahead of the pack. If everyone is using Captcha then there is more incentive to find ways to crack it… on the other hand if everyone is using a custom solution, theres less chance of a hacker taking the time to crack it.

Think of “the club” … I’m sure its stopped a few cars from being stolen, but once its been found out how easily you can cut a steering wheel with a bolt cutter… and off comes the club. If you own a Ferrari I would hate to think you’d trust your car to this security product alone. But on the other hand if your driving a POS, who the hell cares you could leave the keys in the ignition and no one would take it.

But I think it’s good to experiment with concepts and Ajaxian is a great place to publish proof of concepts and bounce ideas around.

I’m sure someone can find a statistic on how many false starts it takes before an idea finally reaches it’s final form… nothing comes out of the box perfect.

Good experiment. Who knows, maybe it’ll spark an accessible-server-validated-super-alternative-captcha idea for someone else.

Cheers!