How Spyware-Driven Forced Visits Inflate Web Site Traffic Counts

The usual motive for buying spyware popup traffic is simple: Showing ads. Cover Netflix’s site with an ad for Blockbuster, and users may buy from Blockbuster instead. Same for other spyware advertisers.

But there are other plausible reasons to buy spyware traffic. In particular, cheap spyware traffic can be used to inflate a site’s traffic statistics. Buying widespread “forced visits” causes widely-used traffic measurements to overreport a site’s popularity: Traffic measurements mistakenly assume users arrived at the site because they actually wanted to go there, without considering the possibility that the visit was involuntary. Nonetheless, from the site’s perspective, forced visits offer real benefits: Investors will be willing to pay more to buy a site that seems to be more popular, and advertisers may be willing to pay more for their ads to appear. In some sectors, higher reported traffic may create a buzz of supposed popularity — helping to recruit bona fide users in the future.

Yet spyware-originating forced-visit traffic can cause serious harm. Harm may accrue to advertisers — by overcharging them as well as by placing their ads in spyware they seek to avoid. Harm may accrue to investors, by causing them to overpay for sites whose true popularity is less than traffic statistics indicate. In any event, harm accrues to consumers and to the public at large, through funding of spyware that sneaks onto users’ PCs with negative effects on privacy, reliability, and performance.

Others have previously investigated some of these problems. In December 2006, the New York Times reported that Nielsen/NetRatings cut traffic counts for Entrepreneur.com by 65% after uncovering widespread forced site visits. But forced-visit traffic is more widespread than the four specific examples the Times presented.

This article offers six further examples of sites receiving forced visits — including the spyware vendors and ad networks that are involved. The article concludes by analyzing implications — suggested policy responses for advertisers and ad networks, as well as ways of detecting sites receiving forced visits.

Example 1: IE Plugin and Paypopup Promoting Bolt.com

IE Plugin Promoting Bolt.com IE Plugin Promoting Bolt.com

In testing of April 23, I browsed Google and received the popunder shown at right (after activation) and in video. Packet log analysis reveals that traffic flowed as follows: From IE Plugin (purportedly of Belize), to Paypopup (of Ontario, Canada), to Paypopup’s multi-pops.com ad server, to Bolt (of New York). URLs in the sequence:

http://66.98.144.169/redirect/adcycle.cgi?gid=9&type=ssi&id=396
http://paypopup.com/adsDirect.php?cid=1133482&ban=1&id=ieplugin&sid=10794&pub…
http://service.multi-pops.com/adsDirect.php?ban=1&id=ieplugin&cid=1133482&sid…
http://service.multi-pops.com/links.php?data=rSe_2%2F%FE%2F1%285%FE1%2F%2B%24…
http://service.multi-pops.com/linksed.php?sn=851177371957&uip=…&siteid=iepl…
http://www.bolt.com/

As shown in the packet log, this traffic originated with IE Plugin’s Adcycle.cgi ad-loader. This ad-loader sends traffic to a variety of ad networks, as best I can tell without any targeting whatsoever. Users therefore receive numerous untargeted ad windows, typically appearing as popups and popunders.

The resulting Bolt window appears without any attribution or branding indicating what spyware caused it to appear. This lack of labeling makes it particularly hard for users to figure out what program is responsible or to take action to stop further unwanted ads. IE Plugin’s unlabeled ads are particularly harmful because users may not have authorized the installation of IE Plugin in the first place: I have repeatedly seen IE Plugin install without user consent, including via bundles assembled by notorious spyware distributor Dollar Revenue.

The packet log indicates that Bolt purchased traffic not from IE Plugin directly, but rather from Paypopup. But Paypopup’s name and product descriptions specifically indicate the kind of ads that Paypopup sells forced visits — popups that appear without an affirmative end-user choice. The inevitable result of such traffic purchases is to inflate the measured popularity of the beneficiary web sites. So even if Bolt did not know it was buying spyware-originating advertising, Bolt must have known it was receiving forced visit traffic.

The packet log also shows that Paypopup specifically knew it was doing business with IE Plugin. Notice the repeated references to IE Plugin in the Paypopup and Multi-pops ad-loader URLs (“id=ieplugin”).

Bolt’s “About” page includes a claim of “reach[ing] 14.9 million unique visitors each month.” Taking this claim at face value, Bolt’s relationship with Paypopup and IE Plugin begs the question: How many of Bolt’s visitors are forced to see Bolt because spyware took them there, rather than because they affirmatively chose it?

Meanwhile, Bolt boasts top-tier advertisers including Verizon (shown in part in the screenshot above), Coca-Cola, Nike, and Sony. These brand-conscious advertisers are unlikely to want their ads to appear through spyware-delivered popups.

Example 2: Yourenhancement, Adtegrity, Right Media Exchange, and AdOn Network (MyGeek) Promoting PureVideo Networks’ GrindTV

Yourenhancement Promoting GrindTV Yourenhancement Promoting GrindTV

In testing of April 29, I browsed the web and received the full-screen popup shown at right. The popup was so large and so intrusive that it even covered the Start Menu, Taskbar, and System Tray — preventing me from easily switching to another program.

