Hacker News new | comments | show | ask | jobs | submit login

> You can implement basic defenses like hidden input forms or checkboxes that are masked by CSS rules or served on the client side with JavaScript to weed out bots from human users, among other less intrusive techniques.

Umh, anything that will end up in the POST request will be reproduced by a bot, I don't even actually look at the page when implementing screen scraping modules, but just at the Network tab of the Chrome Dev Tools.

What I think have the potential to remove the need for conscious CAPTCHA solving is what Google is supposedly doing here: machine learning on behavioral patterns in the user interaction with the form (instead of just with the CAPTCHA).

No no, the hidden input fields would not be filled in by a human (because they're positioned off screen by CSS, for example), whereas a bot would fill them in because the bot is just scraping the HTML for all input fields and filling them in with something.

It seems like you had that backwards -- hope that clears it up.

Why would I have my bot fill them in? One glance at the site and I know that my bot should skip those fields.

It's meant as a defense against non-targeted bots—the ones that roam the web looking for forms to fill out.

I think that's where the issue lies: these tools do different things. Honeypot fields defend against general bots. Captchas defend against specific bots, too, but also have greater friction, so are only used when specific bots are an issue.

I did my mom's website for her small law firm and I was getting tons of bots even with hidden form fields and they didn't look targetted. Captcha helped a lot but the spam didn't stop until I used both combined with special rules, like the phone number field has to have a certain amount of numbers.

Ok, I thought it was intended as a counter-measure to targeted bots.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact