Frustrated that Ken Follett’s book ‘Fall of Giants’ was not available in Spanish on the Kindle, he posted a blog entry on the topic and linked to a downloadable copy of the work available on a file hosting site. This attracted the attention of CEDRO (Spanish Reproduction Rights Center), a group that represents authors in Spain, which in turn filed a DMCA takedown notice with Ricardo and then with WordPress, which eventually took down the site temporarily and blocked Ricardo’s access.

But what makes this case unusual isn’t WordPress’ involvement, it’s how CEDRO claims to have first contacted Ricardo. According to the story, CEDRO didn’t simply email a takedown notice (or a cease and desist) and, instead, they posted it as a comment to the blog entry and, when they didn’t get a reply, they moved up the food chain.

This story raises a lot of interesting questions about sending DMCA notices (or cease and desist letters as it would more appropriately be in this case) via blog comment forms. Unfortunately for CEDRO, I think the reason it took so long for this issue to come up is because it was such a stupid idea in the first place.

Comment Fail

Back in June, I raised the question whether anyone would be willing to send a cease and desist via Twitter or Facebook. The consensus seemed to be that, though these methods of communication are becoming more commonplace, most aren’t comfortable using them for such purposes yet.

But where Twitter and Facebook come with discomfort in using them for such official capacity, comments raise still more issues.

The problem is that comments on a blog post are not necessarily directed at anyone. Where I can send a private message on Facebook or an @reply on Twitter, a comment on a blog entry is just a reply to the post and not necessarily directed at anyone. It could be at another commenter, the blog author or no one at all.

As such, it’s hard to claim that the notice was actually or effectively delivered. It’s a bit like posting the notice to a public bulletin board near a person’s home and expecting them to read it. While public notice is a part of the law, it’s for cases where the public at large, not a specific person, most be notified of something (name change, certain auctions, etc.).

While cease and desist letters and DMCA notices are not official documents in that they do not need to go through the service process, there needs to be at least some proof of receipt as ignoring these notices can have implications on a potential legal case.

It would be very difficult to prove that someone was given adequate notice with just a comment posted to their blog, especially if it is a high-volume blog.

However, that is just the tip of the iceberg with the problems with this method.

Other Problems

In addition to the obvious issues with serving any kind of notice through a comment form, there are many other reasons why a comment form would be a poor choice for such a notice.

1. Spam Filtering: Though email accounts have spam filters, they seem to do a much better job eliminating false positives than comment ones, making it more likely that such a comment would be junked. Furthermore, you have two spam filters to deal with, the comment one and the email one, meaning that even if the comment goes live, the owner might not be notified.
2. No Authentication: How is a blogger going to confirm who wrote a comment? With so many trolls on the Web it would be easy to dismiss such a comment as not being from a valid source, especially since the means is so uncommon. This makes it less likely the site owner will respond in a favorable way.
3. It’s Public: Though no one should be ashamed of doing reasonably copyright enforcement in the public light, taking matters so pubic, especially right off the bat, basically ensures a more negative response. A polite, private message usually gets the best response.

However, the biggest issue of all is that there was no reason to file with Ricardo at all. The file host involved, MegaUpload, does respond to takedown notices and likely would have removed the work quickly. That would have cut off the problem at the source and not further downstream.

In short, rather than damming a river, they simply tried to dam one of its forks, not a good move to stop the water.

Bottom Line

To me, it almost sounds like CEDRO was trying to pick a fight. I can’t imagine a rights group with as much experience as CEDRO making a decision like this. If it were someone with no experience in enforcement, it would be an understandable mistake but this is a rights group that is no stranger to this area.

What the purpose of this was, I can not be sure. I was able to easily find Ricardo’s address (even I know what “contacto” means in Spanish) and it seems a better resolution was a simple email away. Instead now they have an ugly mess on their hands and the artist’s rights are no better protected.

All around, this seems to be a boneheaded move and one I hope other copyright holders do not repeat.

reCAPTCHA is still holding the comment spam at bay and I have swapped out Akismet for Defensio in hopes of reducing the number of trackbacks that seep through.

So far that move has been a stellar success, in the first four hours of operation, Defensio has had a perfect accuracy. However, what is stunning is the statistics it has also collected.

Striking Numbers

I installed Defensio on this blog at about 8:30 AM central time this morning. Now, less than four hours later, Defensio has already caught over 200 spam comments.

If this pace is maintained, then that will represent well over 600 spam comments and trackbacks today. Though it is reCAPTCHA, and not Defensio, stopping the comments. what is stunning is the increase in activity this represents.

