Cloaking Detection?

drcrja asks: "I am conducting some academic research on the use of cloaking and how it affects search engine rankings (cloaking is the practice of delivering a specially optimized page to search engine spiders while delivering a completely different page to the user). I am currently using Alta Vista's Babel Fish to retrieve pages and compare those pages to the pages on the actual web sites but I am trying to find other methods of detecting cloaking. I am wondering if any members of the /. community have any experience with this?"

Comments

Re:Just follow the ion emissions

[irony nazi]

Well, that is the way to detect Vulcan cloaking, but in order to detect website cloaking, try some variation of the following:

Ingredients:
Computer
Perl
Internet Connection
LibWWW, UserAgent, and all the dependencies, I forgot which
Optional: Perl Cookbook, by Christianson and Torkingham.

Directions:
Start with the Perl Cookbook to give you a quick background of how to design an autonomous www agent that will crawl around gathering webpages. You can have them visit links or read from a list of links or whatever you want.

Read the documentation from the Perl UserAgent libs and figure out how to change the http headers to spoof various browsers. I've done this before. I think that I ended up going into the UserAgent code and doing this manually. I don't remember exactly how I accomplished this, I just remember that it was easy.

Now have to agents to crawl websites and compare output from one website using the "Spider" http headers with the output from spoofing the "IE" http headers. Websites would sometimes still think the IE headers were a robot. The key is to pause the request so that it is as though a human is reading the page/clicking the links/etc.

Keep track of the sites that are different or keep track of whatever stats that you need.

Mix, Stir, Burn, Enjoy.

I've actually done this type of thing before in order to test various IE only websites on non-IE browsers (non-MS computers). My results were that all of the pages the *require* IE render perfectly in Mozilla and most render fine in Opera. I still don't understand why businesses would *turn-away* potential customers only for having different http headers!

I'd make or modify an existing program to do this

[stienman]

I imagine wget or another HTTP client can be coaxed to spit out the spider and browser type strings associated with search engine spiders. It would be a simple, straightforward hack to make a script that would request a page twice, once reporting itself as a search engine (and requesting the robots.txt file for good measure) and secondly as a regular browser. Then do a simple compare.

You could give it a list of sites and it could go through dozens or hundreds of sites a minute, rather than you doing it by hand. You could have it save pages that show differences, or at least give you the URLs so you could load them later and study the differences (if that is a goal).

You could use PHP, perl, java, etc to do this very simply as well. I imagine a simple PHP script could well be less than 50 lines, and could even call your browser and load the two pages side by side each time it found a difference.

-Adam

Use Konqueror

[JabberWokky]

Use Konqueror and set your UserAgent to that of a search engine spider. I'm sure this can be done with most any web browser - in Konqueror, just go to Tools/Change Brower Identification. You'll probably have to add a new one (for some reason a spider userid string isn't common enough to be a standard one) - you can do that in Settings/Configure Konqueror/Browser Identification.

--
Evan

Re:Use Konqueror

[QuodEratDemonstratum]

Some lists of useragent strings are here and here.

Problem

[epsalon]

Some sites may apply cloaking based on the IP addess of the spider.

I suggest using Google's cache as a method to detect cloaking. The advantage is that the page cached is exactly the same page used for indexing, and google is the most popular search engine, and thus you win.

Re:Just follow the ion emissions

[penguinboy]

Read the documentation from the Perl UserAgent libs and figure out how to change the http headers to spoof various browsers. I've done this before. I think that I ended up going into the UserAgent code and doing this manually. I don't remember exactly how I accomplished this, I just remember that it was easy.

It's quite straightforward:

my $ua = LWP::UserAgent->new;
$ua->agent("Whatever 3.11/sun4u");

I do this for one of my sites

[Karora]

I make fairly extensive changes to one of my sites for search engines.

Things I do are:

• Make the content more easily indexible.
• Reduce the numbers of links to the same content.
• Present the variable content first

I have had a number of problems with badly behaved search engines basically DoSing the site as well.

Many search engines are easily identifiable by looking at the HTTP_REFERER, but for some of the stealthier ones you have to identify them by source IP, and of course the technique is only ever going to be 95%.

I really limit the options down and make the site look much like one of those old hierarchical sites of old. After all, the search engine is going to see the whole lot of it and I'm sure it is easier for them to navigate a tree without redundant processing since most of the site navigation is about providing multiple content categorisations of what is basically the same content.

To the poster of the question.

[perlyking]

I recommend you look at Webmasterworld there is a massive amount of knowledge there.
One of the guys from google even posts there on occasion.

Good reasons to vary response

[Martin Spamer]

(cloaking is the practice of delivering a specially optimized page to search engine spiders while delivering a completely different page to the user).

There are good reasons for a site to respond differently to different clients. Indeed responding to the capabilities of the client should be considered 'best practice'.

There are a host of client types out there other than just PC Browsers and Robots, IDTV STB's, 3G & WAP Phones, Convergent devices. The range is set to explode.

This is the whole reason for the Http 'Accept' header, which is provided to allow a server to handler clients with different capabilities.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec1 4. html

Cloaking

[SplatFileGoo]

> sometimes google cached copies of pages might be informative.

Look at all the trouble Google is finding itself in with the "cache" (term used loosely since Google doesn't "cache" pages - they "page jack" them and put their own self advertisments on them). It's a ticking time bomb.

Tick, Scientologists,
Tick, German railroads,
Tick, Ok who's next?

> cloaked pages because it comes from
> a different IP than altavista'a index bots

Alta spiders from the Babelfish ip too. They switched the ip last year just to rat out cloakers.

> You can retrieve cached pages from
> Google using their new SOAP API.

Not if the webmaster has used the NOARCHIVE tag (which itself is probably cloaked if done properly).

> Indeed responding to the capabilities of the
> client should be considered 'best practice'.

Absolutly. Language differences, display differences, and various levels of css/dom/scripting support are all quality reasons to cloak. I have a site that deliver 8 different versions of a page based on ip and agent.

There are also cloaking programs sponsored by the search engines themselves. Inktomi's index connect, and Altavista's "trusted feed" programs encourage the cloaking of pages to protect them.

Did you know every major search engine cloaks their own site? Here's one that is agent cloaked by Google themselves: http://wap.google.com . If you don't have the right secret decoder ring, all you will see is stock Google.

--

>LibWWW

lol. No cloaker worth his salt would agent cloak for se purposes today. It's all 100% IP based detection. Unless you are parked on a searchengine ip address, you won't know what you are looking at.

With se's moving to off-the-page criteria (links and contextual themes such as google, teoma, and wisenut) this whole discussion is moot.
Cloaking for search engine purposes is rather rare anymore.

The hay day of cloaking was 99 when their was so much page jacking on Altavista. If you had a top ranking page, it was sure to be ripped off by afternoon and your rankings destroyed in the next update. In that environment, cloaking skyrocketed.

Now that Alta is a dead search engine walking, Inktomi requires fees, and all that is left is Google - it just doesn't make economic sense to cloak. Even if you can cloak, it does very little good and you really, really have to know what you are doing.

How I've seen it done

[The Bean]

I know of a company that used to make a living doing exactly this type of thing. The biggest thing for them was checking for requests for robots.txt. Once it detected a request for this the IP was placed in a database for future reference. They owned a large number of domains, and made up many pages containing the keywords that the client wanted their site to "show up under," with links between them all. These pages were served to any client that had previously requested the robots.txt file. But when a request for one of the pages was received from an IP that hadn't requested robots.txt, they were bounced to the clients site.