Idea about captcha and spam bots...

[dannyb785]

Ok, so when a user visits a site with a form, with say, 5 fields. Obviously it takes a certain amount of time to fill out the form(even with autocomplete, give atleast a few seconds per field) so after a user first views a page with 5 fields, it would probably take a minimu of about 10 seconds to fill it out, right(let's say yes for the sake of argument)?

 

Now, conversely, when a spam bot fills out a form to post its spam, how long does it take to fill out? I really don't know, nor have I done any tests, but perhaps someone knows. Because if it's one of those instantaneous things(or something that only takes a second or 2 for 5 fields), would you say that they probably will out the forms rapidly(since they really don't care what form they're filling out, they just fill out whatever they need).

 

So, with the thought that spam bots fill out forms rapidly(faster than any normal user), could we put a hidden variable that is the exact second the form is displayed, and then, on submit, the current date would be recorded and if the difference is say, less than 5 seconds(or less than 2 seconds per field, perhaps), would it be safe to reasonably assume that it's spam? Does this theory have any merit?

 

 

EDIT: ok so i just realized this thread doesn't relate to captcha's, but you still get the idea

[GingerRobot]

This is basically the same approach as a token system - when the form is loaded, a token is set in a hidden field and also set as a session. When the form is submitted, these values are checked. An automated script will probably direct straight to the action of the form, so it doesn't have the token set.

 

This can quite easily be defeated with cURL. Therefore, your approach could be too. However, i guess it's an interesting approach. Any bot would have to be altered specifically for your site.

[dannyb785]

I was also thinking something along the lines of an event handled with onclick. Can a bot "click", therefore setting the onclick event? like, once the click is physically made, a value is set, and then on the processing page, check to see if the value is set. Something like that?

[GingerRobot]

I can't see how that would work. At some point, something would be sent to the server. The bot can just do that bit.

 

Aside from that, do you really want to completely block all non-javascript users?

 

 

[dannyb785]

You raise a good point(about blocking non-js users) though I would like to assume(hopefully correctly) that all or most bots have js set to be able to interact with(like, a bot is able to do an onclick event or whatever), so I could possibly assume that if the user doesnt have js enabled(by doing an easy test), then the submission would go thru(since the assumption would be that if js isn't enabled, that it's a real person).

 

Would that be wrong to assume?

[dsaba]

well javascript is a browser thing. (correct me if i'm wrong)

if the bot ran through a browser (i doubt it) it would generate browser-like behaviors like onClick and onLoad events, a bot can mimic a user-agent to pretend its accessing the page via a particular browser, but it cannot mimic javascript/browser behaviors like the clicking of buttons, unless of course it is being run through a browser

so can you generate browser-like events NOT in a browser?

 

smarter bots aren't going to necessarily post straight to the action of the form, they usually always load the form first or access it, so what's the power in a "token system"?

 

the time observation among real users is a great idea

[dannyb785]

well javascript is a browser thing. (correct me if i'm wrong)

if the bot ran through a browser (i doubt it) it would generate browser-like behaviors like onClick and onLoad events, a bot can mimic a user-agent to pretend its accessing the page via a particular browser, but it cannot mimic javascript/browser behaviors like the clicking of buttons, unless of course it is being run through a browser

so can you generate browser-like events NOT in a browser?

 

smarter bots aren't going to necessarily post straight to the action of the form, they usually always load the form first or access it, so what's the power in a "token system"?

 

the time observation among real users is a great idea

 

I think the token system is just a way of encrypting the time that the form is displayed, so it uses the concept I brought up, just presented in a slightly different way. Which makes sense bc I think I've sent messages quickly on myspace and they make me enter a captcha, probably to verify that I'm not spam.

 

I would be interested, though, to research what things happen as a user browses a page, as opposed to what all(or most) bots do and how the behavior differs in terms of length on page, actions taken, links clicked, forms submitted, data entered, etc

[dsaba]

if you find a handy bot information repository, let us know (not sarcasm)

[.josh]

- The token system is a way of authenticating the form itself, and does not really have anything to do with "time." 

 

- You can very easily have a bot "sleep" for a couple of seconds on each input to get around your time limit. 

 

- It's really not that hard to make your own browser in c, vb, java, etc.. at least the basics.  Like seriously, it's just a couple lines of code to send and receive data.  And the point to that is that your easily made browser would have no such limitations on "events" etc...