On Mo, Mär 07, 2016 at 11:35:00 +0100, Florian Fuchs wrote:

There are a number of alternatives to captchas to prevent spam. None of them is perfect, but one I kind of like is the honeypot approach:

It's basically an empty and visually hidden input field that is ecpected to be emptily submitted. Most spam bots will try to fill it with some text, which is the warning flag that can be used to ignore those submits.

The big plus is that it won't require human users to take any extra action, making it completely unobtrusive to *most* users.

The one major downside is that it might be confusing to users who use screen readers and to whom this extra input is properly displayed, which might cause some confusion. Of course, this can be solved somewhat by labelling the field accordingly, something like "Are you human? Than keep this empty".

I think I was using sites with this spam protection approach and itwas OK for me.If the field which needs to be empty is clearly labeled, it should cause no problem.

Also, I have no idea how sophisticated spam bots are becoming in detecting honeypots, for instance by only trying to use "known" fields like "username", "email address" and so forth.

Because the mailman sites which are publicly available to the users doall have the same structure, programming bots that can handle this sites will be no big problem IMHO.

Still, even if this is not a perfect solution, it might still be better than the big usage impediment of captchas.

Full ACK :-).

As a side-note, especially to those who are using screen readers: What is your experience regarding the use of JavaScript in current screen readers? Is this still mostly a no-go for web sites aiming to be accessible or has there been some improvement?

Javascript is no problem with modern screen readers and browsers, so no need to not use it. But for example I work very ofthen on linux systems in the console and there is no browser with Javascript support, for this reason I'm happy about every site that is also useable inthis environment :-).

Ciao,

Schoepp

-- Christian Schoepplein - <chris (at) schoeppi.net> - http://schoeppi.net

On Mon, Mar 07, 2016 at 11:35:00AM +0100, Florian Fuchs wrote:

There are a number of alternatives to captchas to prevent spam. None of them is perfect, but one I kind of like is the honeypot approach:

There are others as well. A few scattered examples:

1. Use the Spamhaus DROP and EDROP lists to forbid all access from networks known to be hijacked and/or entirely controlled by spammers. By "all", I mean "drop all packets at the firewall" and "do so bidirectionally".

2. Use the various Spamhaus DNSBLs (particularly: Xen) to block SMTP traffic. The false positive (FP) rate from this is neglibly low.

3. Use country-specific IP allocations (see: ipdeny.com) to grant or deny access on a country-by-country basis. This won't work so well for global mailing lists, but -- to make up an example -- a list for skiers in western Colorado is unlikely to have subscribers from Pakistan, Peru, or Portugal. So why not block those countries entirely? The likelihood of a FP is tiny and can be mitigated by providing a reporting method for those affected.

There are more, and the decision on which to employ depends on the site, the list(s), the audience, etc. But these are well-understood, reliable, robust, difficult-to-game, predictable methods which yield excellent results.

---rsk

On Mo, Mär 07, 2016 at 11:35:00 +0100, Florian Fuchs wrote:

There are a number of alternatives to captchas to prevent spam. None of them is perfect, but one I kind of like is the honeypot approach:

It's basically an empty and visually hidden input field that is ecpected to be emptily submitted. Most spam bots will try to fill it with some text, which is the warning flag that can be used to ignore those submits.

The big plus is that it won't require human users to take any extra action, making it completely unobtrusive to *most* users.

The one major downside is that it might be confusing to users who use screen readers and to whom this extra input is properly displayed, which might cause some confusion. Of course, this can be solved somewhat by labelling the field accordingly, something like "Are you human? Than keep this empty".

I think I was using sites with this spam protection approach and itwas OK for me.If the field which needs to be empty is clearly labeled, it should cause no problem.

Also, I have no idea how sophisticated spam bots are becoming in detecting honeypots, for instance by only trying to use "known" fields like "username", "email address" and so forth.

Because the mailman sites which are publicly available to the users doall have the same structure, programming bots that can handle this sites will be no big problem IMHO.

Still, even if this is not a perfect solution, it might still be better than the big usage impediment of captchas.

Full ACK :-).

As a side-note, especially to those who are using screen readers: What is your experience regarding the use of JavaScript in current screen readers? Is this still mostly a no-go for web sites aiming to be accessible or has there been some improvement?

Javascript is no problem with modern screen readers and browsers, so no need to not use it. But for example I work very ofthen on linux systems in the console and there is no browser with Javascript support, for this reason I'm happy about every site that is also useable inthis environment :-).

Ciao,

Schoepp

-- Christian Schoepplein - <chris (at) schoeppi.net> - http://schoeppi.net

On Mon, Mar 07, 2016 at 11:35:00AM +0100, Florian Fuchs wrote:

There are a number of alternatives to captchas to prevent spam. None of them is perfect, but one I kind of like is the honeypot approach:

There are others as well. A few scattered examples:

1. Use the Spamhaus DROP and EDROP lists to forbid all access from networks known to be hijacked and/or entirely controlled by spammers. By "all", I mean "drop all packets at the firewall" and "do so bidirectionally".

2. Use the various Spamhaus DNSBLs (particularly: Xen) to block SMTP traffic. The false positive (FP) rate from this is neglibly low.

3. Use country-specific IP allocations (see: ipdeny.com) to grant or deny access on a country-by-country basis. This won't work so well for global mailing lists, but -- to make up an example -- a list for skiers in western Colorado is unlikely to have subscribers from Pakistan, Peru, or Portugal. So why not block those countries entirely? The likelihood of a FP is tiny and can be mitigated by providing a reporting method for those affected.

There are more, and the decision on which to employ depends on the site, the list(s), the audience, etc. But these are well-understood, reliable, robust, difficult-to-game, predictable methods which yield excellent results.

---rsk