Hoping to pick your brains on this. What is your preferred method?

 

I loathe captchas, they make for a terrible ux and they are very poor as terms as acessability goes.

 

I simply put a load a few input fields that are hidden using CSS. in a smart way to fool the bots, some of them won't fill out a form element that has display: none for instance, but there are creative ways of visually hiding things (like overlaying other elements on top of them). Put a placeholder inside to instruct users with screen readers not to fill them out, or use aria attributes to make the screen readers ignore them. give them a negative tab-index too so users don't accidentally tab to them.

 

If any of these fields get filled out then you know it's not human.

 

This won't stop all spam, but it stops almost all of it. I imagine the figure is somewhere between 99 and 100% You gmail spam filter should get rid of the majority of the rest, a few might slip through but it's worth it to avoid runing your users experience.

 

Those are my thoughts on the matter.

Edited February 5, 201511 yr by rbrtsmith

Thanks @@rbrtsmith, very useful!

I hate capthas, too, grrrrr

 

I have been looking at hidden fields solution, great advice on usability there, thank you.

 

What do you think would be best for human spam - some sort of inputs value keywords blacklisting maybe?

Captcha - who doesn't loathe them!

 

I prefer using a honeypot field because it non-obtrusive...

The only things I do for human spam, set required fields. just makes them work a bit harder,

 

maybe you can reject anything with URLS but that could have a useablity issue. There's probably php scripts around that will allow you to reject an email containing a set of banned keywords. It's not so easy to stop human spam alltogether though. It's not something I've had issues with personally.

I use honeypot and 'captcha' but a non image, non case sensitive method where I random one of 500 easy questions like ...

 

Which is the odd one out?

Orange, Yellow, Table or Red

So far no complaints from site visitors questioned and some even like the fact it makes them think. Honeypot is ok for most things it's just the more important things that often require we go a little further.

 

The only things I do for human spam, set required fields. just makes them work a bit harder

 

Yep yep! Also don't rely on just js for this without a solid php backup.

 

Yep yep! Also don't rely on just js for this without a solid php backup.

 

 

That's a good point!

Thumbs up Teodora for starting this subject. I often find it difficult to choose the right solution (mostly due to lack of knowledge I must admit).

My main concern is accessibility. I lean towards hidden fields but are hidden fields ignored by screen readers?

BrowserBugs solution also has some issues for non English speaking users relying on translation tools (a Danish browsers translation of “Which is the odd one out?” makes no sense)

aria-role="hidden" will make screen readers ignore. tab-index="-1" will prevent users from tabbing to it.

 

The qustion is still giving the users more steps to complete. You might not get complaints but it will lower conversion a little. Nicer than captcha though. But a honeypot that is hidden in a smart way will work just as well Without making any impact on the UX whatsoever.

Edited February 5, 201511 yr by rbrtsmith

BrowserBugs solution also has some issues for non English speaking users relying on translation tools (a Danish browsers translation of “Which is the odd one out?” makes no sense)

 

Agreed it's not a 'solution' in all situations, this method I've used on account creation process for UK focussed businesses rather than enquiry forms where the worst that will happen is a few junk emails rather than loads of half made accounts awaiting verification. As for translation tools you're at the mercy of whichever tool the visitor is using ... this same translation issue would apply site wide on all content. On the plus side I spent a morning at the local RNIB college and they thought it was a good choice. Interestingly they complained about Googles own captcha as the 'sound' version sounds like you're in a train station.

 

 

aria-role="hidden" will make screen readers ignore. tab-index="-1" will prevent users from tabbing to it.

 

The qustion is still giving the users more steps to complete. You might not get complaints but it will lower conversion a little. Nicer than captcha though. But a honeypot that is hidden in a smart way will work just as well Without making any impact on the UX whatsoever.

 

I agree it's an extra step, but if they want to register for an account there will always be checks in place before being allowed to do 'stuff'. Ah well, it's just another method like time delay on repeat submissions.

 

Edit: Forgot to mention other validation options I use include time delay, checking where the post came from (helps prevent cross site submission), email and phone regex ... yada yada

Edited February 6, 201511 yr by BrowserBugs