Typically this site has gotten its fair share of comment spam, but it has usually been well under a hundred per day. By my estimation, with a daily average of about 50 per day before, this represents a 12-fold increase in comment spam, almost overnight.

Conclusions

The defenses are holding now but I will keep a close watch on Defensio to make sure that it doesn’t trap legitimate comments or let any spam slip through. I’ll definitely report back, likely after the holiday, about how it has done.

Hopefully though this 100% accuracy trend will continue.

In addition to responding to a comment on a post from last week, he alerted me to a copyright case involving Tickmaster (TM) and RMG Technologies. According to the complaint and subsequent injunction (embedded below), RMG produced an application that allowed users to bypass a CAPTCHA system on TM’s site, thus enabling users to easily purchase thousands of tickets before actual humans could even get into the system.

According to the judge, this not only likely constituted an infringement of TM’s copyright, breach of contract and a violation of the computer fraud and abuse act, but also a violation of the DMCA anti-circumvention rules.

This ruling, if it actually stands up through the entire legal process, could have major implications for Webmasters who rely on CAPTCHA technology, including this one, and could introduce new ways to protect content on the Web, especially against automated tools such as scrapers.

Background

The anti-circumvention provisions of the DMCA are, with little doubt, the most controversial portions of the law. They are the portions that make it illegal to circumvent technological protections in order to gain access to copyrighted material as well as the providing of tools to circumvent either access or copy controls.

These rules have created a tremendous backlash due to their effect on fair use. Since it is a crime merely to produce tools that can circumvent copy protection schemes, copyright holders can lock down a work and prevent all use of the content, even use that would have likely been deemed fair if taken to court on its own merits.

However, this case put these provisions in something of a new light. According to the injunction, the CAPTCHA that TM used to protect its purchase pages constitutes a an access control mechanism and the page behind it is a copyrighted work. Thus, RMG’s software, which was designed to circumvent that CAPTCHA, amounts to a violation of the DMCA and, looking at the ruling, there seems to good reason to think that this logic will hold up.

In short, CAPTCHAs might not just be a form of protection against spammers and bots but might also themselves be protected under the DMCA.

A Tricky Application

CAPTCHAs are one of the most popular forms of site protection. They are used by everyone from Google to brand new blogs. Obviously, any additional legal protection CAPTCHAs can get will be a very big deal.

However, the TM case is a fairly unique one. Most bloggers use CAPTCHAs to protect their comment forms or emails, not multi-million dollar purchasing systems. To determine where a more typical use of CAPTCHA might fit in with with the DMCA, we first have to look at what one would have to prove to make such a claim.

1. Ownership of a valid copyright on a work.
2. That is effectively controlled by a technological measure, which has been circumvented
3. That third parties can now access.
4. That those third parties are unauthorized in their access
5. That the access infringes a right protected under copyright law.
6. And that the defendant made the product primarily for the purpose of circumvention, made it available despite limited commercial significance or promoted it as a tool for circumvention.

For most bloggers, the first two requirements are the greatest challenge. Though we use CAPTCHAs to protect comment forms and even our email addresses, neither of those things are copyrightable. One might claim the comment backend as being a copyrighted work, similar to Ticketmaster, but very few bloggers create their own platform meaning they don’t hold copyright in the code they use. Besides, it would be hard to call these files “effectively controlled” as most of them can be accessed directly from the Web.

Even if the blogger protects an email address with a CAPTCHA, that is just information and is not considered copyrightable.

The only exception would be if a blogger actually used the CAPTCHA to protect a copyrighted work. For example, if a CAPTCHA were used to protect a large MP3 file from leeching and another Webmaster implemented a service to let their users bypass the CAPTCHA and download the file directly.

These situations can and do happen, but are exceptionally rare. Fortunately, there are other laws, many of which we talked about when discussing scraping, that better fit this kind of abuse.

Still, there might be a place for these kinds of tactics, just not with your average blogger.

The Big Guns

The question becomes who could make the best use of this ruling? They would have to be someone who met the following criteria:

1. Used CAPTCHAs heavily
2. Protected copyrighted work they had ownership of with them
3. Has the resources to target those who build such tools

Clearly, the list is short but the obvious answers are any of the big three, Google, Yahoo or Microsoft.

Of those three, Google fits best as they make very heavy use of CAPTCHAs, especially on Blogpsot, are frequent targets for circumvention and seem to be struggling to stay ahead of the software. However, it seems unlikely that they would use the law in this manner considering their hostile attitudes toward the DMCA in general.

