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

This is simple form of a honeypot but it is really ineffective. Any bot with even minimal sophistication will know to leave the hidden field empty.

I agree that it's possible - potentially trivial - for a bot to figure out if a field is hidden from view, but "really ineffective" seems a bit extreme for something I've seen work well multiple times.

It's not a definitive solution, but it's an easy and practically free first line of defense for a young project, and depending on the project, can stand for years.

Overall, it depends on the sophistication of the bots your project attracts.

You hide it with CSS, not type='hidden'

So now you're filtering out bots and people with disabilities?

Nope, screen readers (usually?) ignore elements with "display: none".

To be sure, you could add aria-hidden="true", which I'd guess most bots don't recognize.


Many don't just use display:none but position text off-screen or make it tiny or use sizing and overflow:hidden. I've seen a blind user be tripped up by these, so yes, it often also filters out disabled users.

Many people use tools incorrectly, that doesn't mean you shouldn't use those tools, you just have to be aware of the problem, which everyone in this (sub)thread now is.

A decent screen reader will look at the final rendered Dom and obviously cull items off-screen, the same colour as the background, or 1px high.

If it doesn't, its a bug in the screen reader.

There's quite clear standards on how screen readers are expected to interact with the DOM. What you claim is in none of them, and the techniques you mention are explicitly mentioned as something authors of webpages should avoid/mark up correctly for screenreaders.

No such screen reader exists, so you could claim it's a bug in all of them, but it's not a useful position to take. Screen readers are tricky enough to write without having to second-guess people who are trying to hide-but-not-hide text.

Unfortunately I've not given thought to people with disabilities in this case. It's an oversight and that's on me.

I wonder if bots are smart enough to figure out aria-hidden="true". Possibly empty it out using javascript on submit. I would guess a bot not using CSS would also not be using javascript? Unsure, would need testing.

Could we just tell the people with screen readers to ignore it?

As a fallback I imagine so yeah. I'm trying to think about what would be going on at the time, wondering if unexpected instructions inside a form would be confusing.

Disclaimer: I don't know how a screenreader would present this, example only

"Form entry. Input name. Input email. Ignore this field it's for spambots. Input url. Submit" -- In this case does the message more naturally apply to email or url? I'd imagine there'd be a pause after input email (to wait for the input)? I need to set up a screen reader :)

And then hide the warning using CSS too, so it gets picked up by screen readers just like the hidden input!

Should we put the onus on screen readers to not read elements that would not be displayed when the page is rendered in a browser??

Admittedly, I am not familiar with screen reader standards, but my gut feeling is that they are doing their users a disservice if they are not representing what browser users are seeing as similarly as possible.

You can set placeholder with something like "leave it empty".

It really doesn't matter. display:none or position:absolute;left:-1000px makes little difference. Honey pots only catch a small number of bots.

I just removed Google's ReCaptcha for a honeypot solution with an additional name and url field. But there's also a timer which checks how long it takes you to submit the form. If you can fill out everything in <2s, you're most likely not human. I have to figure out how people with disabilities can use the page though. Good to get a reminder here. So far it performs way better than ReCaptcha, I haven't received any spam so far and plenty of ham of course. No human complaints either.

A timer is a novel idea. I hadn't seen that suggested before.

Do you anticipate any problems with form auto-filling tools?

I only have anecdata of course but so far I've had a 100% success rate. I imagine this will come down eventually but for the past ~year or so it's been working fine to just hide the honeypot field with CSS

I'm glad it's worked for one of us at least.

I don't know if it helps any but I've been using a field that looks real.

Depending on where it is the name= would be surname (where the form submission has a name field rather than a first name surname split), website, url, etc

You can still figure out it's hidden.

Sure but the point is that almost nobody does.

Registration is open for Startup School 2019. Classes start July 22nd.

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