Packet log analysis reveals that traffic flowed as follows: From Yourenhancement (of Los Angeles), to Adtegrity (of Grand Rapids, Michigan), to the Right Media Exchange, to AdOn Network (previously MyGeek/Cpvfeed) (of Phoenix, Arizona) to Grind TV (of El Segundo, California). URLs in the sequence:

http://63.123.224.168/mbop/display.php3?aid=19&uid=…
http://ad.adtegrity.net/imp?z=0&Z=0x0&s=4670&u=http%3A%2F%2F63.123.224.168…
http://ad.yieldmanager.com/imp?z=0&Z=0x0&s=4670&u=http%3A%2F%2F63.123.224….
http://ad.adtegrity.net/iframe3?AAAAAD4SAADV5AMAtnIBAAIADAAAAP8AAAABEwACAA…
http://ad.yieldmanager.com/iframe3?AAAAAD4SAADV5AMAtnIBAAIADAAAAP8AAAABEwA…
http://campaign.cpvfeed.com/cpvcampaign.jsp?p=110459&campaign=Mortgage&aid…
http://www.grindtv.com/p/hs444/mygeek/

Yourenhancement’s display.php3 ad-loader sends traffic to a variety of ad networks, by all indications without any targeting whatsoever. Users therefore receive numerous untargeted popups and popunders. As in the prior example, the resulting window lacks any branding to indicate what spyware caused it to appear or how users can prevent future popups from the same source.

Yourenhancement’s unlabled ads are particularly harmful because users may not have authorized the installation of Yourenhancement in the first place: I have repeatedly seen Yourenhancement install without user consent — including in bundles assembled by DollarRevenue, in WMF exploits served from ExitExchange, in misleading ActiveX bundles packaged by IE Plugin, and in a CoolWebSearch exploit served from Runeguide.

The packet log indicates that GrindTV purchased traffic not from Fullcontext directly, but rather from AdOn Network. However, advertising professionals should know that buying advertising from AdOn Network inevitably means receiving traffic from spyware. For example, Direct Revenue’s site previously disclosed that Direct Revenue shows AdOn ads, while AdOn’s site admitted showing ads through both Direct Revenue (“OfferOptimizer”) and Zango (180solutions). My site has repeatedly covered AdOn’s role in spyware placements (1, 2, 3, 4). I continue to observe traffic flowing directly to MyGeek from various spyware installed without user consent, including Look2me and Targetsaver. With voluminous documentation freely available, advertisers cannot reasonably claim not to know what kind of ads AdOn sells.

The GrindTV site is operated by PureVideo Networks. I have previously seen spyware-originating forced visits to other PureVideo sites, including Stupidvideos.com and Hollywoodupclose.com.

PureVideo’s “News” page specifically touts the company’s reported popularity (“among top 10 US video sites by market share”, “top growing sites”, “StupidVideos Climb Charts”, etc.). In March, ComScore even announced that PureVideo sites were the ninth-fastest growing properties on the web. But in that same month, I observed widespread forced-visit promotion of multiple PureVideo sites. Forced visits can easily cause a dramatic traffic jump — the same occurrence ComScore reported. It’s hard to know whether PureVideo’s forced visits inflated ComScore’s measurements of PureVideo’s popularity, but that seems like a plausible possibility, particularly in light of Nielsen/NetRatings’ 2006 cut of Entrepreneur’s traffic (after Entrepreneur had used similar tactics).

PureVideo’s Investors & Advisors page indicates that PureVideo has received outside investment, including a $5.6 million investment from SoftBank Capital.

Example 3: Yourenhancement, Adtegrity, Right Media Exchange, and AdOn Network (MyGeek) Promoting Broadcaster.com

Yourenhancement Promoting GrindTV Yourenhancement Promoting Broadcaster

In testing of April 29, I browsed the web and received the popup shown at right.

Packet log analysis reveals that traffic flowed as follows: From Yourenhancement (widely installed without consent, as set out above) to Adtegrity, to the Right Media Exchange, to AdOn Network to Broadcaster (of Las Vegas). URLs in the sequence:

http://63.123.224.168/mbop/display.php3?aid=18&uid=…
http://ad.adtegrity.net/imp?z=0&Z=0x0&s=113743&u=http%3A%2F%2F63.123.224.1…
http://ad.yieldmanager.com/imp?z=0&Z=0x0&s=113743&u=http%3A%2F%2F63.123.2….
http://ad.adtegrity.net/iframe3?AAAAAE-8AQBJ6wQARMcBAAIACAAAAP8AAAABEwACAA…
http://ad.yieldmanager.com/iframe3?AAAAAE-8AQBJ6wQARMcBAAIACAAAAP8AAAABEwA…
http://campaign.cpvfeed.com/cpvcampaign.jsp?p=110495&campaign=121kwunique&…
http://url.cpvfeed.com/cpv.jsp?p=110495&aid=501&partnerMin=0.0036&…
http://www.broadcaster.com/tms/video/index.php?show=trated&bcsrtkr=a85d2&u…

As in the preceding example, traffic originated with Yourenhancement’s display.php3 ad-loader, and lacked any branding to indicate its source. The preceding example reports some of the many contexts in which Yourenhancement has become installed on my test PCs without my consent.

