As part of the second approach, I make it a point to seek out and highlight services that assist and encourage the legal reuse of content. In fact, on Monday I wrote a column for the Blog Herald detailing five sites/services that can help bloggers get images for their posts.

However, when I found out later that day about a new service called Lizzer, which supposedly “is the easiest way to add links and embed content on the Web” I was initially very excited. But as I used the service and saw first hand how it works, my optimism turned to horror as I realized that Lizzer does not enable legitimate reuse of images or content, but rather, encourages both copyright infringement and image hotlinking.

Lizzer, sadly, shares very little in common with the services that I featured in my Blog Herald article and, instead, gives Webmasters, especially those who work with images, a lot of reason to worry.

All Rights Reserved

When I first logged in to my new Lizzer account, I instantly noticed an issue with the service. From the very first page load I could start searching for content. But, while most of the content was innocent, YouTube embeds and links to articles, one of the options was to use a Flickr search.

While that sounds great, without knowing what licensing terms I wanted, the service had no means of telling which images I could use legally. As such, I knew that there was a decent chance it could return images not appropriate for my sites.

Still, I performed a search for the term “plagiarism” and opened up the Flickr dropdown. Below is a snapshot of what I saw, notice the first image, which is highlighted.

It seemed odd to me because I’ve done a similar photo search using Photo Dropper, which filters for my CC licenses, and have never seen this image in the results. After clicking the “Preview” button followed by the “Source” link, I was able to see why. I was taken to this page, where, at the bottom, I saw the following copyright notice.

The image is “All Rights Reserved” and is marked so clearly in the Flickr API. This image should never have appeared in these search results as embedding it could land a Webmaster in trouble should the owner of the image decide to complain.

However, Lizzer wasn’t done. There were still other features to explore and the worst was yet to come.

Hotlinking from Google Image Search

Though the Flickr issue seemed serious to me, it only affected a small number of photographers and artists, namely those who post all rights reserved images to Flickr, and, since Yahoo! was paying the bandwidth tab, it seemed unlikely many would complain.

However, as I looked through the service’s options, I noticed that I had the ability to add Google image search. I immediately cringed because I know well that the vast majority of images displayed in Google Image Search are protected by copyright. Though Google itself is protected by fair use, it is unlikely that any full-sized use of the content by a user of Lizzer would have the same benefit.

I performed a similar search for “plagiarism” and opened up the Google Search list. The results I saw are below. Again, pay attention to the first image, the highlighted image of Bart Simpson.

I once again followed the image to the source and was then taken to this page. Once again, there was no mention of Creative Commons or any other license to use the image. From a legal standpoint, copying and pasting the whole image is potentially very dangerous (Note: I’m completely ignoring the use of the copyrighted character in this work and treating it as a wholly original image for the sake of originality).

However, the real surprise came when I used the fake blog post to try and embed the image. Clicking the link caused the image to appear in the post, exactly as planned, but then I looked at the code that the embed feature created. I saw the following:

The image, as you see below, is hotlinked straight from the original server, in this case, pandemiclabs.com.

In addition to raising a series of issues about copyright infringement and content misuse, we now also have to worry about abuse of resources. If I were to actually use this image code, not only would I be using the image without permission, but I would be using their bandwidth and server resources to do it.

Obviously, a lot of Webmasters are not going to be happy about this. Not only is Lizzer making their content available for use when no license was granted but, in many cases, is encouraging bloggers to hotlink images straight from the original server without permission. The worst part is that, someone using Lizzer, might think that the service is like Photo Dropper or Zemanta and that they have permission to use everything they see.

Clearly though, that is not the case.

Defending Lizzer

In Lizzer’s Defense, the service is currently in alpha and the version that you see today will likely change before the final release. However, a bookmarklet is already available for wide use and works well with all major blogging platforms, including WordPress, Blogger, MovableType, Tumblr, etc. This means that Lizzer is currently in use by at least some bloggers, many of whom are likely unaware of the copyright issues.

Fortunately though, most of Lizzer’s functionality is centered around finding links and videos to embed. Due to the way YouTube sets up their service, disabling embedding is easy for those that chose to do so, an issue that Flickr has not been able to address.

Out of all the search features they offer, only the Flickr search and the Google Image search seem to have any serious issues. However, they are pretty big problems that are both very easy to see and even easier to avoid. Flickr offers an API that allows you to look for CC-licensed work and there are many ways to search for licensed images.

