The applications detects if the user clicked on “Submit” or elsewhere.
And this saves user’s time of typing weird captcha character.
This is a nice idea, but I think even things as simple as this can
sometimes cause issues. It can be difficult to explain what you’re
trying to do to users. There are also accessibility problems.
I’ve been playing with idea of having a list of randomly selected
questions that pretty much anyone can answer. For example, ‘what colour
is grass?’ with a selection of answers like ‘blue, red, green’. It
would be difficult for a bot to guess the answer and if the
questions/answers differed slightly from site to site, it would be very difficult to guess.
Using this method, you can just use ordinary, html forms, readable in
all browsers and the questions would fit neatly into a page.
On Tue, Aug 29, 2006 at 04:27:09PM +0100, Stephen B. wrote:
}
} > The applications detects if the user clicked on “Submit” or
elsewhere.
} > And this saves user’s time of typing weird captcha character.
} This is a nice idea, but I think even things as simple as this can
} sometimes cause issues. It can be difficult to explain what you’re
} trying to do to users. There are also accessibility problems.
}
} I’ve been playing with idea of having a list of randomly selected
} questions that pretty much anyone can answer. For example, ‘what
colour
} is grass?’ with a selection of answers like ‘blue, red, green’. It
} would be difficult for a bot to guess the answer and if the
} questions/answers differed slightly from site to site, it would be
} very difficult to guess.
}
} Using this method, you can just use ordinary, html forms, readable in
} all browsers and the questions would fit neatly into a page.
}
} Any thoughts?
It’s a great idea. A friend of mine came up with something similar some
time ago:
I had thought about doing something similar. Though it does solve the
accessibility issue of CAPTCHAs, it requires more work on the part of
the
user (filling in multiple form fields instead of just one).
It also seems that if it were to enter widespread circulation, bots
could be
made that would overcome it.
What we need is a Voight-Kampff:
“You’re walking through a desert, and you come upon a tortoise.”
would be difficult for a bot to guess the answer and if the
questions/answers differed slightly from site to site, it would be very difficult to guess.
Using this method, you can just use ordinary, html forms, readable in
all browsers and the questions would fit neatly into a page.
Any thoughts?
Steve
Hi Steve,
I’m actually working on a creating a plugin to do just this. This is
known as a “logic captcha” (Inaccessibility of CAPTCHA).
They have the advantage of not excluding sight-disabled individuals,
and are also harder to defeat programmatically. They can exclude
cognitively disabled individuals, and could also be broken by human
attack. Overall, I think they have better trade offs then image
captchas, so I’ve always wondered why they aren’t in larger use.
I’ve coded a logic captcha in Rails into i2 for the Madison Rails user
group wiki - so you can see it in action here: http://www.madisonrails.com/wiki. Just edit a page and notice the
question at the bottom. Right now you only answer a question for the
edit - after that you get cookied for the rest of the session.
I’m working on separating the code out into a plugin, and will be
announcing the release on the list and at my blog (in my sig).
The applications detects if the user clicked on “Submit” or elsewhere.
And this saves user’s time of typing weird captcha character.
Just a little proof of concept. This needs a lot of work. Please throw
your inputs.
Having decoy submit buttons is a bit messy.
How about instead having a single submit button, but using Javascript to
calculate a value that’s added to the posted parameters which verifies
the pointer position was over the submit button when it was clicked?
To get a render-independent but varying value you’d probably have to
have
a fixed-size submit button appear at a random position within a
fixed-size
area, though a submit button at a fixed relative position to a marker
element would be all that’s needed for sites other than those for which
it’s worth the spammer’s time to independently tune.
Potential problems:
1, Wouldn’t work with text browsers like Lynx,
2, Wouldn’t work if JS was disabled, and
3, Wouldn’t work for tab-highlight+enter submits.
–
We develop, watch us RoR, in numbers too big to ignore.
Any thoughts?
cognitively disabled individuals, and could also be broken by human
announcing the release on the list and at my blog (in my sig).
Rob
Rob, it would be great if you could offer this as a patch for the Rails
i2 wiki. The amount of spam on that, and the number of hours people
spend rolling back spammed pages, is incredible.
I run a free Christian weblog provider and we fought with spam for
some time. We have a few blind users and did not want to move to
captcha. I implemented what you are suggesting and on the blogs that
require users to do that, spam has went to zero. Just watch your
questions that they are universal and not like what is July 4th.
Someone in Russia could care less what July 4th is for an American.
I agree - it is a never ending battle. However, there is something
strange
about when you start rolling back that you just have this urge to check
all
the day’s activity and finish it off.
I have sent a captcha patch through to Alex at i2 for his consideration
and
posted a test site up that people have been playing with.
It has not crashed or created an error yet so I guess it seems to be
holding
up.
questions/answers differed slightly from site to site, it would be
Hi Steve,
group wiki - so you can see it in action here:
i2 wiki. The amount of spam on that, and the number of hours people
spend rolling back spammed pages, is incredible.
Bayesian filters certainly have helped with my email spam.
I would suspect to show the spammers their spam it would need some way
to
identify the users. I would guess that by IP address would do that as
there
is no current login ability with the wiki.
A login feature would also help and I would imagine over time there
could be
a number of features built in. I would like to see either a question
based
captcha or image based one to start with just to slow down the spam a
little. It is impossible to keep up right now and the wiki is getting
clogged with revisions.
OK, not so much a preemptive defense against spam, but using Bayesian
filters to detect and block spammers that managed to get through your
login
requirements can be very helpful. Bayesian filters are what many email
programs use to “learn” what’s spam. There’s a Rails plugin called
acts_as_classifiable that makes implementing this very easy. Something
that the Joel on Software forums do is not delete to spam, but hide it
from
everyone except the spammer. The spammer has no idea that the other
users
aren’t seeing their spam and therefore doesn’t try to circumvent your
filter. In the mean time you can concentrate one making it harder for
them
to register.
This is something the site I’m working on will have for sure, I just
don’t
understand why so few sites use it?
I certainly plan on using it on Life with Christ (http:// lifewithchrist.org) in which is currently being rewritten in Rails.
We have delt with tons of spam issues on the current site. In
general, it will be a weblog owner’s preference, but they can mark it
as spam which will index the item, then remove it from the system.
Another option exists that will allow users to mark it as spam. Once
X number of unique users hit the “This is spam” button, it will then
be indexed as spam and put into a “Moderation” queue for the owner of
the weblog to finally approve it’s removal.
We have a few blind members on the site and therefore I do not want
to go to Captcha. I did however implement a turing question which has
help tremendously, however, I would like to even remove that if we
can get away with it. Only time will tell.
Jeremy
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.