The packet log indicates that GrindTV purchased traffic from AdOn. But as the preceding example explains, Broadcaster should reasonably have known that buying traffic from AdOn means receiving forced-visit traffic as well as spyware-originating traffic.

Broadcaster has recently issued press releases to promote its increased traffic (“Broadcaster traffic rankings soar … one of the fastest growing online entertaining communities”; “88% increase in month-over-month website traffic”; “Tremendous audience growth”; etc.). So Broadcaster clearly views its traffic statistics as important. Yet nowhere in Broadcaster’s press releases does Broadcaster mention that its reported visitor counts include visitors who arrived involuntarily.

Broadcaster is a publicly traded company (OTC: BCSR.OB). Broadcaster’s December 2006 SEC 10KSB/A disclosure does briefly discuss Broadcaster’s purchase of “online advertisements … to attract new users” to its service. But the word “advertisements” tends to suggest mere solicitations (e.g. banner ads), not full impressions that cause a loading of Broadcaster’s site (and hence a tick in reported traffic figures). In my review of this and other Broadcaster financial documents, I could find no direct admission that Broadcaster buys cheap forced visits, then counts those involuntary visits towards records of site popularity. It appears that investors may be buying shares in Broadcaster without understanding the true origins of at least some of Broadcaster’s traffic.

This is not Broadcaster’s first run-in with spyware. Broadcaster’s Accessmedia subsidiary was named as a co-defendant in FTC and Washington Attorney General 2006 suits against Movieland et al., alleging that defendants’ software “barrages consumers’ computers with pop-up windows demanding payment to make the pop-ups go away.” According to the FTC’s complaint, Broadcaster’s Accessmedia subsidiary served as the registrant and technical contact for Movieland.com, and also shared telephone numbers and customer service with Movieland.

Example 4: Web Nexus Promoting Orbitz’s Away.com

Web Nexus Promoting Orbitz's Away.com Web Nexus Promoting Orbitz’s Away.com

In testing of April 29, I browsed the web and received the full-screen popup shown at right. As in Example 2, the popup even covered the Start Menu, Taskbar, and System Tray — preventing me from easily switching to another program. Meanwhile, the ad appeared substantially unlabeled — with a small Web Nexus caption at ad bottom, but with the caption’s letters more than half off-screen.

Packet log analysis reveals that traffic flowed as follows: From Web Nexus (purportedly of Bosnia and Herzegovina) directly to Orbitz’s Away.com. URLs in the sequence:

http://stech.web-nexus.net/cp.php?loc=295&cid=9951709&u=bmV0ZmxpeC5jb20v&e…
http://stech.web-nexus.net/sp.php/9905/28779/295/9951709/527/
http://travel.away.com/District-of-Columbia/travel-sc-hotels-1963-District…

The packet log indicates that Away.com received traffic directly from Web Nexus. Web Nexus is well-known to be unwanted advertising software: The first page of Google search results for “Web Nexus” includes five references to spyware, four to adware, one to viruses, and six to user complaints seeking assistance with removal. I have personally observed Web Nexus becoming installed through a WMF exploit and through the DollarRevenue bundler, among other methods.

Orbitz’s Away.com popup provides three distinct business benefits to Orbitz. First, the popup promotes Orbitz’s own services (e.g. its hotel booking services). Second, the popup promotes Orbitz’s advertisers (here, Verizon, despite Verizon’s repeatedlystated policy of not advertising through spyware). Finally, the popup inflates traffic statistics to Away.com — likely increasing advertisers’ future willingness to pay for ads at Away.com.

Example 5: WebBuying and Exit Exchange Promoting Roo TV

WebBuying Promoting Roo TV WebBuying Promoting Roo TV

In testing of April 23, I browsed the web and received the full-screen popup shown at right. As in Example 2 and 4, the popup covered the Start Menu, Taskbar, and System Tray, and lacked readable labeling of its source.

Packet log analysis reveals that traffic flowed as follows: From WebBuying (a newer variant of Web Nexus) to ExitExchange to Roo TV. URLs in the sequence:

http://s.webbuying.net/e/sp.php/5ers7+aSiObv7uvm7e_v6e7o6e3m6erk
http://count.exitexchange.com/exit/1196612
http://ads.exitexchange.com/roo/?url=http://www.rootv.com/?channel=pop&f…
http://www.rootv.com/?channel=pop&fmute=true&bitrate=56

The packet log indicates that Roo TV received traffic directly from Exit Exchange — traffic that Exit Exchange reasonably should have known would include spyware-originating traffic. Exit Exchange widely receives spyware-originating traffic, passing from a variety of spyware to Exit Exchange, and onwards to Exit Exchange’s advertisers. (For example, in June 2006 I showed Exit Exchange receiving traffic from Surf Sidekick spyware, widely installed without consent. Meanwhile, SiteAdvisor rates Exit Exchange red for delivering exploits to users’ PCs — behavior I documented in February 2006 and observed twice last week alone.)

The Roo TV landing page URL leaves no doubt that Roo TV knew it was receiving forced visits. Notice the “channel-pop” tag in the URL log above — specifically conceding that the traffic at issue was not requested by users.

