CommentAPI Circumvents CAPTCHA

Just so we’re all clear about this, the convenience of the CommentAPI, that nifty little service that allows users to make comments to your blog from the comfort of their favorite RSS aggregator, comes at a cost. Enabling the CommentAPI supplies a back door for comment spammers who want to bypass the CAPTCHA guard posted at the front door.

I was just chatting with Andrew about this and we realized it would be quite easy to add CAPTCHA support to the CommentAPI if we could get both RSS Aggregator developers and blog engine developers to agree on how to update to the CommentAPI to support a CAPTCHA image url or a CAPTCHA text question. The RSS Aggregator would then display this image or text, and provide the user a field in the comment dialog to supply the answer to the CAPTCHA challenge, which the CommentAPI would validate with the CAPTCHA control. Of course this wouldn’t close the CAPTCHA backdoor for Trackbacks and Pingbacks.

In the meantime, I tend to favor non-CAPTCHA approaches to comment spam filtering for this very reason. I want to fight comment spam tooth and nail with every resource I have before I turn off the CommentAPI on my blog. Likewise, I still support Trackbacks because I personally have found them more beneficial than detrimental so far.

In any case, Subtext will provide configuration options to turn each of these services on or off individually so that users have full control of comment entry points.

Comments

8 responses

Sharp as a Marble • June 12th, 2005
Crimminy, I'm getting bombarded by Trackback spammers now. Maybe I should go ahead and switch over...

Haacked • June 12th, 2005
Yeah, I've been bombarded too. I've not switched over yet because I've been too busy, but also as research. :)

I've noticed that most of the bombardments are a result of automated scripts that simply post the same thing over and over. Subtext will handle that well now.

However, I haven't implemented turning off and on CommentAPI, trackbacks, and pingbacks on a granular level.

I did add a HostAdmin table to store the password, removing the stupid issue I left in there from before.

Sharp as a Marble • June 12th, 2005
"However, I haven't implemented turning off and on CommentAPI, trackbacks, and pingbacks on a granular level."

*cough*granularsecurity*cough*...

Which, by the way, is still on my plate. But it's 5 weeks and counting before the new rugrat. So I better hurry! ;)

Dimitri Glazkov • June 13th, 2005
By the way, Trackback spammers are getting on my last nerve. Is there a number I could call to have them tracked down and their kneecaps busted?

Finally, another half-rhetorical question. In your mind, is there any chance of acceptance at all by the blogger communityby the blogger community for a unified authentication/trust expression architecture, whichever form it might take?

Haacked • June 13th, 2005
Hey, you're the russian. I figured you'd know someone back east. ;)

As for a unified authentication/trust architecture, haven't you heard of Microsoft Passport? ;) I jest.

I don't know of any. I don't think the community trust each other enough to build a trust architecture. ;)

There are several ideas that improve trust though.

Whitelisting whereby anyone you've allowed to post before automatically can post again. Blacklisting is an obvious approach, but do it based on the posted urls and the IPs for the urls and not just the referrer (as that can be spoofed. Everything can be spoofed).

I've thought about doing something where you automatically trust trackbacks from anyone in your OPML. etc... etc...

The weakness in all these approaches is how do you authenticate people without being too intrusive?

You could go the fort knox approach and require people create accounts with a valid email address (which you confirm via an email and confirmation link).

But for most of us, that would essentially turn away everybody. Then, you have people who would provide insightful comments not even trying, and that leaves only comment spammers trying to post comments on your blog.

I've written about this before (https://haacked.com/category/15.aspx), but maybe I should write an updated post now that I've spent more time in the trenches.

vern • June 13th, 2005
I LOVE the idea of "whitelisting" those in my OPML!

But, that would only take care of about 3-5 people in my case.

Still, should be considered.

Ryan Farley • June 14th, 2005
I would prefer, instead of a CAPTCHA for validation, to have a blacklisted words list. So any comment posted, whether via the webpage for the post or via CommentAPI would throw back an exception or message if a post contained a disallowed word. Similar to how an e-mail spam filter might work, looking for any blacklisted words and rejecting the item if any are found. The user could maintain the list of blacklisted words in the Admin sections to add new words to the list at any time to add words to match the latest wave of comment spam. This way, the same blacklisted words list would be used no matter how the comment was posted. To me that seems like the most logical approach.

-Ryan

Ryan Farley • June 14th, 2005
BTW, if you went the route of using the blacklisted words approach, the maybe you could even have an option to disallow trackbacks with blacklisted words in the url too. Just an idea...

-Ryan