However, any other company that meets the standards could certainly benefit from this case. It seems to only be a matter of time before a blogging platform takes advantage of this ruling in order to go after comment spammers and, possibly, scrapers.

After all, the DMCA not only applies to CAPTCHAs, but any other technological measure used to protect copyrighted works. I can think of many hosts and Webmasters eager to take advantage of that prospect.

Conclusions

I’m no fan of the anti-circumvention provisions of the DMCA, I want to make that clear. Also, I want to make it perfectly clear that this discussion is purely theoretical and academic and not an indication of a future legal strategy by any entity including Google, reCAPTCHA or anyone else mentioned in this. The best defense against CAPTCHA cracking remains better CAPTCHAs.

Still, even a bad law can be used for some good. Though I am no fan of walled gardens either, they are necessary sometimes. To that end, protecting the content behind a technological measure, such as a CAPTCHA, greatly increases the legal options you have should someone circumvent those protections.

However, the place this is most likely to assist bloggers and Webmasters is in the area of image and file hotlinking. If you use a technological means to prevent such hotlinking and another site circumvents those protections, there is a good chance it would be a violation of the DMCA, giving you legal ammunition above and beyond just traditional copyright claims.

In short, if you are going to restrict access to your content for any reason, make sure to protect it with technology that would have to be circumvented to gain access to it. Not only will this prevent a great deal of the infringement it could also greatly improve your legal options should an infringement occur.

I might disagree with that decision personally, but there is little doubt that, legally, it could open up some new doors.

Though it doesn’t have much to do with content theft, I have several reasons for wanting to cover this. First many of the RSS scrapers and spam bloggers also use this technique to supplement their work. Second, in some cases, the spammed comment contains scraped content, either from your site or others making it an infringement. Finally, it is an issue that is dear to the target readers of this site, bloggers and Webmasters.

Though WordPress’ reputation against spam blogs has been almost impeccable, it has proved to be very vulnerable to comment spam. This has given rise to an entire cottage industry of anti-spam plugins and most of them, in my experience at least, have been ineffective.

This lead me, about a month ago, to disable comments on all old posts. However, I have since backed away from that position because, among other reasons, it simply was not working.

The most effective comment spam plugin I know of, Akismet, is made by Automattic, the operators of WordPress.com. It is a generous gift to the community and it comes at what must be great expense to Automattic since it works by letting their servers filter the millions of comments that get submitted. However, it is not perfect, by Automattic’s own admission, and it does not stop the comment spam from going through, just from appearing on the site.

Unfortunately, WordPress’ problem with comment spam runs much deeper and it renders nearly 99% of all anti-spam methods useless. However, a change on the backend could, potentially, fix that and change the comment spam game forever.

How a Comment Gets Posted (and The Problem With It)

A comment in WordPress works just like any other form.

You most likely have a comments.php file in your template that represents the actual comment form. That is embedded into your post pages via a template call. The comments.php form, upon submission, sends the comment to another file wp-comments-post.php, which sends the comment up the chain of commands and, eventually, places it in the database.

It is a simple form that works like any other. It is also the same process as when you send an email via a Web form or post a forum. However, the problem is that, with WordPress and other spam-prone applications, the backend does not know what the frontend is doing.

Basically, with the default install, wp-comments-post.php has no way to confirm that the comment has come from comments.php or anywhere else on the domain.

Spammers, being the clever lot that they are, simply started calling the wp-comments-post.php without ever visiting the site itself. They simply call the file with a specially-formatted address and, magically, a comment is submitted though the bot never set foot on the actual post page.

This is bad news for WordPress users as nearly all spam counter measures rely on modifications to the comments.php file to work. This includes most captchas, spam questions and even some comment disabling plugins. The spammer simply bypasses those measures, leaving only post-submission filtering to weed out the junk from the real comments.

Though, on most sites, that is a fairly effective approach, sites with large volumes of spam, such as this one, might find it unacceptable. Not only does it mean that some spam is destined to escape the filters and go live, but it can put a strain on the sever, even if, as with Akisment, most of the filtering is done elsewhere.

Furthermore, if email spam has taught us anything, filtering systems are prone to the “better mouse” problem. If one clever spammer finds a way to game the system, the hull will have been breached and all could be flooded.

How Bad Is It?

The problem is rampant. Consider this screenshot taken from my own site stats yesterday.