Roo TV’s “About” page reveals Roo’s emphasis on traffic quantity: The page’s first sentence boasts that “Roo is consistently ranked as one of the world’s ten most viewed online video networks.” But, as in the preceding examples, forced visits raise questions about how Roo got so popular. Is Roo a top-ten site in users’ minds, or only a destination users are frequently forced to visit, against their wishes?

Example 6: WebBuying Promoting Diet.com

WebBuying Promoting Diet.com WebBuying Promoting Diet.com

In testing of April 23, WebBuying also served a full-screen popup of Diet.com — again covering the Start Menu, Taskbar, and System Tray, and again lacking readable labeling to disclose its source. Screen-capture video.

Packet log analysis reveals that traffic flowed from WebBuying directly to Diet:

http://c.webbuying.net/e/check.php?cid=13352451&lid=327&cc=US&u=aHR0cDov…
http://s.webbuying.net/e/sp.php/6+rv6uaSiObv7uvm7e_v6e7o6e3m6erk
http://www.diet.com/tracking/index.php?id=1052

As in the Away.com example, Diet.com receives several benefits from this popup: Promoting its own content, showing ads for third parties (here, Nutrisystem), and inflating its traffic statistics.

Alexa’s traffic statistics show a 5x+ jump in Diet traffic in early March — the same period in which I began observing forced visits to Diet.com.

Additional Examples on File

The preceding six examples are only a portion of my recent records of spyware-originating forced-visit I have recently observed. Under euphemisms that range from “audience development” to “push traffic,” these tactics have become widespread and, by all indications, continue to grow. I have seen other popups from each of these sites on numerous other occasions, and I have seen similar popups from other sites delivered via similar methods.

Implications & Policy Responses

Video sites are strikingly prevalent in the preceding examples and in other forced-visit traffic I have observed. Why? Google’s $1.65 billion acquisition of YouTube inspired others hoping to receive even a fraction of YouTube’s valuation. So far no competitor has gained much traction. But the expectation that video sites grow virally creates an incentive to try to jump-start traffic by any means possible — even spyware-originating traffic.

When forced-visit sites show ads, they tend to promote well-known advertisers. For example, two of the preceding examples (1, 4) feature Verizon, despite Verizon’s stated policy against spyware advertising. While concerned advertisers have generally added anti-spyware policies to their ad contracts, they still tend to ignore the problem of web sites buying spyware traffic. Verizon staff will probably take the position that it is not permissible for a Verizon ad to be shown in a site that receives widespread spyware traffic. But then Verizon’s ad contracts and other policy statements probably need to say so. Same for ad networks seeking to avoid reselling spyware inventory. In practice, few ad policies prohibit intermediary sites buying spyware-originating traffic.

Low-cost spyware-originating traffic can vastly increase a site’s reported popularity. Consider Alexa’s plot of Roo TV traffic. During April 2007 (when I first began to observe spyware-originating forced visits of Roo TV), Alexa reports that Roo’s reach and page views both jumped by an order of magnitude. It is difficult to know how much of this jump results from spyware-originating forced-visit traffic — rather than other kinds of forced visits, or conceivably bona fide user interest. But the New York Times piece reported that when ComScore last year adjusted Entrepreneur’s statistics to account for forced visits, traffic was reduced by 65%. A similar reduction may be required for the sites set out above.

When forced-visit sites show banner ads, the sites raise many of the same concerns as banner farms — including overwhelming advertising, unrequested popups, automatic reloads, opaque resale of spyware-originating traffic, and an overall bad value to advertisers. Particularly prominent among spyware-delivered banner farms is India Broadcast Live’s Smashits — which buys widespread spyware-originating forced-visit traffic, and shows as many as six different banner ads in a page that otherwise lacks substantial content. In some instances, Smashits’ page hijacks users’ browsers: Spyware removes the page a user had requested, and instead shows only the Smashits site. (Video example.) These practices may lead concerned advertisers and ad networks to avoid doing business with Smashits, including Smashits’ many alter egos and secondary domain names. But at present, Smashits continues to show ads from top advertisers and ad networks (particularly FastClick, Google, and TribalFusion). Same for other banner farms still in operation.

Detection

Sophisticated advertisers and ad networks rightly want to know which sites are buying spyware-originating forced-click traffic. But they can’t answer that question merely by examining individual sites: Bolt, GrindTV, and kin all look like ordinary sites, without any obvious sign that they get traffic from spyware. So advertisers and networks’ can’t catch spyware-originating traffic. using their usual techniques for evaluating publishers (such as browsing publishers’ sites in search of explicit or offensive materials).

Advertisers and ad networks might look for unusual changes in sites’ reported traffic rank — on the view that extreme spikes probably indicate forced-visit traffic. But there can be legitimate reasons for traffic spikes. Furthermore, an unexpected traffic jump will often prove an insufficient reason to block a prospective advertising relationship. Finally, if advertisers and ad networks distrusted sites with traffic spikes, sites could start their forced-click campaigns more gradually, to avoid tell-tale jumps. So checking for traffic spikes is not a sustainable strategy.

With help from traffic measurement vendors, advertisers and ad networks could attempt to measure visit length rather than visit count. But even visit length measurement might not prevent miscounting of spyware-originating forced visits. Some spyware opens sites off-screen — where JavaScript or other code could extend traffic indefinitely to inflate measured visit length as needed, without users noticing and closing the resulting windows.

