Wednesday, October 24th, 2007

Preventing spam with drag and drop

Category: Examples, JavaScript, Library

I just saw a fun little solution to spam prevention that will truly annoy your users. The drop comment solution uses jQuery and its drag and drop support to require that you move your comment over to the drop zone before the comment is saved.

I also recently talked about how Passpack lets you click on a box to prove you are not a bot. How much nicer is that that typing in some letters that you can’t read. Imagine it on the iPhone where you can just touch the right icon.

jQuery Comment Spam

Posted by Dion Almaer at 8:52 am
35 Comments

++---
2.9 rating from 56 votes

35 Comments »

Comments feed TrackBack URI

Do people not get the point of what a captcha actually does? It tries to prevent automated submissions by making a human do something that a machine can not.

This does NOTHING but annoy the human. If you want to automate the process you just look at the code and write code that does what it does when the comment is dropped on the box.

Comment by Mark Kahn — October 24, 2007

Awesome! One problem I had it with it that should be fairly easy to fix is that the first few times I dropped the box the event did not fire. It took me few attempts to work out it will only work if the top right hand corner is in the drop zone.

Comment by Chris O'Brien — October 24, 2007

Genius. That would prevent comment spam for roughly 7 minutes

Comment by Jamie — October 24, 2007

what a horrible use of jqeury

Comment by im sad — October 24, 2007

I would think that three (small, randomly named) images below the form and a simple instruction like “click on the orange kitten to submit, any other image to cancel” would be just as effective and less annoying. A human could identify visually which image was the proper one; spambots would cause the form to be cleared once they chose the wrong item.

I applaud the developer for thinking outside the box (no pun intended) but this doesn’t seem to be much of an improvement over the CAPTCHA solutions now.

Comment by Cal Jacobson — October 24, 2007

Great, make it a little less accessible…

Comment by The Hater — October 24, 2007

I am surprised that Ajaxian doesn’t get more spam. They ask the exact same 5 questions at the bottom. X stands for XML.

I recently switched to the HashCash plugin for wordpress.
http://wordpress-plugins.feifei.us/hashcash/

My spam has dropped to nearly zero, with only one false positive, which was very easy to notice and fix.

Comment by Glen Lipka — October 24, 2007

It’s not a real great idea if talking about accessibility but .. it’s nice to see how people are active to show such imagination to fight againts spam.

Keek going !

Comment by Nicolas BUI — October 24, 2007

Bad idea!

No iPhone, iPod Touch user or other user with a mobile device will be able to post comments.

Comment by AndiSkater — October 24, 2007

It’s much better to use a simple question. Like “2+2= ..” or “Two plus two is equal:” or “type ‘blue’ here”.. It’s acessible and no robot can do that (the questions would be random)..
[now i’ve seen that u use this questions here.. :)]

Comment by Rochester — October 24, 2007

Good point, AndiSkater, on the lack of support for some mobile devices and anyone using any form of screen reader, as others have mentioned. The most accessible solution I’ve found is to ask someone to answer a addition or subtraction problem. You can randomly generate numbers from 1 to 10 to be added or subtracted, and randomly select the operator. Then, just store the original question along with the answer provided by the visitor when you send the form out to the server and you can verify said answer.

If anyone is aware of a system that could see “7-8=” and correctly respond, I’d love to hear about it. The system seems to be working well for me so far (no spam coming from those locations where I’ve used this technique).

Comment by Dashifen — October 24, 2007

The most blatently obvious problem with this is that there is no server side validation. Nobody cares about what happens on the client side if the server doesn’t know about it. Here’s the deal. Server must tell something to the client, client must use that to do something the server can validate was done. There’s more to it, but until you get the basics….

Comment by vance Dubberly — October 24, 2007

Dashifen –

The problem with a numerical system like that is it is VERY easy to get around if it’s a constant format.

“7-8=”. Using simply javascript, eval(“7-8”) and get -1. Eval “9+3” and get 12.

Even replacing that with text, “seven minus eight”, it’s very simple to just replace “seven” with 7 and then eval “7-8” again.

Graphical captchas work because OCR technology still sucks compared to what a human can make out. Captcha’s like ajaxian’s work because questions like “What four letter word starting with ‘A’ is the topic of this blog?” aren’t formula that a computer can do (although as pointed out ajaxian only has like 5 questions). The other good type of relatively new captchas are image captchas “click on the bird”. As long as your images aren’t named “bird.jpg”, a computer can’t really do this.

Comment by Mark Kahn — October 24, 2007

Well i “know” the creator of this plugin. He does not call himself a coder, in fact, that is what he wrote in the message on the jQuery-UI group. It is just a proof of concept and to be honest, i like this better then a Capthca

