> Please don't use inflammatory language like "intellectually bloody
> lazy" and "slap a captcha on" to characterize what I've done. Do not
> denigrate my hard work that way, please. That is rude, especially
> since you do not seem to have actually looked at the code.
Sorry, didn't mean to comment on your code in particular - I just wanted to
vent my frustration at the generic intellectual laziness of many people who
just slam a captcha on their blog or web site and thinks that solves
everything. I've fought so many bad captcha implementations or totally
indecipherable pieces of text that I am often repulsed and leave the site in
disgust.
I really, really dislike that, and I was *proud* of the way our Captcha worked
in a completely nondisruptive way, and I was very surprised to see it removed
without a warning, question, or even a review request.
The code looks otherwise good, but I just thing it breaks down a good model and
replaces it with an inferior one.
> The idea with the revised CAPTCHA system is -- indeed -- to put it on
> the same form as the editor. That's quite common (and expected!) with
> many blogs these days -- as you noted. I don't perceive that as
> disruptive in the way that you seem to.
Not all things that are commonly done are the best possible. I think our way
was actually better, because it
* is less disruptive to the edit flow
* makes the editor display smaller and less complex
* allows for use of really complicated captchas (like Asirra), or even
multi-step or off-site captchas
* works well with a spam filtering system which can score (we can do multiple
levels, e.g. "no spam", "check with captcha", "check with really complex
captcha", "spam, no need to even ask")
* slows down a spammer (as he can't simply just keep retrying a simple POST, he
needs to go build a fairly complicated engine to follow through this one).
* it is a clear competitive advantage against other wiki systems with
technically inferior spam/captcha solutions
The whole thing was *thought out*.
> CAPTCHA later? I think it's better to put it on the same screen
> ("CAPTCHA-with-post"), rather than the "CAPTCHA-after-POST" process
> like the one you suggested.
Why is that better? Adding Asirra on the editor screen makes it simply HUGE,
and makes editing really hard (in order to save, your click count goes through
the roof - you need 400% more clicks just to save a page.)
Our spam filtering is already extremely efficient (stops several hundred spam
edits on jspwiki.org every day). I don't see why we should add extra burden on
the user when we already have very good automatic methods?
> But if we did a CAPTCHA-after-POST, it would logically be done via the
> SpamInterceptor (which would return a ForwardResolution to a Captcha
> display JSP if the threshold was exceeded). The workflow classes
> aren't useful for something like this.
The reason why I thought the workflow classes would be useful is that we could
also flag potential spam edits into the workflow acceptance queue. So either
the edit acceptance could be done by a moderator or a captcha. Or even both.
But as I said, I don't really understand the workflow classes at all, so your
proposed solution sounds much better. :-)
/Janne