The only robust way to detect spyware-originating forced visits is through testing of actual spyware-infected PCs — by watching their behavior and seeing what sites they show. Historically, I’ve done this testing manually, as in the examples set out above. Fortunately, detecting widespread spyware-originating traffic is easy — because, by hypothesis, the traffic is common and hence likely to appear even in brief testing. That said, a scalable automated system might be preferable to my hands-on testing. I’ve recently built an automatic tester that performs this function, among others. I’ll describe it more in a coming piece. US patent pending.

Services for Advertisers – Avoiding Waste and Improving Accountability

In the course of my research on spyware/adware, typosquatting, popups, and other controversial online practices, I have developed the ability to identify practices that overcharge online advertisers. I report my observations to select advertisers and top networks in order to assist them in improving the cost-effectiveness of their advertising including by flagging improper ad placements, rejecting unjustified charges, and avoiding untrustworthy partners. This page summarizes the kinds of practices I uncover and presents representative examples drawn from my publications.

For Display Advertisers and Display Networks

In work for display advertisers and display networks, I catch and report the following problems:

For Affiliate Advertisers and Affiliate Networks

In work for affiliate advertisers and affiliate networks, I catch and report the following problems:

Information and Incentives in Online Affiliate Marketing analyzes patterns in merchants’ vulnerabilities and effective defenses.

For Advertisers in Comparison Shopping Engines

In work for comparison shopping engines (CSEs) and their advertisers, I catch and report the following problems:

  • Advertisements loaded, and clicks recorded and billed for, without a user seeing the advertisement link or clicking on it. (CSE click fraud)
  • CSE advertisements presented in adware including injections, popups, sliders, and toasts.

Methods

I catch infractions using multiple “crawler” PCs which operate 24 hours per day, continuously checking for improper advertising placements. These crawlers run from multiple locations in the US, along with systems to detect behaviors targeting users outside the US. Some of my reports draw on large-scale automation developed in partnership with Wesley Brandi. I supplement automatic observations with manual testing using methods I have refined over more than a decade.

Each of my reports includes a packet log presenting the specific methods and identifiers (ad tags, affiliate IDs, etc.) associated with the infraction. Where an incident includes notable on-screen appearances (e.g. a popup), I typically include a screen-capture video or screenshot image showing occurrences as they appear to users. Each report includes a customized explanatory memorandum.

Please contact me to learn more about my reports.

Last updated: May 21, 2016

Banner Farms in the Crosshairs updated June 23, 2006

mo

For the last 8 months, I’ve been following ads from Global-Store, Inqwire, Venus123, and various others — all sites operated by Hula Direct. They’re engaged in a troubling scheme: They buy popups and popunders from various notorious spyware vendors. They show numerous banner ads in “banner farms” without substantial bona fide content. They show advertisers’ ads (and charge advertisers for those ad displays) without the advertisers’ specific permission. They automatically reload ads to rack up extra fees.

Some advertisers and ad networks have taken action to remove themselves from these practices. But others have not, whether from ignorance or indifference. See specific names and screenshots, below.

Buying traffic from spyware vendors

The Inqwire site, as loaded by SurfSidekick spyware. The Inqwire site, as presented to users by SurfSidekick spyware.

I’ve seen Hula banner farms delivered by numerous spyware programs. My October 2005 Claria Shows Ads Through Exploit-Delivered Popups presented Hula’s Venus123 buying traffic from ContextPlus, a spyware program so noxious it used a rootkit to hide its presence on users’ PCs. But that’s just one of many spyware vendors sending traffic to Hula.

The image at right shows Hula’s Global-store.net buying traffic from SurfSidekick. SurfSidekick comes from California-based Santa Monica Networks (also known as SMNi), and I have often seen SurfSidekick installed without consent, as well as installed in misleading bundles where users aren’t fairly told what software they’ll be receiving.

I have also often observed Hula buying traffic from Look2me (a.k.a. Ad-w-a-r-e, made by Minnesota-based NicTech Networks, and widely installed via security exploits). Look2me doesn’t label its ads, so the Hula window doesn’t bear Look2me’s name. But packet log analysis confirms that Hula receives traffic from Look2me.

In further testing, I have also received Hula ads shown by DealHelper (made by Daniel Yomtobian, also of Xupiter), among others.

Hula cannot write off its spyware-sourced traffic as a mere anomaly or glitch. I have received Hula popups from multiple spyware programs over many months. Throughout that period, I have never arrived at any Hula site in any way other than from spyware — never as a popup or popunder served on any bona fide web site, in my personal casual web surfing or in my professional examination of web sites and advertising practices. From these facts, I can only conclude that spyware popups are a substantial source of traffic to Hula’s sites.

Update (June 23): Hula’s attorney, Sandor D. Krauss, has sent me a Cease and Desist letter demanding that I remove all references to Hula from my site. Hula claims that my article is “baseless,” in part because, Krauss claims, Hula “does not buy from spyware vendors.” Krauss further claims that “Hula did not buy from [Surf]SideKick.”

