hpr-knowledge-base/hpr_transcripts/hpr3296.txt

Episode: 3296
Title: HPR3296: Spam Bot Honey Pot
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr3296/hpr3296.mp3
Transcribed: 2025-10-24 20:22:02

---

This is Hacker Public Radio Episode 3296 for Mundi, the 22nd of March 2021.
Tid's show is entitled, Spambot Honey Pot It Is Hosted by Roen and is about six minutes long
and carries a clean flag. The summary is implementing a Honey Pot Style Spam filter for your HTML
forms. This episode of HBR is brought to you by an honest host.com. Get 15% discount on all
shared hosting with the offer code HBR15. That's HBR15. Better web hosting that's honest and fair
at an honest host.com.
Welcome to Hacker Public Radio. In this episode, I will describe the method I chose to combat
Spambots, Spambots, filling out my company's contact form. About 99% of the submission we've received
or spam, which makes filtering for valid messages painful. After some research into different methods,
I decided to go with the Honey Pot Method. The Honey Pot Method uses an extra and text input
field to lure the spam bot into filling it out. There are different suggestions for how to hide
this extra field from valid users by using either JavaScript or CSS. With JavaScript, the Honey Pot
section of the form is removed from the DOM when the page loads, hiding it from your users.
The argument for this method is most bots don't implement JavaScript, so the Honey Pot field will
not be hidden from them. I think it is a valid argument, but I didn't want to include extra JavaScript
in my page, so I went with the CSS method. There are references at the end of the show notes to a
couple of articles I read on implementing the Honey Pot with either JavaScript or CSS. My takeaway was,
one, don't use the CSS display property set to the value of none to take the input out of the DOM.
Sufficiently smart bots may know to scan for this, especially if applied directly to the element.
And also, don't name your class as something obvious to your intent like anti-spam filter.
My guess is the majority of bots out there aren't that sophisticated, but I figured it couldn't hurt
to follow those suggestions. I was already using Bootstrap CSS for our site, so I decided to use
Bootstrap's SR-only class. This class is used for elements that you only want visible to screen
readers. It takes the element and uses a combination of absolute positioning, setting the size and width
to one pixel, setting a negative margin, and hiding content overflow to prevent the Honey Pot showing
up visually. I figured if the bot was scanning CSS for classes or properties, this wouldn't trigger
any warnings. It does bring up the issue of how to prevent impacting the experience of people
using screen readers. I applied the ARIA-Hidden attribute with a value of true to the label elements
surrounding the Honey Pot input field. This removes that element and all of its children from the
accessibility tree. That was a quote from the Mozilla documentation project. So we now have the field
hidden both visually in the browser and from assistive technologies. Given the short
end of the stick accessibility usually gets, I doubt there are any spam bots scanning for that ARIA
attribute. For the minority of users who might be viewing with the classic links browser, I put
four office use as the label text before the Honey Pot, hoping this would get the message across
without tipping off the bot to the intended purpose of the related input field.
The other main issue with this method is the value of the name attribute used for the input
field. Some argue to use up-suited values like MMXX name instead of name or SXYS phone for phone.
Apparently some bots will skip fields they don't recognize. By using more standard names for
multiple Honey Pot fields, it is easier to determine if it is a bot. The counter-argument to this
naming scheme is about the user experience. By substituting the name, the browser won't fill
the valid fields for the form. This also brings up the matter of not filling auto-filling the
spam fields by the browser of your users. This is done by setting any of the Honey Pot input elements
auto-complete attributes to off. So far the spam filtering method is working nicely.
I currently send any messages flag to spam to a different email address with the subject
prepended with the words spam review. Once I am confident there are not that many false positives,
I will just skip sending flag messages. The one issue I have experienced with this message is when
using the tab key to move through the form. Since the input field is only visually hidden,
it still receives focus as you tab through. If you happen to hit another key while still in the
hidden field, it will get captured by the Honey Pot and then the submission will be flag to spam.
I have created a sample form on my personal site. Please visit URL http www.horning.us
forward slash hpr forward slash spambot honeypot.php. spambot honeypot is camel case to try it out.
There is also reference in the show notes to the URL. It is a simple PHP page that using the
get method when submitting the form. Once you press the submit button you will see the form fields
and their values along with the result messages. I choose to use URL as the name for my honeypot
input field. I use it on my example form and I use it for my form at work. For my work form a URL
is not something we ask to be submitted and being a common field in forms makes it very tempting
for bots. In my example code the CSS for hiding the honeypot section is from the mini CSS.org website.
Their visibility hidden class is very similar to bootstraps sr dash only class.
I would be interested to hear if any others out there in the hpr world have implemented something
similar. I would also love to hear if some of our hpr users who use screen readers can test this
out and see if the honeypot field is being hidden from screen readers. It doesn't prevent it
from being read. Thank you for listening. I hope you found this another interesting episode of
Hacker Public Radio. You've been listening to Hacker Public Radio at Hacker Public Radio.org.
We are a community podcast network that releases shows every weekday Monday through Friday.
Today's show, like all our shows, was contributed by an hpr listener like yourself.
If you ever thought of recording a podcast and click on our contributing to find out how easy it
really is. Hacker Public Radio was founded by the digital dog pound and the infonomican computer club
and is part of the binary revolution at binwreff.com. If you have comments on today's show,
please email the host directly, leave a comment on the website or record a follow-up episode yourself
unless otherwise stated. Today's show is released under a Creative Commons
Attribution ShareLight 3.0 license.