You can see that the wp-comments-post.php file is the fourth most called file on my server (Note: Both share-this.php and the ajax-edit-cooments files are often called multiple times in a single page, thus why they are so high.). A quick check of the comment count shows that there is no reason for that to happen.

There are hundreds of hits per day on that file, most of which never access the site itself.

This has led to a whole slew of solutions to the problem. The first is to simply rename the file. However, spammers have grown wise to that method, detecting the new name in as little as ten hours.

Another is to edit your .htaccess file to block visitors from accessing the wp-comments-post.php file without first visiting your domain. I implemented this myself on Plagiarism Today but, while my comment spam volume decreased some, it did not stop. Spoofing a referrer is pretty trivial and it seems that most comment spammers are already doing that.

Yet another hack involves increasing the time between comment submissions, a method that works to stop spammers that “flood” your comments, but does nothing to stop spammers who post once and then come back at a random time later to post again.

One final method, which I ran across some time ago but have been unable to locate again for this article, involved inputting code into the comments.php file that would then be verified by the wp-comments-post.php file. Though it was a messy edit that involved hacking both files, it would have been, theoretically, effective. Once I locate the hack again, I will try it and see if it does indeed work.

In the end though, short of hacks and server alterations, there is no way to prevent this kind of injection. Since almost all plugins deal only with the comments.php file, there is no simple way to effectively block this kind of abuse.

Fixing the Problem

This problem is not unique to WordPress by any stretch of the imagination. None of this should be taken as a criticism of WordPress or its developers. This problem is present on other blogging platforms, message board applications and nearly anything that accepts input from the outside world and posts it to the Web. WordPress merely happens to be what I use and what I am most familiar with.

That being said, there needs to be a fix for this problem. There needs to be some way for the backend, wp-comments-post.php, to ensure that the comment actually came from the frontend, comments.php.

One solution involves using a generic anti-spam question in the comments file but then hacking the wp-comments-post.php file to die if the answers to not match. Thus, anyone calling the backend directly without knowledge of the question would get an error.

However, a static method, like the one described in the post, could be easily beaten by a spammer just adding the variable to their software. A more random implementation, such as the one described in the comments, would provide more protection but could still be figured out if needed since computers are very good at math.

I am not a programmer, but what seems to be needed is a means for the two files to handshake with one another in a way that a spammer can not crack. One example might be to create a hash of the comment using a key that exists only on the server. Another would be to use a pseudorandom variable such as a random number generator, the time on the CPU clock or anything else the two files could share. Another idea would be to have the backend check the WP log and ensure that, at the very least, the IP address involved visited the post page in question before commenting.

(Note: The above suggestions are offered “off the cuff” and probably would not work. Please post suggestions and ideas in the comments.)

This would not be easy. It might require rethinking the entire comment posting process, but certainly there has to be a way to at least improve the situation so spammers can not, with easy, abuse the system.

I am open to any and all suggestions on the process. Please comment below if you have any thoughts.

Some Brief Good News

I did, recently, run across some good news in this fight. I installed reCAPTCHA on my blog a few days ago as an experiment. Though it didn’t stop the flow of spam comments, it did improve Akismet’s accuracy greatly.

It appears that, for whatever reason, Akismet has an easier time dealing with comment spam when it comes almost solely from the backend. Since I installed reCAPTCHA, I have not had any spam comments go live or enter the moderation queue.

I plan to continue the experiment for at least a few more days to see if that trend continues.

(UPDATE: I just received an email from Ben Maurer, the tech lead on the reCAPTCHA project, he said that reCAPTCHA counts the spam as it eats as spam in WordPress, that could explain why Akismet seems to be so accurate. Still, what intrigues me most is that no spam has gotten all of the way through. It seems logical that reCAPTCHA is blocking the spam that actually uses the form, which was the spam getting through from time to time, while Akismet easily handles the spam directly injected through the backend.)

(UPDATE 2: As my education on reCAPTCHA continues, it appears that the plugin DOES validate against comments injected into the backend. That officially makes this my favorite anti-spam plugin.)

Conclusions

Closing this backdoor will not be easy nor will it obliterate comment spam. However, channeling it through the traditional forms makes it possible to apply various Turing tests to weed out the bots.

In short, it won’t put an end to comment spam or replace filtering, but at least it will add an extra line of defense.

Right now, WordPress users are just one clever spammer away from a tidal wave of spam. If someone can find a way to beat Akismet and other spam filtering plugins, there is no backup plan.

Perhaps now, while the situation is somewhat in hand, it is time we started working on one.