To disprove Krauss’s claim, I have posted a supplemental screenshot and packet log, showing traffic flowing directly from SurfSideKick to Hula’s Clickandtrack.net, and on to Hula’s Venus123 site. I have also posted a packet log showing traffic flowing directly from Web Nexus (widely installed without consent and without informed consent), to Hula’s ClickAndTrack, to Hula’s Inqwire. Similarly, my 2005 proof of ContextPlus spyware sending traffic to Hula’s Venus123 entailed a packet log with traffic flowing directly from ContextPlus to Hula’s ClickAndTrack to Venus123. I have numerous other examples on file, and I may post further examples in the future.

These several examples of direct relationships between Hula and spyware vendors serve to rebut Hula’s claims that it is a “victim” of spyware or that it “did not buy” traffic from the spyware vendors I reported.

Banner farms and their overwhelming advertising

The Global-Store site, as loaded by Look2me/Ad-w-a-r-e spyware.  The site includes numerous large ads but no bona fide content. The Global-Store site, as loaded by Look2me/Ad-w-a-r-e spyware.
The site includes numerous large ads but no bona fide content.

I call Hula’s sites “banner farms” because they offer little bona fide content, yet they show many banner-type advertisements. Consider the Global-store.net screenshot shown at right. The page embeds two distinct advertisements that are substantially visible: A large Vonage ad at bottom center, with a smaller text ad above. These ads fill substantially all of the window’s usable screen-space. Indeed, the window shows no substantive material other than this advertising; the “Globalstore.net” name and logo don’t provide users with any useful features or information. The abundance of advertising, vis-a-vis no bona fide content, means this site is, as a practical matter, just ads.

Although the screenshot at right is representative of the ads in Hula sites, some Hula sites show even more ads. The preceding Inqwire example includes four visible ads: A prominent top ad for Verizon, a large ad for Universal Studios, a weather search box from the Weather Channel, and a car rental ad from an unknown provider. The Inqwire site also includes a search box — not an ad in its own right, but a pathway to sponsored links obtained from Epilot, a pay-per-click search network. (Furthermore, Inqwire shows Epilot’s links without the advertising disclosure required by FTC regulation.)

Update (6/23/06): I have posted a screenshot of the unlabeled PPC ads at issue.

Some of Hula’s embedded ads aren’t even seen by typical users. For one, users understandably seek to get rid of Hula’s ads as quickly as possible. But Hula stacks ads, so that users can’t even see all of Hula’s ads without multiple clicks. For example, the large Vonage ad at right was superimposed above several others; seeing those others requires closing the Vonage ad first. Other ads are “below the fold,” off-screen and visible only if a user scrolls down. All told, a typical Global-Store page includes half a dozen different ad frames, but typical users are unlikely to see most of these ads. Nonetheless, CPM (pay-per-impression) advertisers are charged for all the ad displays. For these CPM ads, Hula gets paid more each time it serves up another page of ads, whether or not users actually see the ads.

Update (6/23/06): Hula’s attorney claims “Hula does not take multiple clicks to get the ads. Ads are not below the fold. Based on an 800×600 screen all ads are above the fold.”

To disprove this claim, I have posted further screenshots of Hula’s Inqwire site. I show that Hula’s lowest Inqwire ad is entirely off-screen — “below the fold,” on a standard 800×600 screen, just as I claimed. Reaching this ad requires at least two clicks (one to close the “super pop-up,” and a second to scroll down), which I accurately characterize as “multiple” clicks.

Automatic advertising reloads

Most Hula ads include automatic reloads that charge extra fees to CPM (pay-per-impression) advertisers’ accounts. The main Hula web sites embed a set of ads, in the locations set out above. But rather than directly putting ad-reference code into its sites, Hula’s sites embed a set of ad-loader pages that in turn invoke the ad-reference code. Importantly, these ad reference pages include refresh tags that automatically reload the ad-reference pages. So the outer ad wrapper page stays on-screen permanently, but the ad-reference pages continually reload. Each time an ad-reference page reloads, Hula sends additional traffic to advertisers — and gets paid accordingly, on a per-impression basis for CPM ads.

In October 2005, Hula’s automatic reload code was particularly straightforward. Hula’s Venus123 site loaded an ad-reference page (here, a page called 728×90.asp):

<iframe src=”728×90.asp?jscode=…”>

Then the 728×90.asp ad-reference page automatically refreshes itself every 9 seconds. Note the META REFRESH code (highlighted in yellow).

<html>
<head>
<meta http-equiv=”Refresh” content=”9 url=728×90.asp?jscode=…”>
<body leftmargin=0 rightmargin=0 topmargin=0 bottommargin=0 >
<p align=center valign=bottom>
<SCRIPT TYPE=’text/javascript’ SRC=’http://ad.yieldmanager.com/rmtag2.js’></SCRIPT><SCRIPT language=’JavaScript’>var rm_host = ‘http://ad.yieldmanager.com’;var rm_site_id = 2578;var rm_section_code =4400;var rm_iframe_tags = 1;rmShowAd(‘728×90’);</script>
</p>
</body>
</html>

I have seen Hula sites using a variety of automatic reload times, including times as low as 9 seconds (as shown above). Ads are replaced every time the ad-reference page reloads, so in this case an advertiser’s per-impression fee buys only 9 seconds on the Hula site. These days, Hula’s automatic reload code is somewhat more complicated, largely implemented via JavaScript rather than a META REFRESH. And Hula currently sets its auto-reload for 21 to 25 seconds rather than 9. But the net effect remains the same — showing advertisers’ ads for less time than advertisers reasonably expect.