I’m not going to be so bold as to say that finding licensed images is a “solved problem” but it is clear to me that Lizzer is a step backwards from well-established solutions.

However, what is most disconcerting to me is that I emailed Lizzer on Monday to raise these issues. At that time, the Google Images search feature was not working correctly and the hotlinking issues were not present. Unfortunately though, as of this writing, no one has written me back and the Google Image search function has come back online.

Though I grant that Lizzer is currently very buggy, I experienced multiple issues trying to take these screenshots, it is more than usable and that is bad news for content creators, especially those who work primarily with images.

Conclusions

The simple truth is that Lizzer, in its current form, is very dangerous both for Webmasters who publish content and its members that use Lizzer to find content to embed. With so many great tools already available for finding and embedding licensed content, Lizzer not only seems risky to use, but also dated.

Hopefully Lizzer can correct these issues and make itself a respectable content location tool. However, in its current form it not only misses many of the best sources of licensed material, but leads users to embed things that they do not have the right to.

There simply is no reason to use Lizzer right now, there are much better services available. Granted, Lizzer is in an alpha state, but it has already shown a great deal of disregard for Webmaster content and the legal safety of their service.

Unfortunately, in my experience, these aren’t so much “bugs” as they are flaws in the thinking of the developers. Thus, they are much harder to fix.

Hopefully though, they will be able to resolve these issues, for their sake and ours.

Despite running several domains, I am nowhere near my bandwidth limit for my account and am in no danger of going over my allotted 1 TB of bandwidth. I could probably host all of my sites many times over without any problems terms of raw transfer.

Yet, whenever I want to insert media files into my site, be it images or mp3s of the podcast, I seek out alternative hosting. Be it from a photo sharing site such as Photobucket or, my current favorite, a file hosting site such as Boxstr (see update below), I offload these media files as much as practical.

Why do I do this? To protect this site and ensure that, no matter what happens, it stays up. By offloading these media files, I mitigate against not one, but two of the biggest threats that this site could face on the Web and avoid some potential headaches down the road.

The Digg Effect

One of the most obvious reasons for offloading media files is to shield against any sudden spikes in bandwidth use. As a site that has survived two Digg Effects, a Slashdotting, mentions on Boing Boing, an appearance Fark and dozens of StumbleUpon runs, Plagiarism Today has seen what traffic spikes can do and. Fortunately, since the move to Media Temple, this site has survived them all with grace.

However, that doesn’t completely eliminate the threat. After all, if a large image, or worse yet a podcast, hits the front page of Digg that bandwidth can still disappear pretty quickly. Offloading it ensures that, even if the media goes down, the site remains viable and that I am not slammed with overages by my host. That serves me better and it serves the visitors better.

However, the truth be told, even if a large file on my server hit Digg, I could probably survive with minimal trouble. One TB of data would likely take over a million downloads to use up completely.

In truth, the real reason is much trickier and, sadly, much more likely. Worst of all, it is a risk I expose myself to solely by what I write about.

Fair Use and Evildoers

When I started Plagiarism Today, I knew that I was going to be held to the highest standards both in terms of copyright and attribution. There have been many times that I’ve wanted to do something with this site but felt that the copyright issues were just too uncertain, even if others on the Web were doing the exact same thing with no major problems.

However, in recent months, I’ve made a conscious attempt to add more images, videos and audio files to Plagiarism Today and, over all, I think it’s been a success. However, it opens up a new risk. Where the content on the site is written directly by me, the images are usually screenshots of logos, sample images of a site or other demonstrative works used for clarification.

I am very confident that all of my use is well within the bounds of what would likely be considered fair use and certainly well within what one would call standard practices on the Web.

Still, this doesn’t stop someone from filing a DMCA notice. If there’s one thing that I’ve learned from keeping on top of copyright news, it is that the law is generally used for good but, in some cases, can be used stifle free speech.

The mere fact that I am talking about and instructing in the responsible use of a controversial law almost instantly makes me a target for a false notice, a fact made patently obvious by some of the emails and comments I have gotten.

Quite frankly, given the level the hostility has reached at times, I’m only stunned that it hasn’t happened already.

Teaching Me a Lesson

When analyzing the risks of running this site, I decided that there were two types of individuals likely to file a DMCA notice notice against me.

There was no real way to mitigate against the first kind of extremist. Their claim would have no basis on reality and could just file a notice against anything on the site.

