5 ms·
Cool idea -- what kind of spam protection can it offer though? I'm not worried about the email address being in the open, but my original contact page form was
by aquark 13y ago
Cool idea -- what kind of spam protection can it offer though?
I'm not worried about the email address being in the open, but my original contact page form was getting hundreds (thousands?) of spam submissions a day until I implemented some simple javascript 'traps' to filter out the bots.
I've still not worked out why a bot wants to fill in a contact form with spam anyway, seems like a real waste of time.
- Zikes 13y agoBest and simplest trick I've found for this is having a CSS hidden honeytrap field, something like <input name="message_body" type="text" class="hideme" /> Bots will put something in the field but humans should never see it, so if the server sees anything in there it can safely toss the whole thing.
- eli 13y agoTwo pitfalls: 1) You should add some text to indicate to people using screen readers that this field should remain blank. 2) You should make sure to name the field something unlikely to be autofilled. There are browser toolbars out there that will happily autofill even hidden fields and trigger your spam filter. But other than that, I agree that this is extremely effective against the common sort of drive-by spam bot. (And, obviously, completely useless against any sort of advanced or targeted attack.)
- Zikes 13y agoExcellent points, thank you.
- aquark 13y agoGood point. My javascript solution uses two hidden fields with very similar names. One that the script fills in and one that it doesn't. Bots will either hit both or neither and get rejected. Screen readers/toolbars may be an issue, though the names would be hard to think what to autofill with. It has never come up in practice -- the reject message tells people to email us directly If you have javascript turned off, you'll need to email directly too -- and the site won't work so there probably isn't much lost!
- deleted 13y ago[deleted]
- cpayne624 13y agoHow I handle it. Effective so far... http://img42.com/881bp http://img42.com/881bp
- laurihy 13y agoThanks! :) As many have asked, at least for now there's no real spam protection. Asking you to confirm email for every email/referer pair prevents me from adding your email to zillion sites (although confirmations could also get annoying at that point :) and spamming, but of course that doesn't still prevent bots from filling out your form. I think in a way it's a tradeoff between ease of use, both for you and the visitor. Alternatively we could do heavier registration process and/or let you configure some running on our server, but then setting things up wouldn't be as easy and you might as well just run your own backend. For the visitors forms provide an easy (than, say just email) way to reach out. I guess the question is, do you prefer false positives (spam) or false negatives (folks not reaching out) :) Regarding having clear text emails in the source, I'd argue (based on nothing but anecdotes) it doesn't matter, much. As throwawaymsft said elsewhere, bots are pretty good at figuring out what "you (at) email (dot) com" means, so in most cases you'd anyway be getting much spam. We considered a token-based approach instead, but decided to go all-in for simplicity. Also, since we're using forms anyway, they're more likely source of spam than some bot crawling just for addresses.
- maouida 13y agogreat idea. I think you can give the user the option to specify the email hash (MD5 maybe) instead of clear text email. so either: <form action="//api.formspree.com/user@example.com"> OR <form action="//api.formspree.com/b58996c504c5638798eb6b511e6f49af"> You can provide the user a small tool to generate the email hash. Good luck
- icebraining 13y agoBut then how can they know where to send the email to?
- maouida 13y agoThey have the email (confirmed email) in their DB. they can easily calculate the hash on the fly.
- cbhl 13y ago