Hula’s automatic reloads stand in contrast to Interactive Advertising Bureau (IAB) guidelines for advertising tracking, measurement, and charges. The IAB specifies that ad refresh rates must be “reasonable based on content type.” Despite some vagueness in this standard, it seems unlikely that 9 seconds could be a reasonable refresh rate.

Hula’s automatic refreshes also contradict stated rules at Yield Manager (the primary advertising system to which Hula sends traffic). Yield Manager’s Publisher Signup rules specifically prohibit ads that auto-refresh more often than every 90 seconds.

Update (June 23): In its demand letter, Hula claims that “The major falsity [of my article] is the assumption that the majority of the media placed [in Hula’s sites] is on a CPM [basis].”

I take no position as to the prevalence of CPM advertising within Hula’s site, although some of my sources indicate that CPM advertising is or has been widespread. In any event, my automatic reload analysis primarily applies to CPM ads — such reloads being of far less significance as to CPC or CPA relationships. I have revised some text above to make clear that this analysis primarily applies to CPM ads.

Following the money trail; complacent advertisers

Vonage
money viewers
   aQuantive / Atlas DMT    
money viewers
Traffic Marketplace
money viewers
Yield Manager
money viewers
Hula / Global-Store

The money trail – how funds flow from advertisers
to ad networks to Hula

Few advertisers are likely to want to pay for their ads to be shown in spyware-delivered popups, stacked among (and often obscured by) other ads, reloaded quickly. So, according to the advertisers and ad networks I talk to, Hula doesn’t exactly ask advertisers for permission to show their ads. Instead, Hula sells its advertising space through bulk marketplaces, most notably Yield Manager. Other Yield Manager market participants buy traffic from Hula, apparently without fully understanding how and where Hula will show their ads.

Hula’s Yield Manager relationship provided Hula with the Vonage ad shown in the example above. Hula’s Global-Store sent traffic to Yield Manager which sent traffic to Traffic Marketplace, which sent traffic to aQuantive’s Atlas DMT, which sent traffic to Vonage. Payments flowed in the opposite direction. See diagram at right, and a full packet log of the chain of redirects. Traffic Marketplace may or may not have understood what traffic Hula was selling it via Yield Manager. But consider the perspective of Vonage, three steps removed from Hula. When Vonage bought traffic from Traffic Marketplace, it’s unlikely that Vonage had specific knowledge of what traffic it would receive.

http://global-store.net/index_tiny.asp?st=6755&sc=956&lc=60&ld=20…
http://www.inqwire.com/Ad720x300.asp?flc=5&fld=26&st=6755&sc=956
http://ad.yieldmanager.com/imp?z=0&i=6755&S=956&r=1&y=23&w=720&h=300
http://t.trafficmp.com/b.t/eMMt/11
http://clk.atdmt.com/VON/go/trffevon0740000126von/direct/01/
http://www.vonage.com/startsavingnow

Despite the complexity of the advertising sales relationships, advertisers and intermediate ad networks have considerable power to investigate and terminate improper traffic sources. Reviewing the Vonage packet log, notice that each HTTP transaction contains a HTTP Referer header reporting that traffic came from Inqwire.com, another Hula property. Seeing this reference to Inqwire, Vonage could have investigated Inqwire, immediately uncovering their bad practices: Most top Google results for “inqwire” are users complaining of unwanted Inqwire popups delivered by spyware. After learning that Inqwire serves ads in unwanted popups and through spyware, Vonage could have terminated its indirect relationship with Inqwire by instructing aQuantive and Traffic Marketplace to cease buying Hula traffic on Vonage’s behalf.

Instead, many big advertisers have failed to investigate or stop these practices. I have seen Vonage’s ads served by Hula on dozens of occasions, over a period of many months. Same for other big advertisers, like Verizon (promoting DSL and cell phone service) and Claria (promoting PersonalWeb). Additional well-known advertisers promoted by Hula: Blizzard Entertainment (makers of World of Warcraft), the Blu-ray Disc Association, Circuit City, Classmates.com, Micron, Monster.com, Universal Studios, and the Weather Channel.

In other contexts, Hula’s advertisers are careful, thoughtful companies, focused on how they present and protect their brands. But these companies throw caution to the wind when it comes to banner advertising — mistakenly trusting ad networks to select ad placements, without investigating and supervising ad networks’ decisions and practices.

Some ad networks take action

I first reported Hula’s practices in October 2005, when I showed Claria ads appearing through Hula’s Venus123, as opened by ContextPlus spyware. Since then, various ad networks have noticed and have begun to take action.

Ad network Red McCombs Media became dissatisfied with Hula’s ad practices and apparently refused to pay a $200,000+ bill from Hula. In response Hula sued McCombs, claiming breach of contract. I’m working on getting case documents, and I’ll post them here when available. Without seeing the contract between McCombs and Hula, it’s hard to know whether Hula breached the contract (giving McCombs proper basis to refuse to pay). But if the contract (explicitly or implicitly) required Hula to show ads on bona fide web sites, not in spyware-delivered popups, then McCombs is probably on strong ground. Same if the contract required Hula to show ads for a commercially reasonable period of time, consistent with IAB recommendations and industry norms, not just for a period of seconds.