I did, however, work to find a host with a fair DMCA policy and I know the person who processes claims here at Media Temple. I am confident that, if it did happen I would be able to keep the site live and that they would not simply “pull the plug” like some hosts.

However, even if my host did shut me down, it would be a disaster for the person filing the notice. As I’ve worked on this site, I’ve come to know and befriend many IP attorneys. Odds are I could find someone to help me go after someone filing a patently false DMCA notice.

Such an event would not be tolerated.

Fortunately, the first possibility is very unlikely. False DMCA notices are rarely random and even those used to stifle unwanted speech are based somewhere in a misconception about copyright law. That makes the second scenario much more likely.

Fortunately, that of notice can be mitigated against much more easily.

Since everything written in this blog is by my hand. There is little chance of someone filing a notice against the text. The blogging application, WordPress, is open source, and both the header image and theme are used with permission and are properly attributed.

The only content on this site regularly used from other locations and without prior approval are the images and some of the content contained in the videos.

Though, as I said above. I’m comfortable that the use is legal, that is not a 100% guarantee against a DMCA notice. That is why it is important to be prepared for the possibility.

Shifting the Burden

The idea is simple. If someone objects to the use of a screenshot on this site and decides to skip contacting me or posting a comment in favor of a DMCA notice, they will be filing against the image host and not the company actually hosting my site.

Yes, the image will go down and it is entirely possible I could lose my account at that company, but the rest of the site will stay up. Even better, all of my images are backed up and can be easily reposted elsewhere if needed. The same goes for the videos and the audio.

In the event of such an attack, Plagiarism Today will suffer no downtime and there will only be a brief outage for the content so long as I am at my computer or nearby when it happens.

This is a pretty basic idea and it is one I started working on shortly after my first encounter with iPowerWeb but only started actively using in recent months as I’ve escalated the amount of images on the site.

However, it is a technique a lot of bloggers could benefit from, especially those that deal with controversial topics that might draw unfair DMCA notices from critics with little concept of how the law works.

Application (And Removal)

To use this system on your site, all you have to do is ensure that you only put things on your server that you have created or have direct permission to use. Anything that relies on fair use, no matter how clear cut it seems, should be hosted elsewhere.

Personally, I use Revver for video, because they have a fair copyright policy and are CC-friendly, and Boxstr for other file types as it allows direct linking and high bandwidth limits without any restrictions (see note below).

I, generally, do not recommend YouTube as their terms of service is overreaching and Flickr is frustrating due to its restrictions on the types of images you can use and requirement that the image be linked back to the Flickr page, rather than to a third party.

Both of these sites have at least the potential to create more IP issues than they resolve by forcing you to give up rights

Conclusions

For all of the hype that they get, false DMCA notices are actually very rare. Your average blogger has very little to worry about them and can probably go about their business relatively secure that it will never happen to them.

But those who deal with controversial subjects or frequently use content under fair use may want to consider using this technique to better shield themselves against the threat of such an notice.

When you consider that decent file hosting is both free and readily-available, there is very little reason to not take advantage of such services. In addition to providing protection against traffic spikes and DMCA notices, it also makes it easier to move your site to a new host (fewer files to transfer) and helps organize and backup the files you use.

All in all, using file hosts is a natural decision for many reasons, it just happens to provide a form of protection against a rare, but potentially devestating, form of attack.

Note: Just before submitting this I discovered that Boxstr has a similar linking requirement to Flickr. I apparently overlooked this when originally signing up for the site as it is worded differently and not made as clear as with Flickr. I am going to transfer my images over to Photobucket but leave the audio files with Boxstr as I already provide direct links with for all audio files.

The announcement has been largely well-received and the addition of statistics was one of the most-requested features according to Flickr.

However, those who are interested in using the new tool to track where their photos are used on the Web and check for violations of their copyright license will be sorely disappointed to know that this new system does not track images that are embedded into other sites.

Though Flickr has still introduced a useful and powerful system that will provide some much-needed insight for its pro members, it missed a golden opportunity to help its users, and the rest of the Internet, understand how the embedding feature is used.

Screwing the Pooch

The problem with Flickr is pretty straightforward. Even if you are comfortable with image hotlinking, as more and more people are, using an image hosting service such as Flickr takes away all control over it.

Since you don’t have access to the server or its logs, you can’t check to see who is using your content and how they are doing so. It is nearly impossible to check and see if the people who are using your images are attributing them correctly or using them in a manner that complies with your license.