Comment by Gilles — October 24, 2007

Gilles, thank you.

I’ve made this example just as a concept, not as a solution. It’s basically about thinking outside of the box. This might not work, but maybe it will inspire someone to look at the problem from a different angle.
Spam is killing the internet and it doesn’t hurt to think about possible solutions to get rid of it.

Hmm, interesting. The spam question below is asking me: ‘What three letter acronym is what we use to style web pages?’
Suppose I don’t know the answer, then what?

Comment by Gavin — October 24, 2007

On accessibility and server side validation – sure, ok, agreed.

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!

Comment by Tara Kelly (PassPack) — October 24, 2007

this does nothing, spam bots attack the http request that posts the comment. spam bots dont have to deal with DOM or javascript, they just make the call the browser ends up calling.

Comment by gene — October 24, 2007

I wrote a 100 line captcha using JSP and it rocks. Check it out at http://www.jroller.com/mlconnor

Comment by Michael Connor — October 24, 2007

Who cares how secure it is… all that one has to do to stop spam is make it a little more difficult for the spammer/bot and ta-da, they move on to the next mark.

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.

Comment by NullDaddy — October 24, 2007

Doesn’t akismet render these solutions obsolete?

Comment by jo — October 24, 2007

Besides not actually preventing spam, this would stop you from being able to tab through the form and submit it with just the keyboard.

Comment by Rick — October 24, 2007

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.

Comment by Trevor — October 24, 2007

this doesn’t work, because it doesn’t change the server API. The captcha works because the server has a key, it’s served encrypted in the image, and the only way to get it back is by reading the image.

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.

Comment by theKM — October 25, 2007

it’s not an accessibility issue… it just doesn’t provide the security that captcha’s are designed to do.

Comment by theKM — October 25, 2007

@Michael Connor
Here’s a video about how to create an Ajax CAPTCHA in 5 minutes and 55 seconds for those interested (.Net, Gaia)
Now let’s see if the ajaxian spam system catches THIS comment as a spam comment… ;)

Comment by Thomas Hansen — October 25, 2007

Oh, yea, sorry forgot to post the actual VIDEO… :S
http://ajaxwidgets.com/Blogs/thomas/create_an_ajax_captcha_control.bb

Comment by Thomas Hansen — October 25, 2007

@Rick: It is just a Proof of Concept (POC). It is not a solution for your problems.
@Trevor: Amen
@theKM: See my comment at Rick. You could send an XML request after dropping “the box” to verify something etc.

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

Comment by Gilles — October 25, 2007

I think the best spam prevention is the type used on ajaxian.com. Text based spam filters are accessible to people with screen readers or color blindness, and 99.9% of web developers know the “three letter acronym of what is used to style web pages”… while 99.9% of bots don’t.

Comment by Will Peavy — October 25, 2007

@ Will: I agree, but isn’t it just a matter of time before spammers tackle that too? I mean, if you have stuff like chatbots that have a database with all possible answers to all possible questions, wouldn’t it be just as easy to do the same to answer ajaxian-style captchas?

Comment by Gavin — October 25, 2007

I liked the suggestion from a few weeks back – include an additional input field in the comment submission form, and hide it using CSS so that the user doesn’t even see it.

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.

Comment by Chris Korhonen — October 25, 2007

The thing wrong with that solution (the one posed) is that it isn’t performing any real connection in the background; that’d be the easiest place to exploit. Yes, I understand that it’s a proof of concept too.

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.

Comment by Joe — October 25, 2007

@Joe
Spam bots just speak http like your browser does. If you have the browser do something automatically and send the result in the form post then the spam bot will learn to fake it and send the same values in the form post. CAPTCHAs and questions generally work because humans are needed to provide additional input. If you take humans out of the mix then all you are left with are machines. Since machines can easily emulate other machines you are left with nothing.

Comment by Sam C — October 26, 2007

a true sad way of problem solving.
it is important to keep the user happy and the experience smooth. even the simple question style of spam blocking can annoy some user (trust me, i’ve read some ppl’s comments on that).

Comment by Simon Jia — October 26, 2007

@ Simon: What’s sad is your comment. Even if the proposed concept is bad, at least there’s people trying to solve the problem.

Comment by Gavin — October 26, 2007

Working hard to make the net less accessible? Spam prevention solutions should probably be intelligence and/or parameter “check and balance” based, and preferably transparent. Interface complexity (or in this case obfuscation) without demand or purpose is just backwards.

/* 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.

Comment by advanced — October 28, 2007

Leave a comment

You must be logged in to post a comment.