More recently, ValueClick’s FastClick sent its partners a pointed emailalerting them to this problem. Having concluded that Yield Managerpartnerships are the core of Hula’s business, FastClick moved to ban Yield Manager from the FastClick network. FastClick told its publishers: “Due to recent network quality concerns regarding misuse of ad servers by some publishers the decision was made to no longer allow banner hosting through the Yield Manager ad serving system.” Though FastClick does not mention Hula specifically, my review of industry practices leaves no serious doubt that this policy change was a response to Hula.

I’ve seen other efforts from other networks seeking to stop buying traffic from Hula. But networks find this task surprisingly hard: Many networks buy and sell traffic through convoluted paths; even if a network terminates its direct relationship with Hula, it might still receive Hula traffic through some partner, or some partner’s partner. To me the solution seems clear: Stop buying ad placements through such complex, unaccountable channels. But for ad networks committed to these convoluted placements, Hula presents a serious challenge. A sophisticated network may be able to supervise its own partners, but can it track its partners’ partners’ partners?

Banner farms in context

In general I don’t object to careless advertisers throwing away their money. Of course I seek to prevent my advertiser and ad network clients from being cheated. But I see no overwhelming public policy requiring advertisers to get a good deal on their ad purchases.

Nonetheless, certain rip-offs carry serious public policy concerns. When advertisers pay Hula for ads within Hula’s banner farms, advertisers don’t just get a bad deal. Instead, advertisers paying Hula help contribute to the spyware ecosystem: Advertisers pay Hula, then Hula pays spyware vendors, who, in anticipation of such payments, had infected users’ computers with noxious advertising software like Look2me and SurfSidekick. Were it not for revenue sources like Hula, spyware would have less reason to exist — less ability to make money from infecting users’ computers. In short, Hula’s practices have negative externalities — harming users through spyware infections. So I see substantial reason for the public to want Hula to stop buying traffic from spyware vendors, or simply to shut its banner farms altogether.

The Global-Store site, with numerous large ads but without any bona fide content. ExitExchange, another banner farm, as shown by a SurfSidekick popup.

Though Hula’s use of banner farms is unusual, it is not entirely unique. Consider ExitExchange. Like Hula, ExitExchange buys spyware-delivered traffic, such as the SurfSidekick popup shown at right. Through a variety of ad networks, ExitExchange promotes numerous large advertisers — including Vonage, as shown at right. (I’ve also seen ExitExchange running security exploits which infect users’ PCs with spyware — a particularly unsavory practice.) Another similar banner farm: Whatsnewreport, which I show to be running ads for Claria, Verizon, and Washington Mutual Bank, among others. So the banner farm problem extends beyond Hula.

It’s particularly ironic to see Hula getting paid by Vonage. Vonage went public last month in large part to get money to buy more advertising — to continue their incredible $243 million of advertising spending in 2005. Vonage is one of the web’s largest advertisers, and it’s a sophisticated technology company. So Vonage might be expected to be savvy enough to avoid buying ads in Hula’s banner farms — but in fact, as I’ve shown above, Vonage often appears in Hula’s ads and in other banner farms. Of course these are not Vonage’s only payments to spyware vendors: I have previously reported Vonage buying ads from Direct Revenue and eXact Advertising. That’s a veritable who’s-who of the spyware world. How much other waste is there in Vonage’s advertising budget?

Who’s responsible here? Hula and other banner farms put these problems in motion, so it’s natural to blame them first and foremost. But I also see substantial room for improvement among large advertisers. Anyone buying millions of dollars of online advertising — or tens or hundreds of millions — needs to anticipate bad actors, and needs systems and procedures to detect and block the inevitable unsavory practices. Same for ad networks, who owe special responsibility since they’re spending and allocating their clients’ money rather than their own. So I’m disappointed to see huge advertisers and huge networks allow these problems to fester for so long. That said, it’s reassuring that at least some ad networks have recognized the issue and have taken steps to blunt its effects.

Update (6/23): My article mentions three specific Hula sites: Global-Store, Inqwire, and Venus123. But a cached page from the huladirect.com site shows their admission that they run several other sites too. In particular, Hula takes credit for searchhound.com. (Facts seem to corroborate that claim: SearchHound is hosted within the same “class c” (“slash 24”) network block as other Hula servers. And the SearchHound site shares a common look and feel with other Hula sites.)

Is SearchHound a spyware-delivered banner farm too? I’m stil conducting investigations. But I do know SearchHound receives spyware-delivered traffic. Earlier this week I saw SearchHound in the midst of spyware-delivered click fraud. See packet log and screen-capture video proof : I requested www.zappos.com and was sent, by TrafficSector spyware installed on my test PC my without informed consent, to Click2begin. Click2begin then redirected me to Hula’s SearchHound, which sent me on to an unnamed server at 64.14.206.59, then to LookSmart, and finally on to a LookSmart advertiser. The net effect was that the LookSmart advertiser had to pay for a “click” that never occured — standard click fraud. Meanwhile, SearchHound served as a middle-man in this relationship — receiving traffic from the notorious Click2begin that has received so much criticism. More on spyware-delivered click fraud.