Flickr, through this product, had the opportunity to put that information back into the hands of its customers. Since they run the service, it is at least physically possible for them to track embedding and display the information to its users. Since no other photo sharing service I know of does that, it would have put them head and shoulders above any of their competition.

However, for whatever reason, they did not. That seems especially strange considering that Flickr is designed as a repository for artistic work, something mentioned in their community guidelines, and is not just a generic image host.

Artists and photographers, it would seem, would have much more reason to track their content as it is embedded than those, like myself, who use photo sharing sites primarily to embed logos and screenshots.

Combine that with the linking requirement for embedded images and a strong partnership with Creative Commons and it seems only logical that there would be not only a heightened interest in embedding photographs, but an equally heightened interest in tracking and following those embeds.

This omission seems to fly in the face of those initiatives and would indicate that Flickr feels their own site really is the central offering, not the sense of sharing and community spirit.

Whether this is justified or not depends heavily upon statistics and information that only Flickr has and statistics that Flickr will now be holding on to, at least for some time to come.

Conclusions

The decision to limit stats tracking only to pages on Flickr’s site not only provides a very narrow picture of how photos on Flickr are being viewed, but misses out on a great opportunity to obverse, track and understand how the embedding function is being used.

If you want to allow hotlinking but wish to reserve some of your rights, such as attribution or non-commercial use, your best bet is to secure your own hosting account, perhaps on a cheap domain host such as DreamHost and use the server log analysis tools available to you there.

No matter what you do, be sure to follow the image fingerprinting tips I mentioned previously as no amount of hotlink monitoring, or even outright prevention, will stop people from saving the image and re-uploading it elsewhere. In those cases, you’ll need to use other techniques to track your content and fingerprinting can greatly help.

All in all though, Flickr missed a great opportunity to help their pro users not just completely track their images, but monitor their use and enforce their rights.

Hopefully, this is just an initial release of the system and that a future update may add this feature in later. However, Flickr has given no indication that this is case and it appears unlikely that it will be added in the future.

This is frustrating, but just the nature of the beast when you are entrusting third-party services such as Flickr with your precious content.

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.

Generally, however, that power is best left unused. For the most part, restricting people’s access to your site is a bad move. Though you can use your powers to carve out a members-0nly area or prevent others from accessing administrative areas of the site, turning people away from the door is usually unwise.

Still, there are some people that you want to keep out. RSS scrapers and image hotlinkers, for example, offer nothing to your site but instead only steal your content, your bandwidth and your other resources. If you can prevent them from accessing your site in the first place, without impacting other users, it is probably in your best interest to do so.

Fortunately, with Apache’s .htaccess file, it is possible to do all of those things and more. All one has to do is understand a few basics and get the code that they need.

A Quick Primer

According to the Apache Software Foundation, .htaccess is a distributed configuration file that provides “a way to make configuration changes on a per-directory basis”. It is most commonly used when a Webmaster has access to the server, but not the core configuration files for that server. This is typical of most shared hosting environments.

When editing an .htaccess file, there are three important things to remember:

1. .htaccess is the name of the file: In short, htaccess is the extension and there is no file name. This can make editing the file difficult on some computers, but it is important that the convention be followed. If needed, name the file something else and rename it after uploading it to your server.
2. It is an ASCII file: .htaccess is a plain text file and should only be edited in a text editor such as Notepad.
3. It only works with Apache: Though other servers, such as Microsoft’s IIS Server, offer similar features. .htaccess itself is only for Apache-based servers. If you are unsure of what kind of server you have, check with your hosting provider.

Finally, it is important, when working with .htaccess, to back up well and be careful with your edits. A poorly-constructed .htaccess file can render your site useless.

But despite these warnings, .htaccess files are, generally, very easy to edit and manipulate. Furthermore, there is a lot of very good free code ready for you to copy, paste and manipulate to fit your needs.

Stop Image/File Hotlinking

One of the easiest and most basic tasks that can be performed with .htaccess is stopping image/file hotlinking. This is the process by which other sites link directly to your files, either having them display or download directly from their site. This not only amounts to content theft, as well as often plagiarism, but also bandwidth theft as your server spends the resources to serve the file everyone someone on their site calls for it.

According to Zann Marketing, the process is very simple. All one has to do is navigate to their images folder and either create a new .htaccess file or add the following code to their existing one:

RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://yoursite.com.*$ [NC]
RewriteCond %{HTTP_REFERER} !^http://www.yoursite.com.*$ [NC]
ReWriteRule .*\.(gif|jpg|png)$ – [F]

The first line tells the server to turn the Rewrite engine on, the second line instructs the server to check and see if the referrer is blank, the third and fourth line check to make sure that is not from your own site and the fifth line instructs the server to disallow the request for the selected file types if none of the above statements are true.

With this code, you can easily modify it several different ways including:

1. Add New Domains: You can add new domains and sites to allow hotlinking from. The original example from Zann Marketing includes the IP address for Google Images, for example. You can include other search engines as well.
2. Add New File Types: By editing the last line, you can modify your rules to include any kind of file necessary including movie files, documents and anything else you wish to have protected from hotlinking.
3. Disable Access to Blank Referrers: By removing the second line, you can prevent access from browsers and tools that return a blank referrer. Though some scrapers and black hat spiders do this, so do many visitors in a bid to protect their privacy.

Though this method will not stop people from saving your images to their hard drive and uploading it where they please, it can prevent people from stealing both your image and your bandwidth at the same time.

Also, on the original Zann Marketing page, there are examples for blocking just one hotlinker and to redirect hotlinkers to another image, thus pulling the famous “switcheroo”.

Finally, if the process of editing the code seems too daunting, you can also use HTML Basix’s .htaccess code generator to create an .htaccess code set for you to copy and paste into your file.

Blocking RSS Scraping

Equally easy, or in some cases even easier, than blocking hotlinking is blocking RSS scrapers. All you need to do so is determine the IP address of the RSS scraper. (Note: You can use domains if you wish. However, since not all scraping software is located on the domain itself, IP addresses are more reliable).

The easiest way to determine the IP address of a scraper is to use the Copyfeed plugin and have it place the IP address in the scraped content. This not only eliminates the need to translate domain names into IP addresses, but also works in case where the scraping software is located on another server or computer.

However, if that fails or is not an option and the scraped site is hosted on its own domain, you can simply use the IP address for the server itself. To determine the IP address for a domain, simply enter it into a site like Domain Tools and let it get the IP for you. It only takes a few seconds.

If the scraper is using a free service such as Blogspot, you will likely have to look into your server logs and attempt to find traffic on the feed that times out with when the posts go up on the scraper site. It is a risky task to undertake as you can accidentally block legitimate users and it can be very time-consuming on larger sites, but it is the only option in some cases if you wish to use blocking techniques.

No matter what method you use, once you have the IP address, all that is required, according to JavascriptKit, is the following code in the .htaccess file of your feed’s directory:

order allow,deny
deny from xxx.xxx.xxx.xxx
allow from all

Editing the code is easy, all you have to do is replace the Xs with the IP address of the scraper. You can add more lines to as new scrapers emerge and you can also use wildcards by leaving off numbers. For example 123.123.123., would block all IP addresses that start with 123.123.123. This can be useful if a scraper has an IP that changes, but only within a certain range.

It is important to note that this code will block ALL access to your site for that IP address. However, there is very little reason to allow a scraper onto your site as, most likely, they are only accessing the feed anyway.

Also, if you want to redirect scrapers to a fake feed, you can use the method discussed on Hung Truong, which often generates very humorous results.

Finally, once again, if you are uneasy with editing the files yourself, HTML Basix offers another .htaccess generator, this one to block users. It is also useful to stop RSS scraping.

The bottom line is that, once you obtain the IP address of the scraper, it is trivial to block them using .htaccess. All you need is a little bit of understanding and some freely-available code.

Conclusions

Though .htaccess editing can seem very intimidating to a novice, it is actually very easy to do. With the proper tools and a few fundamentals, anyone can manipulate their .htaccess files and use it to their advantage.

Though these manipulations won’t do anything to stop human plagiarism it can stop some of the more common types of plagiarism before they happen, all without impacting legitimate users at all. It makes sense, if possible, to use these methods to your advantage.

However, it is important to note that you are unlikely to find a free host that allows manipulation of .htaccess files. This is, predominantly, the feature of paid hosting companies. Also, it will not work if your images and RSS feeds are on another server, such as Flickr or FeedBurner.

But if you’ve paid for your hosting, it makes sense to use the tools that come with that kind of an upgrade. One of those is the ability to protect your content at the server level.

It is a great power and one that is sorely underused on the Web.