Posted by Shaiful Borhan on June 5, 2010
Shaiful discusses about alternative ways to combat spam in web forms and why CAPTCHA is his least favourite. Shaiful Borhan is the Web Analyst and Developer at Stampede.
One of the rules in today’s web is if you have forms on your website, you need to have some kind of spam prevention measure implemented. Here I will talk us through the several methods that can be used and why CAPTCHA isn’t one.
Well, spam prevention wise CAPTCHA challenge works. But the main problem is it considerably lowers the user experience by requiring extra effort and time to read the garbled image that may deter the user from completing the form altogether. To overcome that, they came out with the audio version of CAPTCHA which seriously, is even more troublesome. On top of that, having a CAPTCHA image certainly cripples the aesthetics of a well-designed form. With all these shortcomings however, CAPTCHA might be the best method to counter manual spammers (humans) because they would get too annoyed to do the CAPTCHA challenge.
Apart from image CAPTCHA, we could use a different version of challenge question method. One of the popular approaches is to present users with simple arithmetic operations e.g. “What is 4 + 2?” As with CAPTCHA, it is also randomized each time the form reloads. Another variant is to use questions that requires textual answers such as “What animal meows?”. It should be noted that questions like these should be made simplistic as it introduces language barriers between the users and the system and to prevent the user from taking extra efforts.
The methods described above require user input in order to distinguish humans from spambots. This additional step can be eliminated by using a little bit of programming logic to validate the form submission on the server side.
Spambots usually love to fill out every field on the form. We can take advantage of this behaviour to trap the bots by setting up a field that is hidden from the user’s view, assuming it would not be filled by a legitimate human user. This field has to be a normal type=“text” with a tempting name like ‘email’ or ‘website’ except it has a CSS “display:none” property. The idea is to flag the form submission as spam if this field was filled. To cater screen reader users without CSS support, adequate label should be applied telling them to leave this field blank. Additionally, bots also have the tendency to post links and irrelevant keywords in textarea fields. A carefully crafted regex validation on these fields would help prevent faulty form submissions substantially.
Another advanced approach is to attach a unique, dynamically-generated token as a hidden field on your form and then check its validity upon submission. These tokens can be produced using session IDs or simply timestamps. The idea behind this method is to ensure the user viewing the form is essentially the same user submitting it. The timestamp method can be used to calculate the time elapsed between the page being viewed and submitted.
In order to stay concurrent with the advancement of spambots, the measures taken to combat spammers have also been taken a step further by using a collaborative, distributed and intelligent approach as can be seen in Akismet and Project Honey Pot. The Akismet service is fairly popular because it comes natively with Wordpress, arguably the most used blogging platform in the world. What it actually does is it runs numerous tests on the form submission data against its own huge collection of black/white list and returns the status with a thumbs up or thumbs down. The filter works by combining information about spam captured on all participating sites, and then using those spam rules to block future spam.
All in all, there will not be a silver bullet for solving web form spamming. Spambots will always become smarter and we quite surely couldn’t stop manual spamming. Nevertheless, with modern services like Akismet and Project Honey Pot the prospects certainly look promising.
Posted in Code 1 Comment »
Posted by Shaza Hakim on June 1, 2010

Up to this hour, we’re still doing last minute removal of things from the original Stampede v3 design. With the amount of content we’re dealing with – 24 dissected portfolio pieces at last count – 8 months of detailing work on weekend and after hours don’t seem at all extravagant.
All in all, I spent around 180 hours of design time and that’s not only because of the level of complexity involved, but mostly the routine of going macro when everything is done, then removing almost half of it.
I still do incremental design change after sending the templates for Joomlafication, some so minute that only the most observant will notice. If we don’t have our own internal programming powerhouse, I can only imagine the costly bleeding.
Because this is the most ambitious project we have done for ourselves just yet, tension does run high and heated arguments over design vs code were so commonplace that when we finally come to an agreement, it was worth sitting back to take in what just happened. Such is the merry partnership I have with Dov.
It took 4 major revisions, countless minor ones, a bit of going back and forth with the rest of the team for valuable insight (whether to place this element or that on the right or left or scrap it altogether). Stampede v3 was almost a practice of convoluted layering (up to 400 at last count) to achieve a particular blend, testing out new composition for different content type, revising typography properties. Let me not bore you. Needless to say, it required plenty of patience as well.
Though I must say the only constant throughout the revisions was our signature color red. Our new logo and branding does not go through multiple iterations like most design agencies do. The branding – if you can call it that – was a split second decision of deciding what embodies Stampede. After that was decided and validated by the rest of the team, we now have a new logo, polished and all but still represents the very same identity.
Stampede has been very blessed and lucky, to say the least. We have a good score of clients who pretty much leave most design and development decision to us. We also get smart young people generous enough with their passion and time to become part of our team. I felt it’s about time for us to share values that have prevailed since Stampede’s very early days so we have designed and built a special page for this. As co-policymaker at Stampede, I probably have more fun with the Values page than most people expected.
So when v3 is finally launched, you may find it look way simpler than the actual effort – I sure hope so after the many hours spent mulling over what to safely remove and what to keep.
But then again, Stampede’s own website design has always been a sort of escapism for us from daily client requirements. It’s something we don’t do everyday and probably will never do again. For that reason alone, I know a few more days of punishing pixels is worth it.
Posted in Design, Team 1 Comment »