Generally for creating accounts (i've not done this myself but I see it done often) is you register an email and then you have to respond to an email that they send out to verify.

 

In my opinion there should be much harsher laws for those caught to be spamming, it must cost the industry an absolute fortune. and it can also be very invasive.

Generally for creating accounts (i've not done this myself but I see it done often) is you register an email and then you have to respond to an email that they send out to verify.

 

Yep that's verification, however every verification sent is still stored in the DB, more dead records to run through for valid user login. Sure we can purge old records where they are not verified within X time frame but prevention IMO is better than extra work later down the line.

Soooo...

 

I have decided to have a password field, positioned off page with CSS. If this field has value, the form won't submit.

I have also made an array of blacklisted keywords - if any input or textarea contain any of those keywords, the form won't submit either.

 

Would you say that's enough?

 

BTW it's not a contact form or a login form, I have integrated it with a project management software API and it's supposed to add project tasks on submission.

Soooo...

 

I have decided to have a password field, positioned off page with CSS. If this field has value, the form won't submit.

I have also made an array of blacklisted keywords - if any input or textarea contain any of those keywords, the form won't submit either.

 

Would you say that's enough?

 

BTW it's not a contact form or a login form, I have integrated it with a project management software API and it's supposed to add project tasks on submission.

 

That array of keywords, are you testing for them in php? as this is the better place for this. JavaScript is better for general feedback IMO

 

That array of keywords, are you testing for them in php? as this is the better place for this. JavaScript is better for general feedback IMO

 

Yeah I would use php for this, maybe get all hardcore on their ass with a 403 if they have spam terms or maybe nick their ip address and post it to the hackers forums?

I like the honey pot method as mentioned above combined with time, if the form is submitted in 1 second, then that's something i'm happy to challenge.

It's all done with jQuery for now

I just need to get my head around the concept of what I am doing with these forms and then I'll re-write to php!

We love captcha.

We use captcha on all our clients websites. We have never had any complaints and most of them receive 100s of form submissions per week.

We have never had any spam related complaints, unless it was Raj from India who submitted the form to get a SEO contract.

Not getting complaint's is hardly a reliable method to determine if they are having a negative impact on UX and conversion rates. Doing long running AB tests shows that in all cases bar a few anomalies that this is true. I've had plenty of bad experiences on websites, I have never sent a complaint, but I've often left for a competitor as a result.

There is a simple way to check the conversion to compare the page session/visit with the number of submitted forms. If your clients are high profile then you will put additional details to contact if the form is simply not doing for them. We take on page forms and conversions very serious and would not let it be if captcha would effect the conversion.

 

Hidden fields, most modern spambots will ignore hidden fields. Don't forget that if you have a website with high traffic and forms with hidden fields then it will take couple of minutes to recode the spambot specifically for your form where the hidden fields are coded.
A captcha, instead, prevents bots being created (or customized) for your page or form.

 

I would not try to code an insecure method to clients forms.

 

maybe we should advice Google, Microsoft, Yahoo, Amazon, Ebay and many other websites to stop using Captcha?

Edited February 7, 201511 yr by newman

Have you seen the new google captcha? It relies on human activity, which I am guessing is cursor movement, time and anything else a spammer generally doesn't do. If it's unsure if your a real person then it forwards you onto the standard captcha.

https://www.google.com/recaptcha/intro/index.html

Have you seen the new google captcha? It relies on human activity, which I am guessing is cursor movement, time and anything else a spammer generally doesn't do. If it's unsure if your a real person then it forwards you onto the standard captcha.

 

https://www.google.com/recaptcha/intro/index.html

Yes this is what we use. Works perfect.

There is a simple way to check the conversion to compare the page session/visit with the number of submitted forms. If your clients are high profile then you will put additional details to contact if the form is simply not doing for them. We take on page forms and conversions very serious and would not let it be if captcha would effect the conversion.

 

Hidden fields, most modern spambots will ignore hidden fields. Don't forget that if you have a website with high traffic and forms with hidden fields then it will take couple of minutes to recode the spambot specifically for your form where the hidden fields are coded.

A captcha, instead, prevents bots being created (or customized) for your page or form.

 

I would not try to code an insecure method to clients forms.

 

maybe we should advice Google, Microsoft, Yahoo, Amazon, Ebay and many other websites to stop using Captcha?

 

By measuring the conversion I am assuming you are doing this along with AB tests on Captcha Vs non Captcha otherwise you're not getting any real information on how it's affecting conversion.

 

If the fields are hidden in creative ways like I mentioned earlier and not doing something obvious like display none or positioning it offscreen then VERY few will find ways of bypassing this.

 

You are giving your users extra steps to accomplish their task, that will lower conversion. You find far less high profile sites now using captcha than you did previously because of the bad UX they provide. I have never experienced captcha on Amazon in all my time visiting there, same for Google.

 

The new solution by Google posted by @@EpicWebs does look very promising however. I'd actually recommend that over the honeypot method. Traditional captchas though are what I am talking about and they are horrible, especially in terms of accessibility.

 

All that said on less security critical sites I'd probably still go with the honeypot method. it's a toss up between the two depending on the project.

Edited February 7, 201511 yr by rbrtsmith

 

If the fields are hidden in creative ways like I mentioned earlier and not doing something obvious like display none or positioning it offscreen then VERY few will find ways of bypassing this.

 

Oh, no! I thought positioning them off screen was clever!

I rather go with modern reCaptcha against modern spambots then any other method.

 

Using the new reCaptch from Google will make your work easier and will give your forms better security than other methods ( I don't work for Google )

 

Oh, no! I thought positioning them off screen was clever!

 

I was doing similar, it certainly works better than display none.

 

But the bots are less likely to discover that it's hidden, say if you overlay another element on top of it, that way the css for the hidden field doesn't look abnormal in anyway to the bots. You should also be careful how you name this field i.e. don't name it 'hidden field'

 

@@newman agreed, in most cases the Google solution is very nice. I'll be interested into how it affects load & run time of the performance, if it hinders it then I guess we just have to weigh up our options on whats most important, the honeypot requires very little code.. but won't be as effective of course as Google's solution.

Edited February 7, 201511 yr by rbrtsmith

I'll be interested into how it affects load & run time of the performance, if it hinders it then I guess we just have to weigh up our options on whats most important, the honeypot requires very little code.. but won't be as effective of course as Google's solution.

From experience using third party scripts tend to affect load time the most as well so it'll be a close call to just recieve a few spam contacts vs poor load time/UX for the user so you affect the amount of real contacts you receive.

 

Yep that's verification, however every verification sent is still stored in the DB, more dead records to run through for valid user login. Sure we can purge old records where they are not verified within X time frame but prevention IMO is better than extra work later down the line.

 

Then in that case have a table for unverified members. When someone registers put them into a table called for example 'users_pending'. When they click the link in the verification mail move them from that table to say 'users_valid' and delete the details in the 'users_pending' table.

 

You could also set the verification to run a subscript that runs through the table and deletes any entries which are over a certain age. Alternatively a cron job could be set up to do it.

 

Then in that case have a table for unverified members. When someone registers put them into a table called for example 'users_pending'. When they click the link in the verification mail move them from that table to say 'users_valid' and delete the details in the 'users_pending' table.

 

You could also set the verification to run a subscript that runs through the table and deletes any entries which are over a certain age. Alternatively a cron job could be set up to do it.

 

Yes, all the above makes sense, but not everything is thought through to the ultimate finish on phase one of a project - we should all be refining as we progress.

 

Yes, all the above makes sense, but not everything is thought through to the ultimate finish on phase one of a project - we should all be refining as we progress.

 

QFTW

 

Yes, all the above makes sense, but not everything is thought through to the ultimate finish on phase one of a project - we should all be refining as we progress.

 

Well it should be thought through if it is a project, anything else and it's a hobby.

 

Phase one should always be determining precisely what you want to achieve. Once you know what that objective is you know exactly what you are working towards. If you don't define an end objective and 'refine' as you go you are likely to find that things you did at the outset suddenly become a roadblock when you want to add a refinement later on in the proceedings.

 

Well it should be thought through if it is a project, anything else and it's a hobby.

 

Phase one should always be determining precisely what you want to achieve. Once you know what that objective is you know exactly what you are working towards. If you don't define an end objective and 'refine' as you go you are likely to find that things you did at the outset suddenly become a roadblock when you want to add a refinement later on in the proceedings.

 

I believe that's what BB meant?

Depends on the type of project, there's always room for improvement after phase 1, testing to see what works and what doesn't and refining as we go.

Edited February 8, 201511 yr by teodora

 

Well it should be thought through if it is a project, anything else and it's a hobby.

 

Phase one should always be determining precisely what you want to achieve. Once you know what that objective is you know exactly what you are working towards. If you don't define an end objective and 'refine' as you go you are likely to find that things you did at the outset suddenly become a roadblock when you want to add a refinement later on in the proceedings.

 

TBH this just sounds like a blog excerpt, marketing shizzle. Things were planned, if it helps this build is 6 years old now and getting a revamp - the ultimate goal at the time was a image-less captcha back when most sites were still using squiggley text in an image.

 

I'm more referring to progress. When you first conceive a project for a client or yourself you try your best to create something that suits their requirements. However, as with all things 12 months down the line you can see bits that worked really well and bits which had a few unforeseen side effects, such as dead accounts. It's unrealistic to think that we always hit the nail on the head first time, that we always think of every potential situation. Look how far the industry has come; 15 years ago we built sites with tables and <font>, then came css, tableless tables, jquery and now UX is a term! There is always room for improvement, even discussing honey traps in this thread, it's easy to make things 'work', it's just tuning between working and really working well.

 

TBH this just sounds like ......., marketing shizzle.

 

Do you really think so? I might have a possible new career possibility if so. Bloody lucrative one as well, even better than being a recruitment consultant, another overpaid non-job.

 

I may have misconstrued your post if so apologies. I come from the engineering industry where you often don't have the luxury of being able to run a project 'on the fly' as much of the activity involved is regulated by legislation. So perhaps my attitude to planning has become a little more pedantic.

 

Which is where forums like this come in useful, they allow users to gain an insight into other methods of approaching projects and problems.

Edited February 8, 201511 yr by nfc212

 

I may have misconstrued your post if so apologies. I come from the engineering industry where you often don't have the luxury of being able to run a project 'on the fly' as much of the activity involved is regulated by legislation. So perhaps my attitude to planning has become a little more pedantic.

 

Possibly so, but even with engineering and thinking through problems why did the Millenium Bridge wobble so and why did they only rectify this 2 years after it was finished? Sounds more 'on the fly' eh?

I want to revive this discussion because I've just saw this article with an alternative approach: Checking for focus or click events with JS supplemented with a captcha in noscript tags. What do you all think about this approach?

Note that the hidden field by default is set to not identity the user as human, the value of the field is only changed when an event that could only be performed by a human is detected.

Edited February 22, 201511 yr by Nillervision

Surely spam bots can easily get around this kind of detection just by focusing on a form element, or triggering a click event. I don't imagine that kind of behaviour would be difficult to replicate, I feel the honeypot method, hidden in the ways I described is harder for the bots to break. I am happy to be proved otherwise but as it stands I am not convinced by the method in that article. It would also help the readability of his code if he used some indentation, that said I think it's a good thing that we are trying out different techniques for spam prevention, anything but captchas!

Surely spam bots can easily get around this kind of detection just by focusing on a form element, or triggering a click event. I don't imagine that kind of behaviour would be difficult to replicate, I feel the honeypot method, hidden in the ways I described is harder for the bots to break. I am happy to be proved otherwise but as it stands I am not convinced by the method in that article. It would also help the readability of his code if he used some indentation, that said I think it's a good thing that we are trying out different techniques for spam prevention, anything but captchas!

You are probably right. I was also thinking that the method might even hurt UX as to many scripts listening for events could slow down the browser. Still an interesting idea though.

You are probably right. I was also thinking that the method might even hurt UX as to many scripts listening for events could slow down the browser. Still an interesting idea though.

 

It's interesting if you read through the comments on that page too. Seems there is no perfect solution, but unless I'm directly targeted the honeypot method works well. I don't think it's so common that us on here will be directly targeted but it's still good to explore other methods, eventually we'll find something really robust. Although the Google reCaptch will probably be a good choice in those kind of circumstances.

 

Possibly so, but even with engineering and thinking through problems why did the Millenium Bridge wobble so and why did they only rectify this 2 years after it was finished? Sounds more 'on the fly' eh?

 

Oh that was simple it was down to way people walk.