naming names – Page 2

April 27, 2010December 2, 2023

Sony’s Crackle: Invisible Traffic Galore

Advertisers buying display ads from Sony’s Crackle.com rightly and reasonably expect that users can see the ads. After all, a visible ad is a basic and crucial condition for effective display advertising: If a user can’t see ad, then the impression is wasted, as is the associated spending. Nonetheless, in a surprising series of incidents, numerous Crackle partners are loading the Crackle site invisibly — thereby overcharging advertisers for worthless invisible impressions.

Below, I present three recent examples of Crackle partners loading the Crackle site invisibly, largely via 1×1 IFRAMEs. I then tabulate observations preserved by my automation, demonstrating that Crackle’s tainted traffic has continued for more than a year. I conclude by flagging implications for traffic measurement and ad pricing, and by suggesting what Crackle should do to clean up this mess.

Example 1: Yahoo Right Media, Adjuggler Invisible (1×1) IFRAME Loads Crackle Invisibly

In testing of April 24, 2010, my Automatic Spyware Advertising Tester browsed a series of ad URLs I had previously observed to be loaded by various spyware (installed through security exploits without user consent). One such URL embedded Bcserving tags for a 160×600 IFRAME, which passed traffic through Yahoo Right Media (yellow) to Adjuggler (green). Crucially, Adjuggler responded with an invisible 1×1 IFRAME (red) loading a URL on the Crackle site (blue). Meanwhile, another 1×1 IFRAME loaded competing video site Buddytv (grey).

GET /servlet/ajrotator/875404/0/vj?z=pdn&dim=753182&pos=1&pv=1292398882782181&nc=26008239 HTTP/1.1
Accept: */*
Referer: http://ad.yieldmanager.com/iframe3?AAAAAJ57DABJF0gAAAAAAABnEwAAAAAAAgAcAAoAAAAAAP8AAAAHGBe4GAAAAAA
ANXYaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAVewYAAAAAAAIAAgAAAAAAXI.C9Shczz
9cj8L1KFzPP2ZmZmZmZtY.ZmZmZmZm1j8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADJXq7VaJccC
LvQxO2LYSYeejv1pj-PofdqHVgeAAAAAA==,,…,4256ee3e-5018-11df-ace3-001e6837e93f
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Host: rotator.adjuggler.com
Connection: Keep-Alive
Cookie: optin=Aa; ajess1_185B9A7222F0F2E13794DA5C=a; ajcmp=2023xkW0101Em0039kn

HTTP/1.1 200 OK
Server: JBird/1.0b
Connection: close
Date: Sun, 25 Apr 2010 03:11:36 GMT
Pragma: no-cache
Cache-Control: private, max-age=0, no-cache, no-store
Expires: Tue, 01 Jan 2000 00:00:00 GMT
P3P: policyref=”http://rotator.adjuggler.com:80/p3p/RotatorPolicyRef.xml”, CP=”NOI DSP COR CURa DEVa TAIa OUR SAMa NOR STP NAV STA LOC”
Content-Type: application/x-javascript

document.write(“<“+”IFRAME FRAMEBORDER=0 MARGINWIDTH=0 MARGINHEIGHT=0 SCROLLING=NO WIDTH=1 HEIGHT=1 SRC= “http://search.dailygamingupdates.com/ioq1wEIC6YxRSnWiIC9BHpdX0b1i.html”><“+”/IFRAME><“+”br><“+”/br>n”);
document.write(“n”);
document.write(“n”);
document.write(“<“+”IFRAME FRAMEBORDER=0 MARGINWIDTH=0 MARGINHEIGHT=0 SCROLLING=NO WIDTH=1 HEIGHT=1 SRC=”http://crackle.com/c/A_River_Runs_Through_It/?cmpid=762“><“+”/IFRAME><“+”br><“+”/br>n”);
document.write(“n”);
document.write(“<“+”iframe src=”http://www.buddytv.com/home2/american-idol-home2.aspx” width=”1″ height=”1″ scrolling=”no” frameborder=”0″ marginheight=”0″ marginwidth=”0″><“+”/iframe>”);

The net effect was to load the Crackle site completely invisibly. The page-load also embedded tracking tags for comScore/ScorecardResearch (yellow). Unless comScore takes special steps to recognize and discount these invisible loads of the Crackle site, the presence of these tags would cause comScore services to overstate Crackle’s popularity.

Example 2: Yahoo Right Media, Adjuggler, Media Javelin Overflowing IFRAME (1280×800 inside 160×600) Loads Crackle Invisibly

In testing of April 14, 2010, my tester browsed another publisher passing traffic through Yahoo Right Media (yellow) to an ad on Adjuggler (green) with a HTML comment referencing Media Javelin (pink). The placement was purportedly a 160×600 (grey), yet the response included a further 160×600 ad (completely filling the available space) (grey) followed by three 1280×800 IFRAMEs (red). The third of these IFRAMEs passed traffic to an Adspeed URL (orange) which passed traffic to Crackle (blue).

GET /servlet/ajrotator/875404/0/vj?z=pdn&dim=753182&pos=1&pv=9001545836619459&nc=92606617 HTTP/1.1
Accept: */*
Referer: http://ad.yieldmanager.com/iframe3?AAAAAJ57DABJF0gAAAAAAABnEwAAAAAAAgDkAAoAAAAAAP8AAAAEAh e4GAAAAAAANXYaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAVewYAAAAAAAIA AgAAAAAAXI.C9Shczz9cj8L1KFzPP2ZmZmZmZtY.ZmZmZmZm1j8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAT0W5xeDoOCKeWj8s538mkN2SqqfrSTmyoa.sbAAAAAA==,,…
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Host: rotator.adjuggler.com
Connection: Keep-Alive
Cookie: optin=Aa; ajess1_…=a; ajcmp=…

HTTP/1.1 200 OK
Server: JBird/1.0b
Connection: close
Date: Wed, 14 Apr 2010 05:43:20 GMT
Pragma: no-cache
Cache-Control: private, max-age=0, no-cache, no-store
Expires: Tue, 01 Jan 2000 00:00:00 GMT
P3P: policyref=”http://rotator.adjuggler.com:80/p3p/RotatorPolicyRef.xml”, CP=”NOI DSP COR CURa DEVa TAIa OUR SAMa NOR STP NAV STA LOC”
Content-Type: application/x-javascript
Set-Cookie: ajcmp=…;Max-Age=315360000;expires=Sat, 11 Apr 2020 05:43:20 GMT;Path=/

document.write(“<“+”!– BEGIN STANDARD TAG – 160 x 600 – Mediajavelin.com: Run-of-site – DO NOT MODIFY –>n”);
document.write(“<“+”IFRAME FRAMEBORDER=0 MARGINWIDTH=0 MARGINHEIGHT=0 SCROLLING=NO WIDTH=160 HEIGHT=600 SRC=”http://ad.yieldmanager.com/st?ad_type=iframe&ad_size=1024×800&section=820955“><“+”/IFRAME>n”);
document.write(“<“+”!– END TAG –>n”);
document.write(“n”);
document.write(“n”);
document.write(“<“+”!– AdSpeed.com Serving Code 7.9.4 for [Ad] Buddy_home_cpc 1280×800 –><“+”iframe width=”1280″ height=”800″ src=”http://g.adspeed.net/ad.php?do=html&aid=82609&wd=1280&ht=800&target=_top” frameborder=”0″ scrolling=”no” allowtransparency=”true” hspace=”0″ vspace=”0″><“+”img style=”border:0px;” src=”http://g.adspeed.net/ad.php?do=img&aid=82609&wd=1280&ht=800&pair=as” width=”1280″ height=”800″/><“+”/iframe><“+”!– AdSpeed.com End –>n”);
document.write(“n”);
document.write(“<“+”!– AdSpeed.com Serving Code 7.9.4 for [Ad] Buddy_idol_cpc 1280×800 –><“+”iframe width=”1280″ height=”800″ src=”http://g.adspeed.net/ad.php?do=html&aid=82610&wd=1280&ht=800&target=_top” frameborder=”0″ scrolling=”no” allowtransparency=”true” hspace=”0″ vspace=”0″><“+”img style=”border:0px;” src=”http://g.adspeed.net/ad.php?do=img&aid=82610&wd=1280&ht=800&pair=as” width=”1280″ height=”800″/><“+”/iframe><“+”!– AdSpeed.com End –>n”);
document.write(“n”);
document.write(“n”);
document.write(“n”);
document.write(“<“+”!– AdSpeed.com Serving Code 7.9.4 for [Ad] Crackle_blood_cpc 1280×800 –><“+”iframe width=”1280″ height=”800″ src=”http://g.adspeed.net/ad.php?do=html&aid=82611&wd=1280&ht=800&target=_top” frameborder=”0″ scrolling=”no” allowtransparency=”true” hspace=”0″ vspace=”0″><“+”img style=”border:0px;” src=”http://g.adspeed.net/ad.php?do=img&aid=82611&wd=1280&ht=800&pair=as” width=”1280″ height=”800″/><“+”/iframe><“+”!– AdSpeed.com End –>n”);
document.write(“”);

GET /ad.php?do=html&aid=82611&wd=1280&ht=800&target=_top HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, */*
Referer: http://ad.yieldmanager.com/iframe3?AAAAAJ57DABJF0gAAAAAAABnEwAAAAAAAgDkAAoAAAAAAP8AAAAE Ahe4GAAAAAAANXYaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAVewYAAAAA AAIAAgAAAAAAXI.C9Shczz9cj8L1KFzPP2ZmZmZmZtY.ZmZmZmZm1j8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAT0W5xeDoOCKeWj8s538mkN2SqqfrSTmyoa.sbAAAAAA==,,…
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Host: g.adspeed.net
Connection: Keep-Alive

HTTP/1.1 200 OK
P3P: policyref=”http://g.adspeed.net/w3c/p3p.xml”, CP=”NOI CUR ADM OUR NOR STA NID”
Expires: Sat, 01 Jan 2000 00:00:00 GMT
Pragma: no-cache
Cache-Control: private, max-age=0, no-cache, no-store, must-revalidate
Content-type: text/html
Connection: close
Transfer-Encoding: chunked
Date: Wed, 14 Apr 2010 05:43:19 GMT
Server: AdSpeed/s10

<html><head><title>Advertisement</title></head><body leftmargin=0 topmargin=0 marginwidth=0 marginheight=0 style=”background-color:transparent”><SCRIPT language=”JavaScript”>
<!–
window.location=”http://crackle.com/c/Blood/?cmpid=763“;
//–>
</SCRIPT><div style=”position:absolute;left:0px;top:0px;visibility:hidden;”><img src=”http://g.adspeed.net/ad.php?do=imp&zid=0&aid=82611&auth=0DB7FD0BC9&wd=1280&ht=800&cb=1271223799″ alt=”i” width=”1″ height=”1″ /></div></body></html>

The net effect was to load the Crackle site completely invisibly. Here too, the Crackle site returned comScore and ScorecardResearch tags as detailed in example 1.

Example 3: Yahoo Right Media, Extreme-sportsonline, Hotbizguide Double Invisible (1×1) IFRAMEs Load Crackle Invisibly

In testing of April 13, 2010, my tester browsed another publisher passing traffic through Yahoo Right Media (yellow) to Extreme-sportsonline (green) which included a 1×1 IFRAME (grey) passing traffic to Hotbizguide (pink). Hotbizguide returned two separate 1×1 IFRAMEs (red) loading Crackle (blue)

GET /BhkG9KftZrBezVPLOKuGW5pr4LRA.html HTTP/1.1 …
Referer: http://ad.yieldmanager.com/iframe3?AAAAAJ57DABJGEgAAAAAAARoEwAAAAAAAgA0AAIAAAAAAP8AAA ADChe4GAAAAAAASncaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAVewYA AAAAAAIAAgAAAAAAXI.C9Shczz9cj8L1KFzPP2ZmZmZmZtY.ZmZmZmZm1j8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAHyzysEFgNCMHLNiu.ziQAnw9Ws9ezWVJH53CoAAAAAA==,,…
Host: search.extreme-sportsonline.com …

HTTP/1.1 200 OK
Server: nginx/0.7.62
Date: Tue, 13 Apr 2010 13:37:58 GMT
…
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>
<html ; }
function trigger() { step++; if(step==max_steps){ load_content(); } }
</script>
<div id=”inifrcode”></div>
<iframe src=”http://search.hotbizguide.com/66682d5b6048f47cf70e56deb9989bb1.php” marginwidth=”0″ marginheight=”0″ hspace=”0″ vspace=”0″ frameborder=”0″ scrolling=”no” width=”1″ height=”1″ onload=”trigger();”></iframe><!–inifrcode–>
<div id=”stuff”></div>
<div id=”stuff1″></div>
<div id=”innercode”></div>
</body>
</html>

GET /MTNkyUL9SGHUGOPKuJJ7uj3AOWuN.php HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, */*
Referer: http://search.mobilegamesearch.com/NgVbJ4eWaW7bMt57RcZVGMggRW9t.html
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Host: search.hotbizguide.com
Connection: Keep-Alive
Cookie: PHPSESSID=a8qbtgec2k79fd8c6onqp5k3q6

HTTP/1.1 200 OK
Server: nginx/0.7.62
Date: Tue, 13 Apr 2010 21:45:49 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive
X-Powered-By: PHP/5.2.11
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: trkid=…; expires=Fri, 16-Apr-2010 21:45:49 GMT

<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>
<html >iframe src=”http://crackle.com/c/A_River_Runs_Through_It/?cmpid=728” width=”1″ height=”1″ scrolling=”no” frameborder=”0″ marginheight=”0″ marginwidth=”0″></iframe>
<iframe src=”http://crackle.com/c/The_Beast/?cmpid=692” width=”1″ height=”1″ scrolling=”no” frameborder=”0″ marginheight=”0″ marginwidth=”0″></iframe>
<!–customcode–>

The net effect was to load the Crackle site completely invisibly, twice. Here too, the Crackle site returned comScore and ScorecardResearch tags as detailed in example 1.

A Long-Term Problem

To confirm the scope of Crackle’s invisible and forced-visit traffic and to evaluate trends over time, I searched logs preserved by my Automatic Spyware Advertising Tester. My tester records the URLs of pages loaded by the spyware-infected virtual computers, but my tester never intentionally visited the Crackle site, nor did my tester ever prompt or provoke traffic to Crackle in any way. So if my tester observes traffic to Crackle, that traffic must have occurred unrequested — invisibly or, at best, through a spyware popup or popunder.

The following table summarizes my tester’s observations of traffic to Crackle:

Month	Number of observations of traffic to Crackle.com
Q1 2009	15
Q2 2009	57
Q3 2009	95
Q4 2009	31
Q1 2010	51
April 2010 (month to date)	74

Although my testing methods have changed over time (e.g. to test new spyware), my testing intensity has remained constant. I have no specific reason to expect that adjustments to my methods would be more or less effective at uncovering Crackle incidents. I therefore tend to attribute month-to-month changes to changes in the intensity with which Crackle’s partners purchase invisible traffic and other tainted traffic on Crackle’s behalf. In my experience, most traffic-buyers run on-and-off campaigns — buying traffic for a time, then taking a break. If Crackle’s traffic buying followed a similar approach, spikes would be expected.

In any event, invisible and forced-visit traffic to Crackle cannot be written off as a short-term anomaly. Quite the contrary, my tester’s observations confirm that these problems have persisted for many months.

Implications and Next Steps

Advertisers buying placements on Crackle reasonably expect high-quality traffic. For example, the first clause of Crackle’s “About” page boasts that Crackle is owned by Sony, and Sony’s size and wealth provide a level of accountability that smaller video sites cannot offer. Nonetheless, my observations confirm that some placements on Crackle are entirely worthless.

Crackle may blame its tainted and invisible traffic on traffic brokers, affiliates, and other external forces. But traffic-buying inevitably invites exactly these shenanigans. If Crackle intends to buy traffic, it should better vet its partners — including confirming partners’ bona fides, overseeing partners’ specific methods, and developing procedures to hold partners accountable for any shortfalls. I’ve seen no sign of any such efforts. If Crackle can’t buy traffic with the requisite skill, perhaps Crackle would do better by ceasing to buy traffic at all.

Crackle traffic rank from Alexa - April 2010 Three years ago, I posted How Spyware-Driven Forced Visits Inflate Web Site Traffic Counts, pointing out that cheap spyware and popup traffic can increase measurements of web site popularity. Users at least see those spyware popups, giving some nugget of rationale for resulting traffic figures. But users cannot even see the Crackle site when it is loaded invisibly as detailed above. Nonetheless, invisible site-loads are still likely to inflate measurements of Crackle’s traffic. For example, during the first few days of April 2010, my tester observed rampant fake traffic to Crackle — and Alexa simultaneously reported a major spike in Crackle’s traffic. (See image at right.) Furthermore, with comScore tags embedded in each Crackle impression, comScore systems receive a report each time Crackle’s site is loaded. Indeed, such reports come from a large number of distinct IP addresses — seemingly confirming that the traffic is legitimate. Can comScore successfully recognize and discount invisible loads of the Crackle site? If not, comScore will join Alexa in overstating Crackle’s popularity.

My bottom line? Buying traffic is a dirty business — so many sellers who provide worthless traffic, and so many buyers who use too little care in selecting and assessing the traffic they buy. As it stands, advertisers and networks doing business with Crackle risk paying for ads users cannot see. Plenty of small-time video sites play these games, but it’s disappointing to see a Sony site stoop to that level.

January 21, 2010March 1, 2018

Upromise Savings — At What Cost? updated January 25, 2010

Upromise touts opportunities for college savings. When members shop at participating online merchants, dine at participating restaurants, or purchase selected products at retail stores, Upromise collects commissions which fund college savings accounts.

Unfortunately, the Upromise Toolbar also tracks users’ behavior in excruciating detail. In my testing, when a user checked an innocuously-labeled box promising "Personalized Offers," the Upromise Toolbar tracked and transmitted my every page-view, every search, and every click, along with many entries into web forms. Remarkably, these transmissions included full credit card numbers — grabbed out of merchants’ HTTPS (SSL) secure communications, yet transmitted by Upromise in plain text, readable by anyone using a network monitor or other recording system.

Proof of the Specific Transmissions

I began by running a search at Google. The Upromise toolbar transmissions reported the full URL I requested, including my search provider (yellow) and my full search keywords (green).

POST /fast-cgi/ClickServer HTTP/1.0
User-Agent: upromise/3195/3195/UP23806818/0012
Host: dcs.consumerinput.com
Content-Length: 274
Connection: Keep-Alive

md5=ee593c14f70c1b7f8b3341a91c3e3639&ts=1264045792.140&bua=N%2FA&meth=get&eid=300&fid=NULL&bin=24af1f0
&refererHeader=http%3A%2F%2Fwww%2Egoogle%2Ecom%2F&url=http%3A%2F%2Fwww%2Egoogle%2Ecom%2Fsearch%3Fhl%3D
en%26source%3Dhp%26q%3Di%2Bfeel%2Bsick%26aq%3Df%26aql%26aqi%3Dg10%26oq

HTTP/1.1 200 OK
Date: Thu, 21 Jan 2010 03:49:51 GMT
Server: Apache/2.2.3 (Debian) mod_python/3.3.1 Python/2.5.1 mod_ssl/2.2.3 OpenSSL/0.9.8c
Connection: close
Content-Type: text/html; charset=UTF-8

I clicked a result — a page on Wikipedia. Transmissions included the full URL of my request (blue) as well as the web search provider (yellow) and keywords (green) that had referred me (red) to this site.

POST /fast-cgi/ClickServer HTTP/1.0
User-Agent: upromise/3195/3195/UP23806818/0012
Host: dcs.consumerinput.com
Content-Length: 304
Connection: Keep-Alive

md5=ee7e3174db149d0d97f51b10db9ac58d&ts=1264045931.921&bua=N%2FA&meth=get&eid=300&fid=NULL&bin=24af1f0
&refererHeader=http%3A%2F%2Fwww%2Egoogle%2Ecom%2Fsearch%3Fhl%3Den%26source%3Dhp%26q%3Di%2Bfeel%2Bsick%
26aq%3Df%26aql%3D%26aqi%3Dg10%26oq%3D&url=http%3A%2F%2Fen%2Ewikipedia%2Eorg%2Fwiki%2FI%5FFeel%5FSick

HTTP/1.1 200 OK
Date: Thu, 21 Jan 2010 03:52:11 GMT
Server: Apache/2.2.3 (Debian) mod_python/3.3.1 Python/2.5.1 mod_ssl/2.2.3 OpenSSL/0.9.8c
Connection: close
Content-Type: text/html; charset=UTF-8

I browsed onwards to Buy.com (grey), where I added an item to my shopping cart and proceeded to checkout. When prompted, I entered a (made-up) credit card number. Buy.com appropriately secured the card number with HTTPS encryption. But, remarkably, Upromise extracted and transmitted the full sixteen-digit card number (yellow) — as well as my (also fictitious) CVV code (green), and expiration date (blue).

POST /fast-cgi/ClickServer HTTP/1.0
User-Agent: upromise/3195/3195/UP23806818/0012
Host: dcs.consumerinput.com
Content-Length: 1936
Connection: Keep-Alive

md5=352732ac9ee0d9e970f3c65d62ed03b1&ts=1264046115.702&bua=N%2FA&meth=post&eid=300&fid=NULL&bin=24af1f0
&refererHeader=https%3A%2F%2Fssl%2Ebuy%2Ecom%2FCO%2FCheckout%2FpaymentOptions%2Easpx&url=https%3A%2F%2F
ssl%2Ebuy%2Ecom%2FCO%2FCheckout%2FpaymentOptions%2Easpx%3F%5F%5FEVENTTARGET%26%5F%5FEVENTARGUMENT%26%5F
%5FVIEWSTATE%3D%2FwEPDwUKMTQ1MjY3MzM2Mw9kFgQCAw9kFgQCAQ8PFgIeCEltYWdlVXJsBV1odHRwczovL2EyNDguZS5ha2FtYW
kubmV0L2YvMjQ4Lzg0NS8xMGgvaW1hZ2VzLmJ1eS5jb20vYnV5X2Fzc2V0cy92Ni9oZWFkZXIvMjAwNi9idXlfbG9nby5naWZkZAICD
w8WAh8ABXdodHRwczovL2EyNDguZS5ha2FtYWkubmV0L2YvMjQ4Lzg0NS8xMGgvaW1hZ2VzLmJ1eS5jb20vYnV5X2Fzc2V0cy92Ni9j
b3JwL2NoZWNrb3V0X3Byb2Nlc3MvY2hlY2tvdXRfM19wYXltZW50X2dyZWVuLmdpZmRkAgUPZBYQAgUPZBYCZg9kFgRmDw8WBB8ABVN
odHRwczovL2EyNDguZS5ha2FtYWkubmV0L2YvMjQ4Lzg0NS8xMGgvaW1hZ2VzLmJ1eS5jb20vYnV5X2Fzc2V0cy9jcy9pbWFnZXMvYm
1sLmdpZh4HVmlzaWJsZWdkZAIBDw8WAh8ABWNodHRwczovL2EyNDguZS5ha2FtYWkubmV0L2YvMjQ4Lzg0NS8xMGgvaW1hZ2VzLmJ1e
S5jb20vYnV5X2Fzc2V0cy9idXR0b25zLzIwMDgvYnV0dG9uX2NvbnRpbnVlMi5naWZkZAIHD2QWAmYPZBYKAgUPEA9kFgIeB29uY2xp
Y2sFKFNldFVuaXF1ZVJhZGlvQnV0dG9uKCdyZG9QYXltZW50cycsdGhpcylkZGQCBw8QD2QWAh4Ib25DaGFuZ2UFG2phdmFzY3JpcHQ
6c2hvd0hpZGVDQyh0aGlzKWRkZAIJDw9kFgIfAgUfc3dpdGNoUmFkaW8oJ3Jkb05ld0NyZWRpdENhcmQnKWQCDQ8QZA8WDWYCAQICAg
MCBAIFAgYCBwIIAgkCCgILAgwWDRAFBDIwMTAFBDIwMTBnEAUEMjAxMQUEMjAxMWcQBQQyMDEyBQQyMDEyZxAFBD%2A%2A%2A%2A%7B
1422%7D%26%5F%5FEVENTVALIDATION%3D%2FwEWKQLNvonpCgKYm5r9BALB5eOPBALy2ZqvCQLv2ZqvCQLq2ZqvCQLu2ZqvCQLr2ba
vCQL28Nu2CwLDqZ7xDALDqZrxDALDqabxDALDqaLxDALDqa7xDALDqarxDALDqbbxDALDqfLyDALDqf7yDALcqZLxDALcqZ7xDALcqZ
rxDALrtZj9AgLrtaSgCQLrtbAHAuu13OoIAuu16NEPAuu19LQGAuu1gJgNAuu1rP8FAuu1%2BJcHAuu1hPsPAvai%2BtMMAvaihrcDA
vaikpoKAt7CxckKAsqi76gMAva5sdkEAvLqvYoEAoaI4c0FArr3pYIHApibrtgNijCSRDzGArpVaF4m3bbOLp8yvUM%3D%26rdoPaym
ents%3DrdoNewCreditCard%26lstCCType%3D9%26txtNewCCNumber%3D4412124112341234%26lstNewCCMonth%3D01%26lstN
ewCCYear%3D2010%26txtNewCVV2%3D222%26btnContinue2%2Ex%3D18%26btnContinue2%2Ey%3D19

HTTP/1.1 200 OK
Date: Thu, 21 Jan 2010 03:55:15 GMT
Server: Apache/2.2.3 (Debian) mod_python/3.3.1 Python/2.5.1 mod_ssl/2.2.3 OpenSSL/0.9.8c
Connection: close
Content-Type: text/html; charset=UTF-8

Upromise also transmitted my email address. For example, when I logged into Restaurant.com, Upromise’s transmission included my email (yellow):

POST /fast-cgi/ClickServer HTTP/1.0
User-Agent: upromise/3195/3195/UP23806818/0012
Host: dcs.consumerinput.com
Content-Length: 378
Connection: Keep-Alive

md5=26830cfab132bb3122fcf40d8cd0f2f9&ts=1264049936.327&bua=N%2FA&meth=post&eid=303&fid=NULL&bin=24af1f0
&refererHeader=&url=https%3A%2F%2Fwww%2Erestaurant%2Ecom%2Fregister%2Dlogin%2Easp%3Fpurchasestatus%3DRE
GISTER%2DLOGIN%26hdnButton%3DSignin%26txtMemberSignin%3Dedelman%40pobox%2Ecom%26radio%5Fcust%3Dcustomer
%5Fexisting%26txtMemberPassword…

HTTP/1.1 200 OK
Date: Thu, 21 Jan 2010 04:58:56 GMT
Server: Apache/2.2.3 (Debian) mod_python/3.3.1 Python/2.5.1 mod_ssl/2.2.3 OpenSSL/0.9.8c
Connection: close
Content-Type: text/html; charset=UTF-8

All the preceding transmission were made over my ordinary Internet connection just as shown above. In particular, these transmissions were sent in plain text — without encryption or encoding of any kind. Any computer with a network monitor (including, for users connected by Wi-Fi, any nearby wireless user) could easily read these communications. With no additional hardware or software, a nearby listener could thereby obtain, e.g., users’ full credit card numbers — even though merchants used HTTPS security to attempt to keep those numbers confidential.

The Destination of Upromise’s Transmissions: Compete, Inc.

As shown in the "host:" header of each of the preceding communications, transmissions flow to the consumerinput.com domain. Whois reports that this domain is registered to Boston, MA traffic-monitoring service Compete, Inc. Compete’s site promises clients access to "detailed behavioral data," and Compete says more than 2 million U.S. Internet users "have given [Compete] permission to analyze the web pages they visit."

Upromise’s Disclosures Misrepresent Data Collection and Fail to Obtain Consumer Consent

Upromise’s installation sequence does not obtain users’ permission for this detailed and intrusive tracking. Quite the contrary: Numerous Upromise screens discuss privacy, and they all fail to mention the detailed information Upromise actually transmits.

The Upromise toolbar installation page touts the toolbar’s purported benefits at length, but mentions no privacy implications whatsoever.

If a user clicks the prominent button to begin the toolbar installation, the next screen presents a 1,354-word license agreement that fills 22 on-screen pages and offers no mechanism to enlarge, maximize, print, save, or search the lengthy text. But even if a user did read the license, the user would receive no notice of detailed tracking. Meanwhile, the lower on-screen box describes a "Personalized Offers" feature, which is labeled as causing "information about [a user’s] online activity [to be] collected and used to provide college savings opportunities" But that screen nowhere admits collecting users’ email addresses or credit card numbers. Nor would a user rightly expect that "information about … online activity" means a full log of every search and every page-view across the entire web.

The install sequence does link to Upromise’s privacy policy. But this page also fails to admit the detailed tracking Upromise performs. Indeed, the privacy policy promises that Personalized Offers data collection will be "anonymous" — when in fact the transmissions include email addresses and credit card numbers. The privacy policy then claims that any collection of personal information is "inadvertent" and that such information is collected only "potentially." But I found that the information transmissions described above were standard and ongoing.

The privacy policy also limits Upromise’s sharing of information with third parties, claiming that such sharing will include only "non-personally identifiable data." But I found that Upromise was sharing highly sensitive personal information, including email addresses and credit card numbers.

In addition, Upromise’s data transmissions contradict representation in Upromise’s FAQ. The top entry in the FAQ promises that Upromise "has implemented security systems designed to keep [users’] information safe." But transmitting credit card numbers in cleartext is reckless and ill-advised — specifically contrary to standard Payment Card Industry (PCI) rules, and the opposite of "safe." Indeed, in an ironic twist, Upromise’s FAQ goes on to discuss at great length the benefits of SSL encryption — benefits of course lacking when Upromise transmits users’ credit card numbers without such encryption.

The Upromise toolbar offers an Options screen which again makes no mention of key data transmissions. The screen admits collecting "information about the web sites you visit." But it says nothing of collecting email addresses, credit card numbers, and more.

The Scope and Solution

The transmissions at issue affect only those users who agree to run Upromise’s Personalized Offers system. But until last week, that option was set as the default upon new Upromise toolbar installations — inviting users to initiate these transmissions without a second look.

Even if Upromise ceased the most outrageous transmissions detailed above, Upromise’s installation disclosures would still give ample basis for concern. To describe tracking, transmitting, and analyzing a user’s every page-view and every search, Upromise’s install screen euphemistically mentions that its "service provider may use non-personally identifiable information about your online activity." This admission appears below a lengthy EULA, under a heading irrelevantly labeled "Personalized Offers" — doing little to draw users’ attention to the serious implications of Personalized Offers. I don’t see why Upromise users would ever want to accept this detailed tracking: It’s entirely unrelated to the college savings that draws users to the Upromise site. But if Upromise is to keep this function, users deserve a clear, precise, and well-labeled statement of exactly what they’re getting into.

Upromise’s multi-faceted business raises other concerns that also deserve a critical look. The implications for affiliate merchants are particularly serious — a risk of paying affiliate commission for users already at a merchant’s site. But I’ll save this subject for another day.

Upromise’s Response (posted: January 23, 2010)

Upromise told PC Magazine’s Larry Seltzer that less than 2% of their 12 million members were affected. Though 2% of 12 million is 240,000 — a lot!

Upromise staff also wrote to me. I replied with a few questions:

1) How long was the problem in effect?

2) How many users were affected?

3) What caused the problem?

4) I notice that the Upromise toolbar EULA has numerous firmly-worded defensive provisions. (See the entire sections captioned “Disclaimer of Warranty” and “Limitation of Liability” – purporting to disclaim responsibility for a wide variety of problems. And then see Governing Law and Arbitration for a purported limitation on what law governs and how claims may be brought.) For consumers who believe they suffered losses or harms as a result of this problem, will Upromise invoke the defensive provisions in its EULA to attempt to avoid or limit liability?

I’m particularly interested in the answer to the final question. The EULA is awfully one-sided. I appreciate Upromise confirming the serious failure I uncovered. Upromise should also accept whatever legal liability goes with this breach.

Upromise’s Response to My Questions (posted: January 25, 2010)

Upromise replied to my four questions to indicate that the scope of the problem was "approximately 1% of our 12 million members." Upromise did not answer my questions about the duration of the problem, the cause of the problem, or the effect of Upromise’s EULA defenses.

May 13, 2009December 2, 2023

How Google and Its Partners Inflate Measured Conversion Rates and Inflate Advertisers’ Costs

When advertisers measure the effectiveness of their pay-per-click ad campaigns, advertisers systematically assume additionality, i.e. that the sales that follow a paid click are sales that would not have happened without the ad platform’s assistance. This assumption offers intuitive appeal: If a user clicked an ad and then bought the advertised product, by all indications the ad platform should be thanked for finding and sending an interested customer. Or should it?

As it turns out, Google and its partners systematically inflate advertisers’ conversion rates by interceding in transactions advertisers would otherwise have received for free. This conversion-inflation syndication fraud overstates the true effectiveness of the ads Google delivers — leading advertisers to pay more than they should.

In this piece, I offer four examples of Google and its partners inflating conversions to claim credit for traffic advertisers would otherwise have received for free. In each example, an advertiser intensely measuring its conversion rate would mismeasure the true effectiveness of its ads, and would end up overpaying for traffic that is far less valuable than reporting systems suggest.

Traffic source	How users are found	What would have happened had Google and its partners not interceded
WhenU – adware	User requests advertiser’s site. Adware covers advertiser’s site with pay-per-click listings.	Advertiser’s site displays as usual, with no covering popup. User stays at advertiser’s site, and advertiser pays no PPC fee.
SmileyCentral – toolbar	Reconfigured browser tricks user into running a “search” for a site’s domain name.	User’s browser retains its ordinary configuration. User runs a direct navigation, and advertiser pays no PPC fee.
Typosquatting	User misspells advertiser’s domain name.	User’s browser shows a list of alternatives, and user selects one — reaching advertiser’s site at no charge. Or, user sees an error page, notices the misspelling, and corrects the spelling to reach the advertiser’s site without a PPC fee.
Chrome – browser suggestions	User typing a web address is encouraged to run a search instead.	User finishes typing the site’s web address and reaches the advertiser’s site without a PPC fee.

WhenU Covers Advertisers’ Sites with Advertisers’ Own Google Ads

WhenU covers RCN with its own Google ads — chargingad fees for traffic RCN would otherwise have received for free.

PPC advertisers (e.g. RCN)
money

viewers
Google
money

viewers
InfoSpace
money

viewers
Nbcsearch
money

viewers
LocalPages
money

viewers
WhenU

The money trail – how funds flow from advertisers
to Google to WhenU.

Through popups shown to users already at advertisers’ sites, WhenU (and its partners) charge advertisers for traffic they would have otherwise received for free. Google passes along these clicks through its advertising platform, and Google charges advertisers as if these were genuine leads, even though in fact these users were already on advertisers’ sites.

In testing of May 9, 2009, I browsed the web site RCN.com. Advertising software (generously, “adware”) from WhenU popped open the window shown at right — covering more than 80% of the RCN site with a list of pay-per-click ads, among them a prominent ad for RCN. I clicked the RCN ad, and I was taken back to RCN. See screenshots detailing the full sequence, or a screen-capture video.

As a provider of high-speed Internet access (with attendant concerns for user security, PC reliability, and tech support expense), RCN is unlikely to advertise with a notorious adware program like WhenU. Nor is RCN likely to want to show its ads to users already at rcn.com — users who RCN has already managed to reach. So how did RCN’s ads end up in this unfortunate placement? Using a network monitor, I confirmed the full sequence of intermediaries: WhenU and its MediaTraffic ad system sent traffic to LocalPages, which redirected to Nbcsearch, which forwarded the traffic to Infospace, which finally passed the traffic to Google. Google in turn paid Infospace, which paid Nbcsearch, which paid LocalPages, which paid WhenU. See the diagram at right and the full packet log.

For RCN, this placement is a rotten deal. RCN has already paid to get a user to its site — perhaps via a postcard, TV advertisement, display ad, or other paid search activity. But then WhenU intercedes and puts a roadblock in front of that user, in the form of the popup at right. A typical user presented with that popup will click the RCN entry to get back to RCN and continue the signup process. But then RCN pays twice to reach a single user.

Meanwhile, if RCN is tracking conversion rates, it will notice that this WhenU/Google placement seems to have a high conversion rate — reflecting that this ad was shown to users already on the verge of signing up with RCN. So in all likelihood, RCN will increase its Google bid to attempt to obtain more traffic of similar (apparent) quality. But the supposed high conversion rate is misleading at best: Since these are users who were already at the RCN site, without any intervention by Google or WhenU, it is nonsense to credit Google or WhenU for resulting sales.

This ad placement also lacks the labeling required by FTC policy and precedent. For one, all sponsored search ads are to be labeled as such, pursuant to the FTC ‘s 2002 instructions. But look closely at the popup screenshot. On my ordinary 800×600 screen, no such label appears. Furthermore, the FTC’s Direct Revenue and Zango complaints, decisions, and orders reveal an additional duty that adware vendors specifically and clearly label each popup with, among other information, a statement that the popup is an advertisement. (See Direct Revenue Decision and Order, provision VI.(1), and Zango Decision and Order, provision VI.(1).) Here, the popup bears the WhenU icon and even a phone number, but it lacks any disclosure that the window’s listings are advertisements. I gather the required label would ordinarily appear on a sufficiently large screen, but the FTC’s policies make no exceptions for users with small screens. Indeed, as netbooks gain popularity, small screens are increasingly common.

These ad placements are particularly troubling because they have continued for months on end. I first observed substantially similar placements on February 7, 2009, though I have reason to think the placements began well before then. Furthermore, Google has been on actual notice of these practices for 3+ months: I first reported these placements to the public in my lunch keynote at the INTA Trademark Law and the Internet conference on February 10, 2009. I posted my slides that very day, and slides 23-24 show substantially this same set of relationships. Importantly, Google’s Rose Hagan, Senior Trademark Counsel, was present in the audience, and she responded to this portion of the talk by promising to investigate. But despite her presence, my clear posting of the parties responsible, and a three month opportunity to act, Google has nonetheless failed to sever these relationships.

Plenty more could be said about WhenU. I have personally observed a wide variety of deceptive WhenU installations, including even WhenU installations via security exploits. (I never had occasion to post those videos to my public site, but I have them on file.) The Google-funded StopBadware declared multiple WhenU-bundlers to be “badware” (1, 2, 3) based on WhenU’s automatic startup, disruptive pop-ups, and other “bad or undisclosed” behaviors. But I doubt Google will defend its WhenU placements, so I’ll save full critique of WhenU for another day.

IAC’s SmileyCentral Grabs Advertisers’ Organic Traffic to Show Google Ads

Standard web browsers place a search bar at top-left. Click that box, type an address, and press enter to reach a site.

With SmileyCentral installed, a “direct navigation” request for www.verizon.com yields search results, not the Verizon site.

PPC advertisers (e.g. Verizon)
money

viewers
Google
money

viewers
IAC/SmileyCentral

The money trail – how funds flow from advertisers
to Google to IAC/SmileyCentral.

By reconfiguring users’ web browsers, IAC’s SmileyCentral toolbars charge advertisers for traffic they would otherwise have received for free. Google passes along these clicks through its advertising platform, and Google charges advertisers as if these were genuine leads, even though in fact these are users who were specifically and unambiguously trying to reach advertisers’ sites directly.

Since the earliest web browsers, a user seeking a particular web site clicks in the browser’s upper-left text box, types the desired address, and presses Enter. See the first inset image at right — standard Internet Explorer 6, offering exactly this layout to request a site.

But suppose a user installs the “SmileyCentral” toolbar from IAC (the advertising powerhouse that also owns Ask.com, Match.com, and more). SmileyCentral modifies longstanding browser layout by pushing a user’s Address Bar to the right, and inserting at left a search box where users naturally expect the Address Bar to appear. Then, when a user goes to the top-left box and enters a domain name, seeking a direct navigation to the specified site, SmileyCentral runs a search instead. See the second inset image at right — the result of typing www.verizon.com, then pressing Enter, into the top-left box. Notice that the user receives a list of search ads for Verizon, even though the user asked for Verizon by its correct web address.

IAC/SmileyCentral’s search results increase advertisers’ costs. Consider user behavior upon reaching the listings shown at right. In all likelihood, a user facing these listings will click one of the top links — perhaps the first listed (to verizonwireless.com) or the second (which specifically indicates it is the “Verizon Official Site”). But these are sponsored links. Every time a user clicks one of these links, Verizon pays a fee to Google, which in turn pays IAC/SmileyCentral. (To confirm Google’s role, see the packet log.)

As in the WhenU example above, this placement is a bad deal for advertisers. Had it not been for IAC/SmileyCentral’s tricky toolbar, these users would have directly reached the sites they requested. Instead, IAC/SmileyCentral grabs the users and sends them to lists of ads — saddling advertisers with unnecessary advertising expense.

Here too, advertisers are likely to be tricked if they attempt to assess the value of this traffic based on its conversion rate. The conversion rate may well be high — for these users asked for advertisers by name, suggesting that the users are nearly ready to make purchases. But the traffic is still a bad deal for advertisers: By all rights, this is still traffic advertisers should have gotten for free.

This placement is all the worse for advertisers because IAC makes ad clicks excessively easy. Even a click 230 pixels to the right of a Verizon Wireless ad would be treated as a paid click “on” that ad. See video at 0:23, and accompanying screenshot, showing that the hyperlink area extends far beyond the text of the ad.

IAC may claim that users understand that, with MyWebSearch installed, the top-left box no longer allows direct navigations by domain name or URL. But IAC often sneaks its toolbars onto users’ computers in ways that don’t obtain meaningful consent: I previously demonstrated nonconsensual installations through security exploits and undisclosed bundles. IAC’s installations often target kids (as I have repeatedly documented). And even a direct installation from Smileycentral.com places a picture of the post-installation browser layout in a bottom-of-page image, below the fold on 800×600 screens and easily overlooked on larger screens. IAC’s use of the generic “My Web Search” label (just as in “My Documents”, “My Computer”, etc.) further compounds users’ sense that this box is part of Internet Explorer. Combining IAC’s user focus with its choice of labeling and positioning, IAC creates conditions in which users are bound to be confused.

Typosquatting: Cmcast.com, MediaLogik, and Thousands More Intercept Users’ Misspellings to Show Google Ads

Requesting cmcast.com (s.i.c.) yields a page of Google ads.

If no typosquatter had registered cmcast.com, a user would have reached this page and found Comcast without charge.

PPC advertisers (e.g. Comcast)
money

viewers
Google
money

viewers
Typosquatters & brokers (e.g. MediaLogik)

The money trail – how funds flow from advertisers
to Google to typosquatters.

By paying partners to register typosquatting sites and to send the resulting clicks to Google’s ad platform, Google charges advertisers for traffic they would otherwise have received for free. Google charges advertisers as if these were genuine leads. Yet had typosquatters not registered these domains, ordinary web browsers would have assisted users in reaching advertisers’ sites without charge.

A staggering number of typosquatting web sites target users who misspell the domain names of famous web sites. For example, in my INTA presentation this spring, I showed 200+ typosquatting sites all targeting variations of “cartoonnetwork.com.” I’ll have further thoughts on typosquatting in a future article. But for present purposes, two facts are most important: Typosquatting sites are overwhelmingly funded through pay-per-click ads, and these days Google is the advertising provider of choice for most typosquatters. (My preliminary analysis indicates that Google funds more than 75% of those typosquatting sites that show Google ads.)

Consider a user who misspells comcast.com, instead typing cmcast.com (s.i.c.). Such a user will receive the first screen shown at right, presenting a series of pay-per-click links for Comcast. In all likelihood, such a user will then click a paid link to Comcast — meaning Comcast has to pay Google an advertising fee. Google in turn pays the typosquatter which had the foresight to register a domain. See the packet log.

(In some instances, traffic flows from a typosquatter to one or more brokers or intermediaries, then to Google and finally to the advertiser. As to cmcast.com: The packet log confirms that Google pays MediaLogik of Hong Kong. I cannot readily determine whether MediaLogik registered this domain for its own account, or whether MediaLogik brokers ads for some other registrant. Based on the domain’s hosting in the Bahamas, its monetization through a Hong Kong service provider, and its display of Google PPC ads, it is highly unlikely that this domain was authorized by Comcast.)

Although these typosquatting sites ultimately direct users where the users were trying to go, typosquatters leave targeted advertisers importantly worse-off. Had it not been for the typosquatter, the user would have received a standard browser page identifying the typo and, in general, referring the user to the requested site without charge. See the second screenshot at right, showing a request for cmcast.com in a standard installation of Internet Explorer 6. So, even if no typosquatter had registered cmcast.com, the user would still reach Comcast with equal ease; the typosquatter does not actually make it easier for the user to reach Comcast. But notice that a standard IE6 error page shows few ads — here, just one small ad, at far right — whereas the MediaLogik page showed all ads, front and center. So passing the user’s misspelled request to a standard IE landing page, rather than to a typosquatter, would spare Comcast an expensive Google pay-per-click fee.

Notably, typosquatting exactly fits the traffic pattern detailed in preceding examples. First, Google and its partners identify users who are already trying to reach a given advertiser. Then Google and its partners intercede — here, by registering a typosquatting domain. The user thus stumbles into Google’s ad listings and clicks through to the advertiser’s site — letting Google charge the advertiser a fee, even though the user would have reached the advertiser even without Google’s assistance.

Google Chrome Suggestions Divert Users from Direct Navigation to Search

Typing 'expedia' yields a suggestion that users search Google (simply by pressing 'Enter') rather than visiting Expedia.com directly (third entry -- requiring a mouse-click or multiple keystrokes). Meanwhile, the second link ('expedia/') yields an error -- discouraging future exploration of green direct-navigation listings.

Typing “expedia” yields a suggestion that users search Google (just press “Enter”) rather than visit Expedia.com directly (third entry — requiring a mouse-click or multiple keystrokes). The second link (“expedia/”) yields an error — discouraging future exploration of green direct-navigation listings.

As users type web addresses into Google’s Chrome web browser, Chrome’s “Omnibox” address bar suggests that users run searches instead of direct navigation. See the screenshot at right, showing the Omnibox’s suggestion after I typed “Expedia” and before I typed the final “.com”.

If a user accepts Chrome’s suggestion — by clicking the “Search for …” drop-down, or by merely pressing Enter — the user is taken to a page of Google search results for the specified term. See screenshot and screen-capture video. As usual, Google’s most prominent search result is an advertisement. If the user clicks the ad, the advertiser pays a pay-per-click fee — even though the user was nearly at the advertiser’s site, for free, before Chrome interceded with its “Search for…” suggestion.

To complete a direct navigation to the Expedia site, without passing through Google search results, a user must ignore Google’s suggestion and continue typing (“.com”), click the “expedia.com” entry (third on Google’s autocomplete list), or use the keyboard (down-down-enter) to navigate manually. In principle these steps are straightforward — just a few extra seconds. But by pushing default behavior from direct navigation to search, Google makes searches that much more frequent — yielding that many more ad-clicks, that much more revenue to Google, and that much more expense for advertisers.

Chrome further encourages searching by mixing useful autocomplete direct navigation listings (e.g. “www.expedia.com/”) with nonfunctional listings. Notice that the second entry on Chrome’s autocomplete drop-down is “expedia/” (s.i.c.) — not a valid domain name. If a user clicks that entry, the user suffers a delay followed by a DNS error — hardly a good user experience. (video) By placing this nonfunctional result prominently in the autocomplete drop-down, above the one working direct link to Expedia, and in the same distinctive green font as the working direct link, Chrome discourages users from exploring direct links. After all, if the prominently-listed “expedia/” link did not work, users are less likely to try the similar-looking link Google ranked lower.

Although competing browsers also perform searches if users enter malformed text into the Address Bar, competing browsers are less pushy in suggesting and encouraging searches in lieu of direct navigation. Chrome thus extends browser norms through its increasingly forceful suggestion of search, not direct navigation, as the default way to reach a site.

Beyond its effects on advertisers’ costs, Chrome’s Omnibox raises other serious concerns too. For example, Chrome transmits users’ every navigation keystroke to Google — including what users search for, what addresses users request by name, and what addresses users begin to request but ultimately decline to visit. CNET reports EFF and EPIC staff concerned about Omnibox’s privacy implications, and I share their discomfort.

Fair Play and a Way Forward

Notice similarities across all four examples:

In all four examples, Google and its partners intercede to divert traffic that, but for their intervention, would reach advertisers’ sites directly — without advertisers incurring any advertising expense.
In all four examples, Google and its partners ultimately pass the traffic back to the advertisers users were trying to reach — but only after collecting pay-per-click advertising fees.
In all four examples, if an advertiser attempts to measure its conversion rate, it will conclude that it receives traffic at attractive prices — at effective cost-per-acquisition consistent with its objectives. Standard conversion rate measurements will overlook the fact that, were it not for the intervention of Google and its partners, the advertiser would have received this traffic for free.

Not all advertisers measure conversion rates. For one, some advertisers may take Google at its word, rather than attempting detailed and rigorous monitoring of Google’s effectiveness. Furthermore, for some advertisers, conversion rates are unmeasurable. (Advertisers may have offline sales process, rather than online sales. Certain advertisers may seek brand awareness rather than immediate purchases.) But for advertisers that measure conversion rates and adjust bids accordingly, inflated conversion rates are of grave concern. In particular, inflated conversion rates yield records that seem to indicate that campaigns are working well and delivering fair value, when the truth might be exactly the opposite.

Aggrieved advertisers could sue Google over these placements. But Google imposes terms and conditions that discourage advertisers from pursuing such claims. Google’s Advertising Program Terms purport to “disclaim[] all warranties … [and] guarantees regarding positioning, levels, quality, or timing of costs per click, … clicks, conversions, or any other results” (internal numbering omitted). Google further claims that “Any refunds for suspected invalid impressions or clicks are within Google’s sole discretion.” Google also insists that advertisers’ sole remedy is advertising credits (never refunds), and Google says advertisers must complain within 60 days of a disputed charge (even if advertisers did not know about the improper charges because the charges were concealed through, e.g., inflated conversion rates). I doubt whether all these harsh provisions are enforceable. But if these provisions are enforceable, they would tightly limit advertisers’ ability to obtain redress from Google. Even if these provisions are unenforceable, their mere presence serves to discourage advertisers from filing complaints, whether informal (through Google’s customer service staff) or in court.

In a recent presentation defending its competitive posture and overall approach, Google claimed “advertisers pay what a click is worth to them” (slides 17-21). But does Google have the right to charge such a fee for all traffic, even the traffic advertisers receive without any Google assistance whatsoever? Few advertisers would tolerate such charges, if presented explicitly. Nor does Google ever seek permission to charge advertisers for their existing traffic. Yet in the future Google seems to envision, all manner of ruses intercede to claim Google delivered a customer, when in fact the customer reached the advertiser’s site without bona fide assistance from Google.

More generally, when Google and its partners overstate the effectiveness of the ads they deliver, advertisers cannot make well-informed decisions about which ads to buy or how much to be willing to pay. Danny Sullivan calls AdWords pricing a “black box,” and I certainly share that sentiment. But here, Google’s actions are even worse than opacity: By claiming to have delivered traffic advertisers would have received anyway, Google tricks advertisers into paying for that traffic — and even tricks advertisers into concluding, mistakenly, that the traffic is a good deal.

It’s also hard to reconcile Google’s WhenU and IAC/SmileyCentral placements with Google’s “Software Principles” requirements. With bundled installations disclosing WhenU’s presence only midway through installation, WhenU is anything but “upfront” (contrary to Google’s “upfront disclosure” section heading). Showing the generic “My Web Search” toolbar label after users requested the distinctively-named SmileyCentral, Ask’s offering similarly flunks Google’s call for “clear behavior.” I could continue. But even if these programs satisfied Google’s criteria, they still fall short of advertisers’ reasonable expectations — for they still intercede to claim traffic advertisers they did nothing to deliver.

Looking forward, I see two key principles. First, ad platforms must deliver genuine, incremental traffic — not just intercept and repackage traffic advertisers were already going to receive for free. Second, ad platforms need to stand behind their products — abandoning one-sided attempts to disclaim responsibility, and instead offering meaningful commitments to provide what they promise. In both these respects, Google currently falls short.

October 14, 2008December 2, 2023

Hydra Media’s Pop-Up Problem — Ten Examples

Late last month, I posted an example of Vomba using a Hydra Media affiliate link to defraud VistaPrint — charging VistaPrint for traffic VistaPrint would otherwise have received for free. This was only the second Hydra Media advertising fraud example I had posted on my public web site. (The first showed similar Blockbuster fraud in spring 2007.) So some might think Hydra Media doesn’t have a big adware, spyware problem. Indeed, that’s exactly what Hydra claimed in a comment to ReveNews.

Despite Hydra’s claims of appropriate and ethical behavior, my observations indicate the contrary. Looking back to June 2007, across all my AutoTester’s browsing, my AutoTester has seen a remarkable 1,343 instances of spyware sending traffic to/through Hydra Network — 56 incidents in the past two weeks alone.

Ten Specific Examples

Using my Automatic Spyware Tester, I recently found the following Hydra Media spyware/adware incidents.

Overwrites cookies of any other affiliates previously slated to receive commission for making a referral to the advertiser.

#	Date	Spyware	Advertiser	Traffic flow	Hydra ID	References
1	10/1/08	Zango	Survey Club	Zango > Hydra > Survey Club	27352	video, packet log
2	10/2/08	Outerinfo	Bidz	Outerinfo > MediaTraffic > Hydra > Bidz	17203	video, packet log
3	10/4/08	Vomba	Gevalia	Vomba > Hydra > Gevalia	15387	video, packet log
4	10/4/08	Vomba	Gevalia	Vomba > Offerweb > Hydra > Gevalia	5830	video, packet log
5	10/4/08	Vomba	Video Professor	Vomba > Hydra > Video Professor	6102	video, packet log
6	10/11/08	Zango	Gevalia	Zango > Hydra > Gevalia	11427	video, packet log
7	10/11/08	Vomba	Gevalia	Vomba > Doubleyourctr > Hydra > Gevalia	9136	video, packet log
8	10/11/08	Vomba	Reunion.com	Vomba > Artur2 > Hydra > AdShuffle > Reunion	28138	video, packet log
9	10/11/08	Targetsaver	Reunion.com	Targetsaver > Kchuentracking > Hydra > AdShuffle > Reunion	27039	video, packet log
10	10/12/08	WhenU	Omaha Steaks	WhenU > MediaTraffic > Tcshoppingdeals > Hydra > Omaha Steaks	7386	video, packet log
Effects: Targets advertiser with its own affiliate link — thereby charging the advertiser for traffic it would otherwise have received for free. See extended discussion in Auditing Spyware Advertising Fraud: Wasted Spending at VistaPrint.

These are just a fraction of the Hydra incidents my AutoTester observed during the past two weeks. But as the “Effects” entry notes, each of these incidents entails charging an advertiser for traffic the advertiser would otherwise have received for free — a strikingly poor deal for the advertiser. Moreover, each of these incidents entails a distinct Hydra affiliate ID, as shown by the ten unique values in the “Hydra ID” column.

Covering Their Tracks

It is difficult to know whether Hydra and the targeted merchants were aware that these affiliates were using spyware/adware to claim commissions on traffic merchants would otherwise have received for free. In principle it is possible that the affiliates told Hydra and the merchants what they were doing — though I find that unlikely at best. But in each instance, the packet logs reflect that these affiliates’ traffic to merchants did not affirmatively indicate that the traffic came from spyware or adware. In principle such designation could be provided by “sub=” tags on affiliate links, by HTTP Referer headers, or by other indications. But these packet logs include no such disclosure.

In incidents 9 and 10, it seems these affiliates and their spyware/adware partners took additional steps to cover their tracks. In incident 9, Targetsaver invoked the affiliate’s link to LynxtTrack and onwards to Reunion.com, without an on-screen Reunion window appearing, whether as a popup, popunder, Taskbar entry, or otherwise. See the incident 9 video — showing only a brief blip at 0:37 when Internet Explorer briefly loses then regains focus. (Notice the change in color of the Internet Explorer title bar.) With no meaningful on-screen display to report what occurred, even a sophisticated tester might fail to notice that an affiliate link had been invoked and affiliate cookies had been dropped. Incident 10 also reflects significant obfuscation: WhenU opened the affiliate’s link in a window that was initially blank (0:25-0:28). WhenU then moved the window off-screen, and even when I manually clicked the window’s Taskbar entry (video at 0:33), the window did not appear. Only by right-clicking and choosing Maximize (0:38) was I able to force the window to appear in the active screen space, letting me demonstrate and confirm that the window did indeed load the Omaha Steaks site through a Hydra affiliate link.

Taking from Other Affiliates

Not only do these affiliates charge merchants for traffic merchants should have received for free, but these affliates also take commissions that should have flowed to other affiliates. Suppose an ordinary web site affiliate (“A” for short) recommends, e.g., Gevalia. If a user clicks A’s affiliate link to Gevalia, and if a user later makes a purchase from Gevalia, then A is supposed to receive a commission on the sale. But if one of these spyware/adware-using affiliates jumps in with its own link, A gets nothing.

I first demonstrated this commission-stealing in July 2004. See my proof of Zango (then “180solutions”) claiming commissions that would otherwise be paid to other affiliates, as to traffic for Crucial, Freshpair, TGW, and Valuemags. This problem remains in full effect.

Legitimate rule-following affiliates rightly disdain spyware and adware for, among other reasons, their tendency to take commissions that would otherwise flow to legitimate affiliates. For example, my VistaPrint piece last month prompted a spirited response from Linda Buquet at the 5 Star Affiliate Programs Blog (“adware also steals from Vista Print’s HONEST AFFILIATES!”) and a discussion at affiliate forum ABestWeb.

Next Steps

In a recent MediaPost article, Hydra claimed it is “complying with the instructions [it has] been given.” Perhaps a few aggressive marketers are willing to look the other way on spyware and adware issues. But all of the advertisers listed above? All these companies are happy to pay commission on traffic they would otherwise have received for free? Pay commission for placements through spyware known to arrive on users’ computers without users’ consent? It strains credibility. By posting these examples, I intend to alert the corresponding advertisers to the nature of the traffic Hydra is sending them — letting the advertisers decide for themselves whether this is a suitable allocation of their marketing budgets. As detailed in my Wasted Spending at VistaPrint piece, my firm view remains that these placements offer advertisers no bona fide benefit, and that no fully-informed advertiser would willingly pay for such traffic.

Meanwhile, others are also observing Hydra placements through spyware and adware. In a comment at ReveNews, ShareASale CEO Brian Littleton noted that he sees Hydra affiliates using spyware and adware to cover and supersede traffic his company provides to advertisers — reducing earnings of ShareASale and ShareASale’s affiliates. Brian generously offers to provide Hydra with reports of these practices, and I encouraged Brian to post his findings on the web for all to see.

Hydra’s “AdControl” service promises “positive, proactive protection” to provide “control over where [advertisers’] ad[s] [are] placed.” Hydra says it “guards against compliance problems from every angle” to assure that ad placements are “safe[,] secure [and] profitable.” Furthermore, Hydra claims to provide “tough affiliate pre-screening and policing to assure quality.” I applaud these objectives, but it seems Hydra has more to do in order to deliver the ethical, compliant, profitable placements it has promised.

October 7, 2008December 2, 2023

CPA Advertising Fraud: Forced Clicks and Invisible Windows

At first glance, conversion-contingent advertising (cost-per-action / CPA, affiliate marketing) seems a robust way to prevent online advertising fraud. By paying partners only when a sale actually occurs, advertisers often expect to substantially eliminate fraud. After all, if commissions are only due when a user makes a purchase, what can go wrong? Unfortunately, this view is overly simplistic and, on balance, overly optimistic.

I’ve previously written at length about spyware and adware programs that watch a user’s web browsing in order to claim commission on sales that would have happened anyway. See last week’s examples of six different affiliates cheating VistaPrint through exactly this technique.

But CPA fraud does not require the use of spyware or adware on a user’s computer. To the contrary, I’ve seen plenty of CPA fraud that is entirely web based. Below I present three examples representative of this ongoing problem.

The Basic CPA Relationship

CPA advertising generally oblige an advertiser to pay a commission if three events occur:

A user browses an affiliate’s web site;
A user clicks a specially-coded link to a participant CPA merchant; and
A user makes a purchase from that merchant.

The purchase in step 3 may occur immediately, i.e. within a single browsing session. But even if the purchase occurs shortly thereafter, e.g. a day later or even a few weeks later, a merchant will typically credit this purchase to the corresponding affiliate — on the view that the affiliate at least introduced the user to the merchant. This extended credit period is typically known as the “return-days period.”

Example 1: Couponcodesmall Forces Clicks to Drop Buy.com Cookies

The Couponcodesmall Site – Cookie-Stuffing Invisibly

Some affiliates seek to bypass the user-click requirement (event 2 above) by simulating a click on an affiliate link using JavaScript. When the user merely visits the affiliate’s site, the affiliate forces the user’s browser to load an affiliate link — thereby placing affiliate cookies on the user’s PC, and claiming an affiliate commission if the user subsequently makes a purchase from the corresponding merchant.

In 2004, I presented 36 such examples in Cookie-Stuffing Targeting Major Affiliate Merchants, But the problem is ongoing.

In testing this month, I requested a page from Couponcodesmall, a top organic result for Google searches for “buy.com coupon” (without quotes). Couponcodesmall sent more than 65KB of HTML, followed by the following IFRAME:

I preserved a full packet log that shows this IFRAME in context. (Edit-Find on “IFRAME” to skip to the key section.) I also preserved a screen-capture video showing the cookies created after I requested this page — confirming the IFRAME‘s effect. As the HTML instructs, the IFRAME yields no visible on-screen indication — for the IFRAME‘s 5 pixel by 5 pixel size (blue highlighting) leaves too little space for the Buy.com site to be recognized.

Buy.com’s agreement with affiliates requires that affiliates comply with Commission Junction’s Publisher Service Agreement (PSA), and PSA rule 3.a grants credit only when a user “clicks through [a] Link[] to [an] Advertiser.” This affiliate’s IFRAME-delivered forced clicks exactly violate that requirement. If a user merely views this affiliate’s page, without clicking an ad or taking any other action, then this affiliate will receive a 3% to 5% commission on any purchase the user makes from Buy.com within the next 14 days, even though the user never clicked an affiliate link as required under the PSA.

I notified the affiliate program manager for Buy.com, and I gather that Buy.com is taking appropriate action.

Similar infractions remain easy to uncover. My automated testing systems typically uncover a dozen or more violations in a day of searching. I’ve also seen all manner of advances over the popups, popunders, and IMG tags I observed in 2004. For example, I now often observe cookie-stuffing using EMBED tags, OBJECT tags, HTML entity encoding, and doubly-encoded JavaScript.

Example 2: Allebrands Banner Ads Invisibly Load Affiliate Links

Other affiliates load affiliate links and drop affiliate cookies as users merely view a banner ad. From a rogue affiliate’s perspective, this attack is more effective than the attack in Example 1, for the affiliate need not get the user to visit the affiliate’s site. Instead, merely by viewing a banner ad on a third party web page, the affiliate can drop its cookies and obtain a commission on purchases users make from the targeted merchants within the return-days period.

That is, the affiliate bypasses both the user click requirement (event 2 above) as well as the browsing requirement (event 1 above). Removing this additional requirement lets the affiliate claim commission on more users’ browsing that much more easily.

To targeted merchants, this attack is importantly worse than the attack in Example 1. In particular, through this kind of attack, a merchant receives no promotional benefit whatsoever. Under this attack, merchants pay out commission only on sales that would have happened anyway — so every commission paid is entirely wasted.

I recently observed such an attack via a banner ad running on the Yahoo RightMedia Exchange. Merely by viewing an ad from Allebrands, a user’s computer was instructed to load three affiliate links, each in a 0x0 IFRAME. Below is the relevant portion of the HTML code (formatted for brevity and clarity):

GET /iframe3? …
…
Host: ad.yieldmanager.com
…

HTTP/1.1 200 OK
Date: Mon, 29 Sep 2008 05:36:02 GMT
…

<html><body style=”margin-left: 0%; margin-right: 0%; margin-top: 0%; margin-bottom: 0%”><script type=”text/javascript”>if (window.rm_crex_data) {rm_crex_data.push(1184615);}</script>
<iframe src=”http://allebrands.com/allebrands.jpg” width=”468″
height=”60″ scrolling=”no” border=”0″ marginwidth=”0″
style=”border:none;” frameborder=”0″></iframe></body></html>

GET /allebrands.jpg HTTP/1.1
…
Host: allebrands.com
…

HTTP/1.1 200 OK
…

The three IFRAMEs (green highlighting) load three separate affiliate links in three separate windows. Because these windows are each set to be 0 pixels wide and 0 pixels tall (blue highlighting), they are all invisible.

I preserved a full packet log of the entire HTTP sequence — showing traffic flowing from the underlying Smashits web site to Right Media to Allebrands to the target affiliate programs. (Edit-Find on “allebrands” to skip to Allebrands’ code.) I also notified the targeted merchants — McAfee, Microsoft, and Symantec. They’re taking appropriate action.

Allebrands’ Decoy Ad

Notice Allebrands’ tricky use of the misleadingly-named /allebrands.jpg URL (yellow highlighting). In particular, Allebrands instructed Right Media to send traffic to http://allebrands.com/allebrands.jpg — a .JPG extension, so seemingly an ordinary JPEG compressed image. But despite the URL’s extension, the URL actually provided ordinary HTML — creating the A HREF, IMG, and IFRAME‘s set out above. Meanwhile, if a user happened to look at this ad, the user would see only the http://allebrands.com/images/allebrands.JPG image specified by the IMG tag (pink highlighting; image shown at right). Because the IFRAMEs are invisible (blue highlighting), the IFRAMEs yield no on-screen display whatsoever.

In my testing, Allebrands distributed its rogue banner ad via a variety of web sites. One that particularly caught my eye was Smashits, a spyware-delivered banner farm which buys widespread pop-up traffic and shows voluminous ads. Beyond Smashits’ dubious traffic origins, Smashits is also notable for its placement of ads in invisible windows: Via the two-row FRAMESET presented below, Smashits creates a 0-pixel-tall “part1” frame of /audio/empty.html, which in turn ultimately displays the Allebrands ad at issue.

Reviewing the packet log in the context of my prior observations of Smashits’ spyware-originating traffic, the full sequence of relationships proceeds as follows: A variety of spyware sends traffic to Smashits (often via the MyGeek / AdOn Network / Mynaagencies run-of-network ad loader), and some users may affirmatively request the Smashits site. Smashits creates a 0-pixel-tall FRAME row in which to load ads off-screen. In that frame Smashits sends traffic to Traffic Marketplace, which redirects the traffic to Theadhost, which redirects it to RightMedia Exchange, which selects an ad from Allebrands, which stuffs cookies to claim commission from the three target affiliate programs.

Who is Allebrands? Allebrands’ web site offers no contact information, and Allebrands’ Whois is equally uninformative. But Allebrands’ DNS servers reside within creativeinnovationgroup.com, and Creativeinnovationgroup’s Whois references a Simon Brown at 700 Settlement Street in Cedar Park, Texas. Google Maps confirms that this is a bona fide address — seemingly a residential unit in a development.

Example 3: Avxf Stuffing Amazon and Hostgator Cookies through Signature IMG Tags in DealOfDay Forum

In Example 1, Couponcodesmall managed to lure a user to its own web site — in part through successful search engine optimization. In Example 2, Allebrands bought traffic from Right Media. In this Example 3, affiliate rogue Avxf manages to stuff cookies using others’ traffic — without paying for that traffic.

To get traffic, Avxf places images in the footer of a message it posts to a DealOfDay.com forum discussion. The associated HTML:

Originally Posted by <strong>somerset1106</strong> …

Ditto. I am still researching some other sites that are similar. If I find out any information I will keep ya posted. …

Avxf’s footer specified two .JPG URLs, /img16.jpg and /img17.jpg — seemingly image files based on their use of the standard .JPG file extension. But in fact these URLs redirect to affiliate programs for HostGator and Amazon:

GET /img16.jpg HTTP/1.1
…
Host: www.avxf.com

HTTP/1.1 302 Found
…
Location: http://secure.hostgator.com/cgi-bin/affiliates/clickthru.cgi?id=dsplcmnt01
…

GET /img17.jpg HTTP/1.1
…
Host: www.avxf.com

HTTP/1.1 302 Found
…
Location: http://www.amazon.com/?Fencoding=UTF8&tag=qufrho-20

Avxf Cookie-Stuffing:
The Resulting On-Screen Display

The resulting two pages then go on to drop affiliate cookies as usual. Thus, if a user makes a purchase at Amazon or Hostgator within their associated return-days periods, then Avxf gets paid a commission. The only on-screen indication of cookies being dropped is the two “broken image” icons shown at right — indications that something is missing, but in no way sufficient to inform a typical user (or even many advertising professionals) of what is occurring. Nonetheless, if a targeted user makes a purchase from Amazon within 24 hours of receiving Avxf’s forced click, or if a targeted user signs up with Hostgator within 30 days, then Avxf receives a commission.

I preserved a full packet log of the underlying HTML and redirects, showing Avxf’s images and redirects in context. (Edit-Find on “avxf” to skip to the code at issue.) I also preserved a screen-capture video confirming the destinations of the broken images.

Avxf’s practices violate applicable policies at Amazon and Hostgator. Amazon’s Associates program allows credit only if a customer “click[s] through” a special link (agreement 4¶1), whereas no click occurs in the example shown above. Furthermore, Amazon specifically prohibits atempts to “caus[e] any page of the Amazon Site to open in a customer’s browser other than as a result of hte customer clicking on a Special Link on [an affiliate’s] site” (agreement 4¶4). Similarly, the HostGator Affiliate Agreement prohibits the similar practice of forcing clicks through IFRAMEs (except “on pages or sites in which the other content represented on the site is related to HostGator” — an exception unavailable here, since the DealOfDay site is entirely unrelated to HostGator).

Who is Avxf? The Avxf web site offers adult content, but no mailing address on its Contact Us page. However, the site’s Whois offers a name and address: Kyle Hahn of Muncie, Indiana. Google Maps confirms the existence of the specified address, 480 W Skyway Drive.

Consequences – Winners and Losers

I see five basic consequences of these commission schemes:

Fraudsters win from the bogus commission they receive, despite failing to provide merchants with a bona fide marketing benefit.
Merchants pay extra commissions without getting anything in return. In particular, merchants pay commission on sales they would have made anyway. Moreover, merchants overestimate the effectiveness of their CPA marketing programs: Merchants mistakenly conclude that their CPA programs yielded sales that in fact would have happened anyway.
Legitimate affiliates lose commissions that are seized by fraudsters. Whenever an ordinary affiliate was about to receive a commission, but one of these fraudsters jumps in to claim the commission instead, the first affiliate loses a commission it had fairly earned.
Advertising intermediaries profit from the additional commissionable sales that purportedly occur. Affiliate networks typically charge merchants in proportion to the number (or dollar value) of commissionable sales. So every time a rogue affiliate claims commission improperly, the merchant must pay additional fees to the affiliate network.
Affiliate marketing staff typically benefit, directly or indirectly, from growth in the reported size of their affiliate programs. For example, an affiliate manager might earn a bonus for rapid quarter-over-quarter growth in affiliate program size.

In principle, merchants’ losses to fraud should encourage merchants to prevent such scams. But in practice, many merchants fall victim to these attacks. Why?

For one, enforcement requires fact-intensive technical investigation — examining HTML code and packet logs to uncover infractions. The required skills have little overlap with the relationship-building and communication that otherwise drive affiliate marketing.

For some merchants and networks, mixed incentives further hinder efforts to prevent these fraudulent practices. In the short run, affiliate networks and merchants’ in-house affiliate marketing staff stand to lose from rigorous enforcement — reducing their commissionable base, reducing the size of their marketing programs, and distracting their attention from activities that more directly increase their respective short-run compensation. Thus, in the short run, both groups may perceive that they can increase their profits by deemphasizing fraud prevention.

Of course, in the long run, affiliate networks have reputations to protect. Similarly, affiliate marketing staff must consider their duties to their employers; in the long run, employers may learn about these scams and think unfavorably of marketing staff who failed to take effective action to uncover improper practices.

Large Merchants at Heightened Risk

For many cookie-stuffing attacks, large merchants are at highest risk. For example, Avxf is essentially betting that the users who read DealOfDay will subsequently go on to make purchases from Amazon. As to Amazon, that’s a safe bet, for many users buy from Amazon with remarkable regularity. But if Avxf were to target a lesser-known merchant, it would face tougher odds and lower earnings.

Thus, these random cookie-stuffing attacks (as in Examples 2 and 3) tend to target large merchants. In contrast, SEO-based attacks, as in Example 1, can prey on CPA merchants of any size.

Prevention and Response

For merchants and networks seeking to uncover and prevent these practices, I see three clear ways forward:

Analyze statistics already on hand . Look for unusually high click-through rates, unusually low conversion rates, blank or unexpected HTTP Referer headers, unusual HTTP User-Agent headers, long delays between clicks and sales, and other errata. But beware of affilates who manage to manipulate these statistics.
Provide a report / complaint page. It’s surprisingly difficult for independent affiliates, users and researchers to report fraud to many online marketers. But such reports can be extremely useful — particularly when gathered by those with a special interest in catching these scams. There’s ample evidence that affiliates enjoy reporting scams: In the ParasiteWare forum at ABestWeb, affiliates and others analyze and reveal improper marketing practices; some merchants pay bounties to anyone reporting fraud by their affiliates (1, 2).
Conduct hands-on testing. Browse the web looking for such scams. Run a network monitor to detect any unexpected “click” events. Or, design appropriate software to conduct such tests automatically.

Separately, merchants and networks can sensibly deter violations through tough penalties. At present, affiliates face little downside to attempting to defraud most merchants. In Deterring Online Advertising Fraud Through Optimal Payment in Arrears, I suggest a different approach — paying affiliates more slowly so that they face greater losses if they are found to be cheating. Meanwhile, some merchants have resorted to suing fraudulent affiliates. See eBay v. Digital Point Solutions (accusing affiliates of cookie stuffing through invisible code claiming unearned commissions — like the examples above) and Lands’ End v. Remy (accusing affiliates of typosquatting on Lands’ End trademarks and redirecting to Lands’ End’s LinkShare affiliate links).

More generally, merchants ought not assume infallibilityof their online marketing schemes. Certainly CPA marketing programs avoid some of the more obvious problems of pay-per-click marketing (e.g. click fraud), but CPA campaigns remain vulnerable to other kinds of abuse. Shrewd merchants should anticipate what can go wrong, and design and audit accordingly.

September 30, 2008December 2, 2023

Auditing Spyware Advertising Fraud: Wasted Spending at VistaPrint

“VistaPrint is disciplined in operation … [VistaPrint’s] marketing [uses] highly analytically driven fact-based decision-making … [W]e manage those [marketing partners] tightly.”

– VistaPrint CEO Robert Keane in a January 2008 earnings call

For more than four years, I’ve been monitoring online advertising — alerting advertisers, ad networks, and the general public when ad spending finds its way to spyware vendors and when advertisers are getting cheated. (Examples: 1, 2, 3, 4, 5) Every day, my Automatic Spyware Tester browses the web on multiple spyware-infected PCs, watching for spyware-delivered advertising and recording its observations in videos and packet logs.

Although VistaPrint’s Robert Keane claims to effectively oversee VistaPrint’s marketing practices, I emphatically disagree. To the contrary, I’ve seen ample evidence of VistaPrint promoted by spyware and adware programs that sneak onto users’ computers without consent (including through security exploits) and through ruse and deception. In many instances, including as detailed in the examples that follow, the corresponding affiliates trick marketing analytics — claiming commission on sales that would have happened anyway, and thereby overstating the true effectiveness of their marketing efforts.

When VistaPrint is cheated by rogue marketing partners, the costs fall in the first instance to VistaPrint shareholders. Every dollar wasted on worthless advertising leaves that much less for corporate profits, and VistaPrint’s advertising budget is already strikingly large: In 2008, VistaPrint marketing consumed 31.9% of revenue (more than $125 million) while profits were just 9.9% ($39.7 million). Meanwhile, fraud against VistaPrint also harms the general public: Consumers suffer unwanted installations of spyware programs funded, in part, by theft from VistaPrint.

The following table summarizes my recent observations of fraud against VistaPrint:

Ad network	Example incident	Rogue VistaPrint incidents observed
		August – September 2008			January – July 2008
		Number of affiliates	Number of dates	Number of observations	Number of observations
Lynxtrack	Vomba, Hydra Network Affiliate 19934	6	13	18	32
Clickbooth	Vomba, Clickbooth Affiliate 14941 WhenU, MediaTraffic, Iadsdirect, Clickbooth Affiliate 7781	5	13	14	14
CPA Builder (including traffic from Revenue Gateway, from OptInRealBig / CPAEmpire, and from XY7)	Zango, Revenue Gateway Affiliate 12489, CPA Empire, CPA Builder	2	8	9	21
CX Digital Media (Incentaclick)	Vomba, Weclub, CX Digital Media Affiliate 13736	2	2	2	18
Performics (Google)	Deluxe Communications, Smartyseek, Performics	1	5	5	5
direct relationships & other networks	not yet tabulated in full – some examples on file

During August-September 2008, my AutoTester repeatedly observed VistaPrint facing rogue traffic coming from five different ad networks. In the sections that follow, this piece presents an example of fraud by an affiliate from each of the specified networks. But I’ve seen plenty more. My AutoTester has been running for more than a year — preserving tens of thousands of records of online advertising fraud, including 133 other spyware incidents arising out of traffic to VistaPrint. These many incidents confirm the breadth of improper practices by VistaPrint’s marketing partners.

Example 1: Vomba, Hydra Network Affiliate 19934 Claiming Commission on VistaPrint’s Organic/Type-In Traffic

Vomba, Hydra Network Affiliate 19334 Targeting VistaPrint

In testing on September 12, my AutoTester browsed VistaPrint’s site on a computer with Vomba (from Integrated Search Technologies, makers of Slotchbar, XXXtoolbar, WhenU, AdVantage, and more). Vomba popped open a window that sent traffic to Hydra Network (LynxTrack) (affiliate 19934), and Hydra Network in turn forwarded the traffic back to VistaPrint. The result was the screen shown at right — the original VistaPrint window at left/back, with a new popup at front/right.

Crucially, both web browser windows share a single set of cookies. Whether the user buys from the original VistaPrint window or from the popup, cookies tell VistaPrint that this Hydra Network affiliate caused the sale. So VistaPrint will pay this affiliate a commission — even though, in fact, the affiliate did nothing whatsoever to facilitate the sale. I call this tactic “self-targeting” — reflecting that Vomba covers VistaPrint with its own ad. All of the examples presented on this page entail spyware/adware performing this kind of self-targeting attack.

My AutoTester preserved a video of this incident and a packet log of the underlying network traffic.

My AutoTester observed this same affiliate using the same method on three different dates in August-September 2008. My AutoTester also observed five other Hydra Network affiliates similarly defrauding VistaPrint. All told, in August-September, my AutoTester observed 18 such incidents on 13 distinct dates.

My AutoTester’s records indicate that Hydra Network receives substantial spyware-originating traffic. Looking back to June 2007, across all my AutoTester’s browsing, my AutoTester has seen a remarkable 1,287 instances of spyware sending traffic to/through Hydra Network.

Example 2: Vomba, Clickbooth Affiliate 14941 Claiming Commission on VistaPrint’s Organic/Type-In Traffic

In testing on September 12, my AutoTester browsed VistaPrint’s site, again on a computer with Vomba. Vomba popped open a window that sent traffic to Clickbooth (affiliate 14941), and Clickbooth in turn forwarded the traffic back to VistaPrint.

Because both web browser windows share a single set of cookies, this Clickbooth affiliate gets paid a commission whether the user buys from the original VistaPrint window or from the popup. This commission gets paid even though, in fact, the affiliate did nothing whatsoever to facilitate the sale.

My AutoTester preserved a video of this incident and a packet log of the underlying network traffic.

My AutoTester observed this same affiliate using the same tactics on eight different dates in August-September 2008. My AutoTester also observed three other Clickbooth affiliates similarly defrauding VistaPrint. All told, my AutoTester observed 13 such incidents on 12 distinct dates.

My AutoTester’s records indicate that Clickbooth receives substantial spyware-originating traffic. Looking back to June 2007, across all my AutoTester’s browsing, my AutoTester has seen 917 instances of spyware sending traffic to/through Clickbooth.

Example 3: WhenU, MediaTraffic, Iadsdirect, Clickbooth Affiliate 7781 Claiming Commission on VistaPrint’s Organic/Type-In Traffic

In manual testing on September 28, I browsed VistaPrint’s on a computer with WhenU. WhenU opened a popunder that flashed briefly on screen (video at 0:15) but then forced itself to an off-screen location where I could not see it even if I minimize other windows. (See video at 0:24 to 0:30, when I attempted to find the popunder.) By manually right-clicking and choosing “maximize,” I managed to make the popunder visible — confirming that it loaded VistaPrint and noting the affiliate ID number.

Packet log analysis reveals that traffic flowed from WhenU to MediaTraffic (a pay-per-view advertising marketplace also operated by Integrated Search Technologies) to Iadsdirect to Clickbooth (affiliate 7781) to VistaPrint.

As in prior examples, both windows share a single set of cookies. Thus, the WhenU popunder causes the corresponding affiliate to receive a commission if the user makes a purchase — even though the affiliate did nothing to encourage or facilitate a purchase.

I preserved a video of this incident and a packet log of the underlying network traffic.

This advertising fraud by WhenU is particularly notable because WhenU previously claimed to have reformed all unsavory practices. (See e.g. “WhenU CEO Bill Day Cleans House.”) Moreover, WhenU previously touted a TRUSTe Trusted Download certification, and TRUSTe specifically prohibits Trusted Download programs from defrauding advertisers. (See Certification Agreement, Schedule A (“Program Requirements”), provision 14.k.) That said, WhenU has silently left the Trusted Download whitelist. Furthermore, in separate testing of WhenU software, I have recently seen repeated self-targeting fraud improperly claiming commissions from a variety of advertisers.

Example 4: Zango, Revenue Gateway Affiliate 12489, CPA Empire, CPA Builder Claiming Commission on VistaPrint’s Organic/Type-In Traffic

VistaPrint
money

viewers
CPA Builder
money

viewers
CPA Empire
money

viewers
Revenue Gateway
money

viewers
Zango

The Money Trail and Traffic Flow

In testing on September 21, my AutoTester browsed VistaPrint’s site on a computer with Zango. Zango popped open a window that sent traffic to Revenue Gateway (affiliate 12489), which redirected to CPA Empire (formerly OptInRealBig), which redirected to CPA Builder, which in turn forwarded the traffic back to VistaPrint.

The chain of intermediaries adds additional complexity to the relationships. But traffic flows in a continuous forward path: From Zango to Revenue Gateway to CPA Empire to CPA Builder and finally back to VistaPrint. Conversely, revenue flows in the opposite direction: From VistaPrint to CPA Builder to CPA Empire to Revenue Gateway to Revenue Gateway affiliate 13425 to Zango. The diagram at right summarizes the flows of traffic and money.

My AutoTester preserved a video of this incident and a packet log of the underlying network traffic.

During August-September 2008, my AutoTester also observed other incidents wherein spyware waited for a user to browse the VistaPrint site, then sent the user back to VistaPrint via CPA Builder. Beyond this Zango / Revenue Gateway / CPA Empire example, I also observed incidents wherein CPA Empire’s relationship with XY7 was the source of the tainted traffic. All told, my AutoTester has preserved more than 600 incidents of spyware sending traffic to/through CPA Empire, as well as at least 24 incidents of spyware sending traffic to/through Revenue Gateway (though I have reason to believe that some Revenue Gateway incidents were not preserved).

Example 5: 8/17/08 – Vomba, Weclub, CX Digital Media (Incentaclick) Affiliate 13736 Claiming Commission on VistaPrint’s Organic/Type-In Traffic

Vomba, Weclub, CX Digital Media Affiliate 13736 Targeting VistaPrint

In testing on August 17, my AutoTester browsed VistaPrint’s site on a computer with Vomba. Vomba popped open a window that sent traffic to Weclub, which immediately redirected to CX Digital Media (Incentaclick), which in turn forwarded the traffic back to VistaPrint.

See the screenshot at right. My AutoTester preserved a video of this incident and a packet log of the underlying network traffic.

During August-September 2008, my AutoTester also observed another CX Digital Media affiliate using spyware to claim commission on VistaPrint’s organic traffic. All told, my AutoTester has preserved more than 200 different incidents of spyware sending traffic to/through CX Digital Media.

Example 6: Deluxe Communications, Smartyseek, Performics Claiming Commission on VistaPrint’s Organic/Type-In Traffic

In testing on September 14, my AutoTester browsed VistaPrint’s site on a computer Deluxe Communications (which I have repeatedly observed installed through security exploits and otherwise without user consent). Deluxe Communication popped open a window that sent traffic to Smartyseek, which immediately redirected to Performics, then back to VistaPrint.

In typical Deluxe Communications fashion, the popup window entirely covered the window the user had been browsing. But because both windows showed VistaPrint, some users might not notice.

My AutoTester preserved a video of this incident and a packet log of the underlying network traffic.

My AutoTester observed this same affiliate using the same tactics on five different dates in August-September 2008, and my AutoTester also observed Performics traffic during VistaPrint browsing on five other (prior) occasions.

Responsibility and Causation

It’s easy to present VistaPrint as perpetrator: VistaPrint fails to adequately oversee its marketing partners. As a result, VistaPrint’s advertising spending helps fund spyware and adware programs that sneak onto users’ PCs, with serious harms to performance, reliability, and privacy.

But I also see an important sense in which VistaPrint is a victim: VistaPrint’s marketing partners are defrauding VistaPrint by claiming commissions on sales they actually did nothing to cause. Such commissions are entirely wasted, yielding no bona fide marketing benefit to VistaPrint.

By all indications, VistaPrint faces significant difficulties in supervising its marketing partners. Yet other major retailers handle such challenges with greater success. For example, it is comparatively rare to see spyware or adware promoting, defrauding, or attempting to defraud Amazon — even though Amazon spends nearly three times as much on marketing as VistaPrint ($344 million to $125 million).

What could VistaPrint do differently? For one, I question VistaPrint’s choice of marketing partners: As the preceding statistics indicate, I have repeatedly and widely seen spyware and adware sending traffic to many of the partners VistaPrint works with. VistaPrint might face less fraud if it favored marketing partners with a track record of successful supervision of their affiliates.

More generally, an affiliate currently faces little real downside to attempting to defraud VistaPrint. If an affiliate gets caught cheating, VistaPrint will terminate that affiliate, but I see little indication that VistaPrint exacts any meaningful penalty to make the affiliate (or the network providing that affiliate) regret its transgression. In Deterring Online Advertising Fraud Through Optimal Payment in Arrears, I suggest a different approach — paying affiliates more slowly so that they face greater losses if they are found to be cheating. Alternatively, VistaPrint might sue affiliates it learns are cheaters, as in eBay v. Digital Point Solutions and Lands’ End v. Remy.

Yet Keane’s remarks (“highly analytically driven fact-based decision-making”) reveal that VistaPrint is at least attempting to supervise its marketing partners to optimize its spending. How, then, could VistaPrint end up facing so much fraud? I suspect VistaPrint’s analytics actually lead the company astray. Consider the tactics presented above, from the perspective of the information easily available to VistaPrint’s marketing staff. Because these affiliates target users who are already interested in VistaPrint, the affiliates’ conversion rates are likely to be well above average. Moreover, because these affiliates incur limited costs, they can accept payments far below what Google might require. Thus, VistaPrint’s staff are likely to assess these affiliates favorably — without realizing that the traffic at issue is traffic VistaPrint would otherwise have gotten for free. Put differently: Although VistaPrint’s measurements may be very precise, they’re inaccurate because VistaPrint misunderstands the sources of affiliates’ traffic.

In attempting to prevent such fraud, VistaPrint should also examine its ad networks’ incentives. Ad networks often mark up affiliates’ fees: For every dollar VistaPrint is slated to pay to a given affiliate, that affiliate’s network takes another (say) $0.20. As a result, ad networks have a clear incentive to tolerate rogue affiliates: Networks make money from each sale credited to an affiliate, so ejecting rogue affiliates would directly reduce the network’s earnings.

The Big Picture

Spyware-based advertising fraud extends far beyond VistaPrint. Most merchants operating affiliate, CPA, or other conversion-contingent programs face similar fraud. But VistaPrint is a large and, purportedly, sophisticated advertiser. So VistaPrint could appropriately lead by example.

I’m overdue to present further examples of spyware and adware continuing to defraud major merchants. Historically my articles have tended to emphasize the largest US affiliate networks — Commission Junction, LinkShare, Performics. But there’s plenty of fraud through smaller networks too, as well as through networks based outside the US. I’ll present additional examples later this fall.

In January, an Anti-Spyware Coalition workshop asked “Is adware dead?” Some panelists responded substantially in the affirmative. But my AutoTester indicates otherwise. I’m pleased to see that big advertisers no longer advertise directly with major adware vendors. Yet a chain of indirection — adware sending traffic to one ad network, which forwards to another, then finally to an advertiser — continues to promote top brands. Furthermore, spyware-delivered banner farms and ad-loaders are becoming increasingly widespread. This month I saw adware still promoting American Express, Apple, and AT&T — to name just a few of the A’s. There’s plenty of work left to be done.

February 14, 2008December 2, 2023

Critiquing C-NetMedia’s Anti-Spyware Offerings and Advertising Practices

Not every “anti-spyware” program is what it claims to be. Some truly have users’ interests at heart — identifying and removing bona fide risks to privacy, security, stability, or performance. Others resort to a variety of tricks to confuse users about what they’re getting and why they purportedly need it.

This article reports the results of my examination of anti-spyware software from C-NetMedia. I show:

Deceptive advertising, deceptive product names, and deceptive web site designs falsely suggest affiliation with security industry leaders. Details.
The use of many disjoint product names prevents consumers from easily learning more about C-Net, its reputation, and its practices. Details.
High-pressure sales tactics, including false positives, overstate the urgency of paying for an upgraded version. Details.

Note that C-NetMedia is unrelated to the well-known technology news site CNET Networks. Details.

Deceptive advertising, deceptive product names, and deceptive web site design falsely suggest affiliation with security industry leaders.

Some C-NetMedia products are marketed using practices, keywords, labels, and layouts that falsely suggest they come from security industry leaders. This suggestion comes from both the actions of C-Net itself, as well as from the actions of C-Net’s marketing partners.

Google Shows Deceptive Ads for C-NetMedia’s Products

Consider the top three ads for a Google search for “Spybot”, a popular early anti-spyware program (full name “Spybot Search & Destroy”). As shown at right, the top three ads each specifically mention “Spybot” — the first two, in directory names; the third, in its domain name. Furthermore, all three ads also include the distinctive and original phrase “Search & Destroy” that specifically describes the genuine Spybot product. Yet in fact each of these three ads takes users to the unrelated site spywarebot.com (emphasis added) (screenshots: 1, 2, 3). Clicking the first ad immediately takes a user to spywarebot.com via the ClickBank advertising network. As to the second and third ads, traffic flows through independent “landing page” sites which in turn show ClickBank links to promote Spywarebot. These landing pages are hosted on the deceptively-named domains named spybot-sd-info.com and www-spybotcom.com — each further (but falsely) suggesting an affiliation with the genuine “spybot” product.

C-NetMedia partners similarly fill top ad spots for a search for “Ad-Aware”, another well-known anti-spyware program. The top ad promotes C-Net’s adwarealert.com — a name particularly likely to confuse users because the ad’s title and domain differ from the user’s request by just a single letter. The first ad takes the user to adwarealert immediately, while the second ad takes users to a www-ad-ware.com landing page which also promotes adwarealert.com (again via ClickBank).

Other deceptive C-NetMedia partners pervade search results for spyware-removal search terms. See e.g. “Spybot-free.com” using distinctive “Spybot” “Search & Destroy” marks to promote C-Net’s spywarebot.com. See also C-Net’s Registrysmart.com advertising with ad title “Microsoft Antispyware” in Google results for searches on “Microsoft Spyware”. Because the Registrysmart ad title touts “Microsoft Antispyware”, users might reasonably think the ad will yield an official Microsoft site that actually provides the free “Microsoft Antispyware” product. But in fact the link leads only to a C-Net site with paid products.

C-NetMedia may claim that these ads were placed by affiliates. But the actions of these affiliates are prominent — occurring on search terms as well-known as “Spybot” and “Ad-Aware.” These actions are also longstanding: My October 2006 False and Deceptive Pay-Per-Click Ads shows that some of these ads have continued for more than a year. Furthermore, these affiliates act for C-Net’s benefit, and C-Net has the right and ability to monitor them, to oversee their activities, and to limit their efforts as it sees fit. Finally, FTC litigation confirms that companies can be liable for the actions of their affiliates and marketing partners. See e.g. US v. APC Entertainment (advertiser liable for sexually-explicit unsolicited commercial email sent by its affiliates), In the Matter of Zango, Inc. (advertising software company liable for nonconsensual and deceptive installations of its software by its partners), In the Matter of Direct Revenue LLC (same).

C-NetMedia’s involvement in these advertising practices is heightened by C-Net’s own selection of product names. C-Net, not its affiliates, chose product names so close to established market leaders — names that invite consumer confusion. C-Net furthers the confusion by calling its products “official” (e.g. “The Official Ad-Ware Client“, emphasis added) when there is no meaningful sense in which C-Net’s products are more “official” than any other. Indeed, when users arrive at C-Net sites after requesting similarly-named better-known competitors, C-Net’s offerings are exactly not the official products users specifically requested by name.

Some C-Net sites are also deceptive in that their titles and graphic design falsely suggest they are an official part of Windows. Consider antispyware.com. The site’s heading presents the generic title “AntiSpyware For Windows” — without mentioning any company name or showing any other prominent indication that the product is not actually part of Windows. Furthermore, antispyware.com shares numerous graphic design elements with official Microsoft sites: Like official Microsoft sites, antispyware.com features a broad blue bar across the top of the page, bold white type at top-left with smaller white type at top-right, a grey navigation bar down the left edge (with thin black lines as section separators, and with simple black text), a grey nav bar down the right edge (with broad grey bars to separate sections, and with blue bulleted text), a grey background, a skewed 3D rendering of a product screen at page center, and a vivid colored bubble at top-center, linking to a product download. See the two screenshots below — antispyware.com on the left, and the official Microsoft Windows Defender download page on the right. These many visual similarities make it especially likely that a user at antispyware.com will mistakenly believe the site is an official Microsoft offering.


C-NetMedia’s Antispyware.com		Microsoft Windows Defender

Some C-NetMedia sites give users the false impression that they are bona fide informational sites rather than commercial advertisements. For example, Remover.org presents itself as a general-purpose spyware information site, but Remover.org actually promotes only one product — C-Net’s “AntiSpyware For Windows.” Furthermore, Remover.org claims to have “one goal and one purpose: to win the war on spyware” — suggesting a non-commercial purpose, when in fact Remover charges a fee for its removal program. The totality of these practices suggests that a user at Remover.org may reasonably think he is viewing an ordinary informational site and/or a source of unbiased reviews, when in fact the site is a C-Net advertisement.

Hindering Consumer Investigations through Use of Numerous Product Names and Domains

C-Net uses exceptionally many product names and domain names. My analysis indicates that the following products and domains all come from C-NetMedia:

Site	Whois	IP Address	Trademark
adware.pro	Whois-Proxy	72.32.100.197
ad-warealert.com	Domains By Proxy (GoDaddy)	72.32.242.170 – C-Netmedia	77047467 – November 20, 2006 – C-Netmedia
adwarealert.com	Domains By Proxy (GoDaddy)	72.32.29.230	77047467 – November 20, 2006 – C-Netmedia
adwarearrest.com	Syber Corporation 8400 East Prencitce Avenue, Ste 1500 Greenwood Village CO 80111	72.32.134.197
adwarebot.com	Domains By Proxy (GoDaddy)	72.32.242.171 – C-Netmedia
antispyware.com	Domains By Proxy (GoDaddy)	72.32.26.195	77073855 – December 30, 2006 – C-Netmedia
antispywarebot.com	Domains By Proxy (GoDaddy)	72.32.48.186	77047469 – November 20, 2006 – C-Netmedia
errorkiller.com	C&C Networks 3630 County Ct S Mobile, AL 36619	72.32.242.171 – C-Netmedia	77047443 – November 20, 2006 – C-Netmedia
errorsmart.com	Domains By Proxy (GoDaddy)	73.32.26.195
errorsweeper.com	Domains By Proxy (GoDaddy)	73.32.48.186	77047440 – November 19, 2006 – C-Netmedia
evidenceeraser.com	Domains By Proxy (GoDaddy)	73.32.29.230	77073969 – December 31, 2006 – C-Netmedia
free-pc-repair.com	Ofer Shoshani 747 Durshire Way Sunnyvale, CA 94087	72.32.100.197
free-registrysmart.com	Domains By Proxy (GoDaddy)	72.32.242.171 – C-Netmedia	77047441 – November 20, 2006 – C-Netmedia
macrovirus.com	Domains By Proxy (GoDaddy)	72.32.242.171 – C-Netmedia
malwarebot.com	Domains By Proxy (GoDaddy)	72.32.242.169 – C-Netmedia	77047470 – November 20, 2006 – C-Netmedia
privacycontrol.com	Domains By Proxy (GoDaddy)	73.32.48.186	77073857 – December 31, 2006 – C-Netmedia
privacycontrols.com	Domains By Proxy (GoDaddy)	73.32.48.186	77073859 – December 31, 2006 – C-Netmedia
regclean.com	Domains By Proxy (GoDaddy)	73.32.48.186
regrecall.com	Domains By Proxy (GoDaddy)	73.32.90.213
registrybot.com	Domains By Proxy (GoDaddy)	72.32.242.169 – C-Netmedia	77047445 – November 20, 2006 – C-Netmedia
registryclear.com	Bruce Cope 3630 County Ct S Mobile, AL 36619	72.32.134.197
registrysmart.com	PrivacyPost (Dotster)	73.32.29.230	77047441 – November 20, 2006 – C-Netmedia
regsweep.com	Domains By Proxy (GoDaddy)	73.32.26.195	77047438 – November 19, 2006 – C-Netmedia
remover.org	Domains By Proxy (GoDaddy)	72.32.26.195
restore-pc.com	Domains By Proxy (GoDaddy)	73.32.29.230
spywarebot.com	Domains By Proxy (GoDaddy)	73.32.134.197
spywareremover.com	C&C Networks 3630 County Ct S Mobile, AL 36619	64.49.219.215

The United States Patent and Trademark Office’s Trademark Search provides the brunt of my evidence that the listed sites are associated with C-Netmedia. Other evidence comes from the 73.32.242.168-175 network block that C-Net uses at Rackspace. (Rackspace also hosts all of the other listed C-Net sites. The 64.49.219.215 server is indeed a Rackspace server, despite its distant IP address.) My conclusion is bolstered by the many other similarities among these sites, including their common substantive theme, structure, layout, registration method, and advertising relationships and suppliers. Furthermore, the sites’ programs are largely similar — with identical detections, false-positives, and user interfaces.

An ordinary user would face substantial difficulty in determining that a given site is operated by C-NetMedia or in finding C-Net’s contact information. At a few of the sites, a user would at least find a street address in Whois. But the other domains all lack useful Whois data. Furthermore, while the listed web sites offer email and/or chat support, they all lack a phone number, mailing address, or even a legal name or place of incorporation. A user seeking to send a formal complaint therefore has no clear means to do so. Savvy users might notice a reference to C-NetMedia within a program’s license agreement. But these references appear only in the licenses shown by programs’ installers — not in the license agreements linked from the corresponding web sites. So these references to C-Net are especially hard to find after a user has already received C-Net software.

A user who manages to identify the C-Net company name, e.g. from trademark applications, is still substantially stymied in learning more about the company. The name “C-NetMedia” immediately suggests an association with CNET Networks, Inc., the well-known news site at www.cnet.com. In fact C-NetMedia and CNET Networks are entirely unrelated. But by choosing a name that matches an existing company, C-Net hinders attempts to learn more about its practices: Searches for “C-Net” overwhelmingly yield references to CNET Networks.

C-Net’s use of many names brings valuable benefits to C-Net but real costs to users: The numerous names prevent users’ unfavorable views of specific C-Net products (examples: 1, 2, 3, 4, 5) from easily spreading to other C-Net products. If C-Net had only a single product, users searching for that product would easily find the complaints of prior dissatisfied users. But by shifting from name to name, C-Net can abandon product names with unfavorable coverage, in each instance starting fresh with a new name. In this regard, C-Net’s approach is strikingly similar to Direct Revenue’s use of dozens of company and product names.

It seems C-Net sometimes uses the name 2squared to describe its offerings. The 2squared.com site claims to be the maker of at least some of C-Net’s products (including ErrorSweeper and RegClean). While C-Net’s trademark applications list one address in Mobile, Alabama (590 B Schillinger Road South, Suite 8), 2squared provides the adjacent suite 10.

C-Net’s trademark applications all list Erik Mv. Pelton as their attorney of record. Mr. Pelton’s tm4smallbiz.com site indicates that he is a bona fide trademark attorney with an office in Arlington, Virginia.

High-Pressure Sales Tactics and False Positives

C-NetMedia SpywareBot False Positives

Once a user installs C-NetMedia’s free trial software, C-Net resorts to high-pressure tactics to encourage users to make a purchase.

I tested C-Net’s SpywareBot on a clean PC running Windows XP with no service packs,. My test PC was supplemented only by the ordinary analysis tools I use to study spyware and adware infections. SpywareBot detected Regsnap, my registry change-tracking tool, as the “Absolute Keylogger.” Bold red “Warning” messages repeatedly alerted me to the supposed “43 parasites” on my computer, and a “toast”-style slider arose from the bottom-right corner of my screen. Perhaps this was just an ordinary false positive — a mistake that any security program can make. But C-Net’s error was unusually self-serving in that C-Net requires users to pay a fee — in this case $19.95 — before removing any of the items it detects.

C-Net’s many products mean extended further investigation would be required to fully determine the effectiveness and error rates of C-Net’s various programs. Due to the seriousness of the advertising practices described above, I have chosen to post this article without fully testing for such false positives or other deficiencies across all of C-Net’s programs and across a variety of test computers. I will update this article to link to any such research performed by others.

Other Anomalous Marketing Practices: Affiliate Programs, Certifications, and Logos

C-NetMedia’s marketing programs are striking in their generosity: C-Net offers its affiliates 70% commissions on users’ purchases. Such large commissions tend to suggest that charges to users bear little relationship to the underlying cost of providing the service. In particular, when a user arrives at C-Net’s site through an affiliate link, at least 70% of the user’s payment goes towards marketing costs. But if marketing receives 70% of revenue, relatively little remains to fund product design or other core business functions. A user might be better off with a free product — such as the free products with names nearly identical to the names C-Net selected.

C-NetMedia sites systematically and prominently tout certifications that are substantially irrelevant to the true attributes of C-Net software. For example, C-Net’s Adwarealert site boasts a McAfee HackerSafe logo. When this logo appears on a site offering security software, a user might reasonably think the logo means the site’s software will keep the user safe from hackers. But in fact HackerSafe signifies nothing of the kind: HackerSafe has merely checked the Adwarealert web server for a set of known security problems. C-Net’s use of the HackerSafe certification thus has the tendency to deceive, i.e. to leave users with an untrue impression of the certification’s significance.

Update (February 14, 11:30am): I notice that McAfee has withdrawn HackerSafe certification of C-NetMedia sites. C-NetMedia sites now show blank space where the logo previously appeared.

Adwarealert also features a Microsoft “Certified for Windows Vista” seal. Microsoft’s certification list confirms that Adwarealert did receive this certification. But it seems Adwarealert does not truly qualify for this certification because Adwarealert violates rule 1.11 of the Microsoft certification requirements, namely the requirement that a certified program comply with all applicable guidelines from the Anti-Spyware Coalition. The ASC’s Risk Model negatively characterizes incomplete or inaccurate identifying information; obfuscation; and misleading, confusing deceptive or coercive messaging or false claims to induce users to take action. By failing to readily provide accurate contact information, by using misleading product names, and by reporting false positives with a request for payment, Adwarealert violates each of these requirements. I therefore conclude that Adwarealert is ineligible for the “Certified for Windows Vista” certification.

C-NetMedia’s sites also feature unsubstantiated claims of product benefits. C-Net sites feature the following logos: “Guaranteed – 100% No Adware or Spyware”, “#1 Most Advanced Privacy Software”, “#1 Registry Cleaner”, “100% Safe and Secure”, “Total Privacy Protection,” “Most Advanced Anti-Spyware Detection,” and “World’s #1 Spyware Remover.” None of these claims contains, references, or links to any substantiation, documentation, or other supporting details. Some of these claims are presented in graphical form, i.e. in logos that appear to be endorsements or certifications. But C-Net gives no indication of any bona fide third party offering these endorsements; instead, the graphics seem to be C-Net’s own creation.

Work To Be Done

My analysis shows ample room for online advertising and security vendors to better protect users from C-NetMedia’s deceptive advertising practices:

Google and other search engines could block the widespread deceptive ads from C-NetMedia and its marketing partners. C-Net and its partners have continued these practices for more than a year. Google claims to be tough on malware, and Google does exclude some harmful organic search results. But Google has been ineffective in removing the false and deceptive ads shown above, among many others, despite ample complaints from users and security researchers.
McAfee could remove its Hacker Safe certification from C-NetMedia sites. At present, the McAfee logo gives users the false impression that McAfee endorses C-Net and the McAfee vouches for the effectiveness of C-Net’s software. I gather neither is truly the case. Indeed, McAfee’s HackerSafe certifies some C-Net sites at the same time that McAfee’s SiteAdvisor characterizes rates those same sites as red. In my view, the SiteAdvisor rating better describes the view of security experts and better serves typical users. (Disclosure: I serve as a member of the Board of Advisors of McAfee SiteAdvisor.) (Update, February 14, 11:30am: McAfee has withdrawn HackerSafe certification of C-NetMedia sites.)
Microsoft could withdraw its Certified for Windows Vista certification on the basis of C-NetMedia’s violations of various ASC rules, as cited above. Anticipating this kind of harmful marketing practices, Microsoft’s certification rules provide ample basis for excluding C-Net on the basis of its deceptive advertising. Microsoft’s concern should be particularly acute because C-Net copied the layout and format of the Microsoft Antispyware site, because C-Net marketing partners trade on Microsoft’s brand name and product names, and because C-Net products worsen the experience of Windows users (i.e. by charging a fee for security software, when Microsoft provides similar software for free).
ClickBank could eject C-NetMedia from ClickBank’s affiliate network due to the pattern and practice of false and misleading ads placed by ClickBank affiliates in their promotion of C-Net offers. ClickBank’s Client Contract specifically prohibits fraudulent, deceptive, false or misleading information in advertising messages (clause 7.n.), and Clickbank reserves the right to immediately suspend violators (9.d.). But at present, C-NetMedia seems to remain a ClickBank clent in good standing.

Thanks to security researcher Janie Whitty for references on C-NetMedia’s trademark registrations.

January 4, 2008December 2, 2023

Sears Exposes Customer Purchase History in Violation of Its Privacy Policy

Want to know what a given customer has purchased from Sears? It’s surprisingly easy to find out. Here’s the procedure:

1) Go to the Sears “Manage My Home” site, www.managemyhome.com . Create an account and sign in. Screenshot.

2) On the Home menu, choose Home Profile. In the Search Purchase History section, choose Find Your Products. Screenshot.

3) Enter the name, phone number, and street address of the customer whose purchases you wish to view. Press Find Products. Screenshot.

Sears then displays all purchases its database associates with the specific customer — typically major appliances and other large purchases. See examples from Washington, DC, Brookline, Massachusetts, and Lincoln, Massachusetts.


The information required to retrieve a customer’s purchase history		A customer’s purchase history – showing specific items and purchase dates

Sears Fails to Protect Customer Information

Sears offers no security whatsoever to prevent a ManageMyHome user from retrieving another person’s purchase history by entering that person’s name, phone number, and address.

To verify a user’s identity, Sears could require information known only to the customer who actually made the prior purchase. For example, Sears could require a code printed on the customer’s receipt, a loyalty card number, the date of purchase, or a portion of the user’s credit card number. But Sears does nothing of the kind. Instead, Sears only requests name, phone number, and address — all information available in any White Pages phone book.

Neither does Sears even include any special instructions or obligations in its signup agreement with users: The ManageMyHome Terms of Use say nothing about what information users may access. Indeed, while Sears includes a small-type link to its Terms of Use, Sears never asks users to affirmatively accept the Terms.

These Disclosures Are Contrary to Sears’s Explicit Promises

Sears violates its privacy policy when it discloses users’ purchases to the general public. The Sears Customer Information Privacy Policy lists specific circumstances in which Sears may share customer information. These circumstances are relatively broad — allowing Sears to share customer data “with members of the Sears family of businesses … to provide … promotional offers that we believe will be of interest.” Disclosures are also permitted “to provide [users] with products or services that [they] have requested,” to “trusted service providers that need access to your information to provide operational or other support services,” to credit bureaus, and to regulatory authorities and law enforcement. But none of these provisions grants Sears the right to share users’ purchases with the general public.

Sears may argue that its web site privacy policy only applies to users’ online purchases, and does not govern purchases made in retail stores. Perhaps. But I doubt in-store customers expect their friends, neighbors, and the general public to be able to find out what they bought. I’m still trying to determine what privacy (if any) Sears promises its in-store customers.

Sears’s Privacy Breach in Context

Sears’s exposure of customer purchase history fits within a long history of unintended web site disclosures. For example, in October 2000 I showed that Buy.com’s return system was revealing customer names, addresses, and phone numbers at publicly-available URLs. But Sears’s disclosure is more troubling: Sears discloses the specific products users purchased. Sears’s disclosures apply to all users, not just those who return products. And Sears’s disclosures come some 7+ years after Buy.com’s breach — a period of great advance in online security.

The combination of data Sears provides could open the door to serious harms to Sears customers. ManageMyHome reports the specific products customers purchased, as well as the dates of each such purchase. With this information, a miscreant could approach a customer and pretend to be a Sears representative. Consider: “Your washing machine was recalled, and I need to install a new motor.” Or, “I’m here to provide the free one-year check-up on your dishwasher.”

Assessing Sears’s IT Strategy

The ManageMyHome site offers some useful services: Consolidated information about dates of purchase, clear listing of warranty status, and easy links to product manuals. Sears touted these benefits in its recent coverage of ManageMyHome.

But as soon as Sears resolved to provide online access to customers’ purchase histories, Sears staff should have recognized the need to determine which users are truly authorized to see this information. Sears’s failure to effecitvely authenticate users is therefore puzzling. Did Sears staff fail to notice the problem? Decide to ignore it when they couldn’t devise an easy solution to protect users’ purchase histories? Resolve to argue that purchase history merits no better protection than the current system provides?

Combining this privacy breach with Sears’s poorly-disclosed installation of ComScore tracking software, it appears that Sears is not effectively protecting its users’ and customers’ privacy. Perhaps that’s no surprise in light of Sears’s recent financial distress — a 99% drop in profits in third quarter 2007, compared with the third quarter of 2006. But users need not accept excuses for Sears’s lackadaisical treatment of their private information. No matter the company’s financial standing, Sears ought to comply with its stated privacy policy and treat user information with the care users rightly expect.

Sears’s Response

I wrote to Sears ManageMyHome via the addresses on their Contact Us page. To their credit, they responded quickly (less than ninety minutes). However, their reply does not address the seriousness of this situation. Their reply follows:

“We appreciate that you have a security concern. Thank you for taking the time to share your comments with us. We appreciate hearing feedback from our customers, and will pass this information to the appropriate area to research.”

Update (January 4, 5pm): Sears has disabled the search feature described above. Attempts to retrieve a purchase history now yield the message “We’re sorry, this feature is currently disabled.”

Thanks to an anonymous contributor, using pseudonym Heather H, for the tip that led to this article.

January 1, 2008December 2, 2023

The Sears "Community" Installation of ComScore

Late last month, Benjamin Googins (a senior researcher in the Anti-Spyware unit at Computer Associates) critiqued a ComScore installation performed by Sears’ “Sears Holdings Community” (“My SHC Community” or “SHC”). After reviewing the installation sequence, Ben concluded that the installation offered “very little mention of software or tracking” and otherwise fell short of CA and industry standards. I agree.

I write today to add my own critique. I begin by presenting the entire installation sequence in screenshots and video. I then explain why the limited notice provided falls far short of the standards the FTC has established. Finally, I show that Sears’ claims of adequate notice are demonstrably false.

The SHC Installation Sequence

The SHC installation proceeds in four steps:

1) An email from Sears after a user provides an address at Sears.com. In seven paragraphs plus a set of bullet points, 582 words in total, the email describes the SHC service in general terms. But the paragraphs’ topic sentences make no mention of any downloadable software, nor do the bullet points offer even a general description of what the software does. The only disclosure of the software’s effects comes midway through the fourth paragraph, where the program is described as “research software [that] will confidentially track your online browsing.” Sophisticated users who notice this text will probably abandon installation and proceed no further. But novices may mistakenly think the tracking is specific to Sears sites: SHC is a research program offered by Sears, so it is difficult to understand why tracking would occur elsewhere. Furthermore, the quoted text appears midway through a paragraph — in no way brought to users’ attention via topic sentences, headings, section formatting, or other labels. So it’s strikingly easy to miss.

2) If a user presses the “Join” button in the email, the user is taken to a SHC web-based installation sequence that further details SHC’s offerings. The first page describes some aspects of SHC in reasonable detail — with six prominent and clear bullet points. Yet nowhere does this text make any mention whatsoever of downloadable software, market research, or other tracking.

3) Pressing “Join” in the SHC screen takes a user to a “Welcome to My SHC Community” page which requests the user’s name, address, and household size. The page then presents a document labeled “Privacy Statement and User License Agreement” — 2,971 words of text, shown in a small scroll box with just ten lines visible, requiring fully 54 on-screen pages to view in full. The initial screen of text is consistent with the “privacy statement” heading: The visible text indicates that the document describes “what information [SHC] gather[s and] how [SHC] use[s] it” — typical subjects for a privacy policy. But despite the title and the first screen of text, the document actually proceeds to an entirely different subject, namely downloadable software and its far-reaching effects: The tenth page admits that the application “monitors all of the Internet behavior that occurs on the computer on which you install the application, including … filling a shopping basket, completing an application form, or checking your … personal financial or health information.” That’s remarkably comprehensive tracking — but mentioned in a disclosure few users are likely to find, since few users will read through to page 10 of the license.

Within the Privacy Statement section, a link labeled “Printable version” offers users a full-screen version of the document, requiring “only” ten on-screen pages on my test PC. But nothing in the Privacy Statement caption or visible text suggests that the document merits such thorough review. Due to the labeling and the first screen of text, few users will see any need to click through to the full-screen version.

4) A user next arrives at a screen labeled “You’re almost finished!” Clicking “Next” triggers an ActiveX screen offering an unnamed program, signed by a company called TMRG, Inc. (nowhere previously mentioned in the installation sequence), authenticated by Thawte (part of VeriSign). Pressing Yes in the ActiveX yields an installation program with no further opportunity to cancel installation. Packet sniffer analysis confirms that ComScore software is installed.

See also a video of the installation sequence.

Relevant FTC Rules

The FTC’s recent settlements with Direct Revenue and Zango explain the disclosure and consent required before installing tracking software on users’ computers. To install such software on users’ PCs, vendors must obtain “express consent” — defined to require “clear[] and prominent[] disclos[ure of] the material terms of such software … including the nature and purpose of the program and the effects it will have … prior to the display of, and separate from, any final End User License Agreement.” “Clear[] and prominent[]” installations are defined to be those that are “unavoidable”, among other requirements.

The Sears SHC installation of ComScore falls far short of these rules. The limited SHC disclosure provided by email lacks the required specificity as to the nature, purpose, and effects of the ComScore software. Nor is that disclosure “unavoidable,” in that the key text appears midway through a paragraph, without a heading or even a topic sentence to alert users to the important (albeit vague) information that follows.

The disclosure provided within the Privacy Statement and User License Agreement also cannot satisfy the FTC’s requirements. The FTC demands a disclosure “prior to … and separate from” any license agreement, whereas the only disclosure on this page occurs within the license agreement — exactly contrary to FTC instructions. Furthermore, users can easiliy overlook text on page ten of a lengthy license agreement. Such text is the opposite of “unavoidable.”

The SHC/ComScore violation could hardly be simpler. The FTC requires that software makers and distributors provide clear, prominent, unavoidable notice of the key terms. SHC’s installation of ComScore did nothing of the kind.

Other Installation Deficiencies

Beyond the problems set out above, the SHC installation also falls short in other important respects.

Failure to provide the promised additional information. Sears’ initial email promises that “during the registration process, you’ll learn more about this application software.” In fact, no such information is provided in the visible, on-screen installation sequence. Based on this false promise and users’ general experience, users may reasonably expect that the download link in step 4 will offer additional information about the software at issue, along with an opportunity to cancel installation if desired. In fact no such information is ever provided, nor do users have any such opportunity to cancel.

Choosing little-known product names that prevent users from learning more. The initial SHC email refers to the ComScore software as “VoiceFive.” The license agreement refers to the ComScore software as “our application” and “this application” without ever providing the application’s name. The ActiveX prompt gives no product name, and it reports company name “TMRG, Inc.” These conflicting names prevent users from figuring out what software they are asked to accept. Furthermore, none of these names gives users any easy way to determine what the software is or what it does. In contrast, if SHC used the company name “ComScore” or the product name “RelevantKnowledge,” users could run a search at any search engine. These confusing name-changes fit the trend among spyware vendors: Consider Direct Revenue’s dozens of names (AmazingMerchants, BestDeals, Coolshopping, IPInsight, Blackone Data, Tps108, VX2, etc.).

Critiquing Sears SHC’s Response

To my surprise, Sears defends the practices described above. In a reply to CA’s Ben Googins, Sears SHC VP Rob Harles claims that SHC “goes to great lengths to describe the tracking aspect.” In particular, Harles says “[c]lear notice appears in the invitation”, “on the first signup page”, and “in the privacy policy and user licensing agreement.”

I emphatically disagree. The email invitation provides vague notice midway through a lengthy paragraph that, according to its topic sentence, is otherwise about another topic. The first signup page makes no mention at all of any downloadable software. The privacy policy and license agreement describe the software only in the tenth page of text (where few users are likely to find the disclosures), and even then it fails to reference the program by name.

Harles further claims that the installer provides “a progress bar that they [users] can abort.” Again, I disagree. The video and screenshots are unambiguous: The SHC installer shows no progress bar and offers no abort button.

The Installation in Context

In June 2007, I showed other examples of ComScore software installing without consent — including multiple installations through security exploits. TRUSTe responded by removing ComScore’s RelevantKnowledge from TRUSTe’s Trusted Download Program for three months. Now that more than five months have elapsed, I expect that ComScore is seeking readmission. But the installation shown above stands in stark contrast to TRUSTe Trusted Download rules. See especially the requirement that primary notice be “clear, prominent and unavoidable” (Schedule A, sections 3.(a).(iii) and 1.(hh)).

Why so many problems for ComScore? The basic challenge is that users don’t want ComScore software. ComScore offers users nothing sufficiently valuable to compensate them for the serious privacy invasion ComScore’s software entails. There’s no good reason why users should share such detailed information about their browsing, purchasing, and other online activities. So time and time again, ComScore and its partners resort to trickery (or worse) to get their software onto users’ PCs.

August 28, 2007March 1, 2018

A Closer Look at Coupons.com updated September 24, 2007

I recently examined software from Coupons.com. At first glance their approach seems quite handy. Who could oppose free coupons? But a deeper look reveals troubling behaviors I can’t endorse. This piece summarizes my key concerns:

Installing with deceptive filenames and registry entries that hinder users’ efforts to fully remove Coupons’ software. Details.
Failing to remove all Coupons.com components upon a user’s specific request. Details.
Assigning each user an ID number, and placing this ID onto each printed coupon, without any meaningful disclosure. Details.
Allowing third-party web sites to retrieve users’ ID numbers, in violation of Coupons.com’s privacy policy. Details.
Allowing any person to check whether a given user has printed a given coupon, in violation of Coupons.com’s privacy policy. Details.

The Coupons.com business

Coupons.com offers users coupons which they can print at home, then redeem at retailers.

Coupons.com specifically promises users that they may "use as many [coupons] as [they] like." But in fact, Coupons.com takes great pains to limit how many coupons users can print. Rather than simply letting users print GIF or JPG coupons from an ordinary web page, Coupons.com requires that users install a coupon-printing ActiveX control. Coupons.com also customizes each coupon with information about who printed it and when. These design decisions increase the complexity of Coupons.com’s business — giving rise to the serious consent and privacy issues set out below.

Installing with deceptive filenames and registry entries

On an ordinary test PC that had never previously run any software from Coupons.com, I installed Coupons.com’s Coupon Bar 5.0 software. I requested a coupon to be printed, then ran an "InCtrl" comparison of changes made to my computer. InCtrl revealed the following new files and registry entries:

c:\windows\uccspecc.sys
c:\windows\WindowsShellOld.Manifest.1
HKEY_LOCAL_MACHINE\SOFTWARE\ClassesManifest.Template.1
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\uccspecc
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Controls Folder\Presentation Style
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\EnableAutoTrayHistory
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\URLDecoding

Each of these entries consisted of a 30 to 90-letter string of gibberish. For example, the contents of uccspecc.sys exactly matched the contents of the first three registry entries: HtmWSrewvuaCGtKrVlXxMKdbMkLfgHq.

Others have also noticed these oddly-named files. For example, McAfee SiteAdvisor reports every file and registry entry Coupons.com creates.

These Coupons.com filenames and registry keys are deceptive, for at least three different reasons.

1) The labels falsely suggest that the components are part of Windows, rather than third-party add-ins. For example, the files and registry keys are placed in locations reserved for Windows itself, not for third-party applications. Furthermore, Coupons.com’s choice of filename and registry keys affirmatively misrepresents the function of the specified components.

2)The labels falsely suggest that the components are system files. For example, the .SYS file extension has a special meaning to Windows (e.g. for device drivers and other system components), but the Coupons.com file serves no such "system" function. Registry keys as to (supposed) Explorer AutoTray, URL encoding, and folder presentation settings all suggest intuitive meanings. But Coupons.com goes on to use these keys for a purpose unrelated to their names.

3) The labels are confusingly similar to genuine Windows components. For example, WindowsShell.Manifest is a bona fide Windows file, but Coupons.com’s "WindowsShellOld.manifest.1" (emphasis added) has no relationship whatsoever with that file (and is certainly not an "old" version of that file). Similarly, the HKLM\Software\Microsoft\Windows\CurrentVersion\Internet Settings\URLEncoding registry key is required by Internet Explorer, making Coupons’ choice of the similar URLDecoding (emphasis added) especially likely to confuse typical users.

Coupons.com’s choice of registry keys and filenames has a clear purpose and effect: To deter users from deleting the specified keys and files. Even among users sophisticated enough to manually delete unwanted files and registry keys, the chosen registry keys and filenames look so official that removal appears unwise. The typical result is that users will elect to retain these files, mistakenly concluding that these files are part of Windows.

Coupons.com’s deceptive filenames flout industry norms. For example, the Anti-Spyware Coalition’s Best Practices invite anti-spyware vendors to consider whether a program’s “files have easy-to-understand names and are easy for users to find on their computers” — a test Coupons.com clearly fails. Anti-spyware statutes in Texas and Arkansas specifically prohibit deceptively-named files and registry entries that prevent users from removing software, and TRUSTe Trusted Download rules (which bind Coupons.com as a Trusted Download sealholder) also prohibit deceptive naming to avoid removal. These Texas, Arkansas, and TRUSTe requirements admittedly limit their prohibitions to deceptively-named "software" and to deception that hinders program removal. Perhaps Coupons.com manages to escape these rules by deceptively naming its configuration files (rather than its executable code) or by making its executable code (though not its configuration files) easy to remove. Nonetheless, these authorities reveal the public’s discomfort with deceptive naming. If users are to know what is on their computers and why, vendors must name their files in a way reasonable users can understand. Yet Coupons.com intentionally does exactly the opposite..

Failing to remove all Coupons.com components when users request uninstall

On my test PC, I attempted to uninstall the Coupons.com software in the usual way: Control Panel – Add/Remove Programs – Coupon Printer. The uninstaller claimed to have run successfully. Yet my computer retained the two files and five registry entries set out in the prior section. These files and registry entries remained even after I restarted my test PC.

I had requested an "uninstall" of Coupons.com software — not a partial uninstall, but (for lack of any instruction or indication to the contrary) a complete uninstall. The Coupons.com uninstaller had even paused to ask about a specific "shared system file" it wanted special confirmation to delete — further suggesting a thorough removal procedure. The uninstaller ultimately reported that the uninstall was "successful." Nonetheless, the specified components were left on my computer after uninstall.

Coupons.com’s privacy policy fails to disclose that these files and registry keys — embodiments of a user’s ID number, as explained in subsequent sections — are left behind even after uninstall. The privacy policy discusses cookies (a more common way to store user information) in a full paragraph, including three sentences about "persistent cookies" and how users can remove them. The privacy policy therefore seems to cover all user information that Coupons.com stores on users’ PCs. Yet the privacy policy is entirely silent as to the files and registry entries set out above, and as to their retention even after a user attempts to remove Coupons.com software. Neither does Coupons.com’s software license agreement mention these hidden files — neither their existence nor their retention.

The TRUSTe Trusted Download certification agreement requires "an easy and intuitive means of uninstallation" (provision 7). TRUSTe instructs that uninstallation "must remove the Certified Software from the User’s computer." TRUSTe does not specifically speak to the possibility of a program leaving data files behind after uninstall. But where TRUSTe offers an exception to the requirement of complete removal, that exception is tightly limited to serving a user’s direct and immediate interest. (Namely, TRUSTe allows a program to leave behind a shared component that other programs also rely on, since removing that component would disable the other programs.) Furthermore, TRUSTe’s requirement summary demands that "[u]ninstallation must remove all software associated with the particular application" (emphasis added) — broad language suggesting little tolerance for files intentionally left behind. Since TRUSTe offers only a single exception to the requirement of complete removal, and since that exception is so narrow, I believe TRUSTe will likely take a dim view of certified software intentionally failing to uninstall any of its components.

Printing users’ ID numbers onto coupons

Coupons.com Prints a User’s ID Number on Each Coupon

Every coupon printed from Coupons.com bears a series of small numbers. These numbers include the user ID of the user who printed the coupon. See an example coupon printed from my computer, repeatedly reporting my user ID: 35415364.

Coupons.com’s privacy policy does not prominently warn users that Coupons.com will include their user IDs on each printed coupon. As best I can tell, after multiple careful readings of the privacy policy, the only relevant provision is as follows:

Coupons, Inc. discloses "automatically collected" data (such as coupon print and redeem activity) to its Clients and third-party ad servers and advertisers. These third parties may match this data with information that they have previously collected about you under their own privacy policies, which you should consult on a regular basis.

I believe Coupons.com considers user ID numbers to be "automatically collected data," and Coupons.com seems to use the word "Clients" to include product manufacturers as well as retail merchants. On such an interpretation, the quoted language might let Coupons.com print user ID numbers on coupons that are given to retailers and ultimately to merchants. But even if consumers read the quoted language, most consumers will be unable to figure out what it means because the wording is so convoluted and vague.

In lieu of the quoted wording, Coupons.com could simply explain: "We include your user ID on each coupon you print." Such a warning would be clear, concise, and easy to understand. But such a warning would also raise privacy concerns for typical users — perhaps one reason why Coupons.com might prefer more complicated wording.

Allowing third-party web sites to retrieve user ID numbers, in violation of Coupons.com’s privacy policy

Coupons.com Allows Third-Party Sites to Retrieve User ID Numbers

Examining JavaScript code on Coupons.com’s web site, I noticed an apparent design flaw. Testing confirmed my suspicion: Any web page can invoke the "GetDeviceID" method of Coupons.com’s coupon-printing software. The web page then receives the user ID associated with the user’s installation of Coupons.com software.

To confirm this data leakage, see my Coupons.com Software Shares User IDs with Arbitrary Third Parties testing page. If a computer runs current Coupons.com software, this page will display the associated Coupons.com user ID. (However, no information is sent to my web server or otherwise stored or preserved.) This is the exact same ID number that is printed onto users’ coupons. (Screenshot.)

Although Coupons.com user ID numbers appear to be assigned arbitrarily, distribution of these ID numbers raises at least three privacy concerns:

1) This distribution is not permitted under Coupons.com’s privacy policy. Coupons.com’s privacy policy specifically limits the circumstances in which Coupons.com will share user information, and this is not among the circumstances users accept. In particular, Coupons.com says it will disclose certain information to "clients and third-party ad servers and advertisers." But in fact, Coupons.com’s program code makes user IDs available to anyone — even to sites with absolutely no relationship to Coupons.com.

2) Coupons.com user IDs are widespread. As explained in the prior section, a user’s ID is printed onto each coupon the user prints. Broad distribution of user IDs increases the unpredictable consequences of further sharing of ID numbers. For example, a merchant’s web site could cross-check users’ computers against coupons — conceivably even connecting users’ computers back to users’ retail purchase histories. Retailers could similarly use Coupons.com ID numbers to connect a user’s online activity to the user’s in-store shopping habits.

3) Coupons.com user IDs are persistent. Unless a user carefully removes the filenames and registry entries set out in the preceding section, uninstalling and reinstalling Coupons.com software will retain the same user ID. A Coupons.com user ID is therefore highly likely to continue to identify the same user over time. In contrast, other identifiers tend to change over time. For example, many ISPs reassign user IP addresses often. Some users their cookies in an attempt to increase their online privacy. Because Coupons.com user IDs are unusually hard to remove, Coupons.com user IDs are a particularly effective way for sites to track users over an extended period.

This violation of Coupons.com’s privacy policy occurred despite Coupons.com’s membership in the TRUSTe Web Privacy Seal Program, the TRUSTe Trusted Download Program, and the BBBOnLine Reliability Program. Knowing that Coupons.com software assigns each user an ID number and that Coupons.com accesses these ID numbers through its web site, the prospect of leakage to other web sites (in specific violation of Coupons.com’s privacy policy) was obvious and intuitive. Yet it seems TRUSTe and BBBOnLine failed to check for this possibility. This failure is particularly disappointing since TRUSTe’s Trusted Download program claims to specialize in software testing.

Allowing any person to check whether a given user has printed a given coupon

Coupons.com Confirms that a Given User Has Printed a Given Coupon

Coupons.com Reports that a User Has Not Printed a Given Coupon

Coupons.com’s Veri-fi service, veri-fi.com, lets any interested person determine whether the coupon is (in Coupons.com’s view) "counterfeit [or] fraudulently-altered." But this same mechanism also lets any person check whether a given Coupons.com user (identified only by the user’s Coupons.com user ID) has printed a given coupon — potentially revealing significant information about the user’s purchasing interests.

To confirm the effect of Coupons.com’s Veri-fi service, I entered the codes from the example coupon shown above. I received the first confirmation shown at right — indicating that the specified user ID (me) had printed the specified coupon.

I then entered the same user ID, but a different coupon code. In particular, I chose a coupon code associated with a valid Coupons.com coupon that I had never printed using the specified user ID. As shown in the second screenshot at right, Veri-fi reported that this second code was invalid. That is, Veri-fi reported that the specified user ID had never printed the specified coupon.

Veri-fi seems to work just as Coupons.com intended. However, combining the Veri-fi verification system with the widespread distribution of Coupons.com user IDs (both in print and through JavaScript), Coupons.com reveals detailed information about which users have requested which coupons. Via the JavaScript interface, a web site can easily extract a user’s Coupons.com user ID. Then, via Veri-fi, the web site can check which coupons the user has printed. The web site can thereby build a rich profile of the user’s purchasing interests — despite the promise in Coupons.com’s privacy policy that such information would be distributed only to Coupons.com’s clients, ad servers, and advertisers.

Strikingly, Coupons.com fails to limit Veri-fi to bona fide coupon validators (e.g. retailers and manufacturers). In fact, Veri-fi lacks even a Terms of Service document or a license agreement to attempt to limit who uses the site.

Update (August 28, 2007 – 3:35pm): Coupons.com has contacted me to report that the Veri-fi site no longer allows the data retrieval described above.

Implications & Consequences

A user visiting Coupons.com reasonably expects to get free coupons. Unfortunately, Coupons.com’s practices far exceed anything described in marketing materials, EULA, or privacy policy. Would users join Coupons.com if they knew they had to receive deceptively-named files? That uninstall would leave files behind for possible use later? That every printout would carry a user ID that could be linked to a user’s full coupon-printing history? That Coupons.com’s software and web site would distribute user information in ways even Coupons.com probably didn’t anticipate? We can’t know the answers to these questions because Coupons.com never gave users the opportunity to decide. But with full disclosure, users might well choose to get their coupons elsewhere.

Coupons.com prominently touts its certifications from TRUSTe (including TRUSTe’s new Trusted Download Program) and BBBOnLine. But when these organizations learn of Coupons.com’s specific practices, I doubt they’ll be impressed. Coupons.com’s practices are in tension with various TRUSTe rules, including a Trusted Download prohibition on certain deceptive filenames and registry keys, as well as TRUSTe’s general prohibition on privacy policy violations. More generally, it’s hard to call a program "trusted" when it uses deceptive names to hide some of its key files, when it fails to remove itself fully upon a user’s specific request, and when it makes available users’ identifying information despite privacy policy promises to the contrary. Retaining the credibility of Trusted Download probably requires that TRUSTe take action either to correct Coupons.com’s practices or to sever TRUSTe’s ties to Coupons.com.

Coupons.com could easily fix some of these bad practices. A new version of Coupons.com’s software could prevent arbitrary web sites from retrieving user ID numbers. Coupons.com could stop printing users’ ID numbers on each coupon, or could prominently tell users that each coupon bears a user ID. Coupons.com could limit Veri-fi access to retailers and manufacturers.

With effort, Coupons.com could track users’ coupon-printing without underhanded tactics like deceptive files and registry entries. For one, Coupons.com could label its files and registry keys appropriately — treating its users with dignity and respect, rather than assuming users will try to cheat. Alternatively, Coupons.com could use recognize computers on which it has previously been installed, without resorting to deceptive files or registry entries. (Direct Revenue built such a system — checking a user’s ethernet address, Windows product key, etc. in order to identify repeat installations.) Simpler yet, Coupons.com could request users’ email addresses, and use duplicate addresses to recognize repeat users. Coupons.com may worry that email addresses offer inadequate security, but eBay (Paypal), Google, and others have used this method even for larger offers (as large as $5 – $10).

Coupons.com’s practices fit the historical problems with digital rights management (DRM) software that attempts to constrain what users can do with their own computers. Compare Coupons.com’s approach to the notorious Sony CDs which used a rootkit to conceal Sony’s DRM software. Just as Sony had to rely on a rootkit to hide its DRM software from users who otherwise would have chosen to remove it, Coupons.com hides user IDs in obscure files and registry keys. Just as Sony’s disclosures were less than forthright, so too does Coupons.com fail to tell users what it is doing and how. Based on their examination of software to constrain access to digital music, Ed Felten and Alex Halderman previously explained the core problem: So long as users don’t want a given piece of code on their computers, vendors are forced to conceal their efforts to put it there and to keep it there. As to Coupons.com, some users do want the core functionality. But tracking users after uninstall is sufficiently noxious that Coupons.com knows it must cover its tracks lest users notice. Coupons.com thus finds itself in the same DRM predicament that ensnared Sony.

FullContext Spyware Injects Coupons.com Ads Into Google

Coupons.com is currently suing John Stottlemire, who Coupons.com claims told users "how to beat the limitation imposed by the software provided by coupons.com." (Complaint paragraph 20.) Coupons.com alleges that Stottlemire "created and used software that purported to remove Plaintiff’s security features, for the purpose of printing more coupons than [Coupons.com’s] security features allow." (Paragraph 21) Coupons.com claims that Stottlemire’s practices violate the Digital Millennium Copyright Act, among other causes of action. I can’t speak to the merits of Coupons.com’s claim. But perhaps Coupons.com would do better to focus on protecting users’ privacy and on complying with its privacy policy.

Coupons.com’s behaviors are particularly notable because they extend to multiple coupon-printing programs distributed by literally thousands of web sites. Although I primarily tested Coupons.com’s Coupon Bar software (version 5.0), it seems Coupons.com’s Coupon Printer 4.1 shares all relevant characteristics. (These are the two Coupons.com programs that have been certified by TRUSTe’s Trusted Download.) In addition to distribution at the Coupons.com web site, these programs are also offered by numerous partner sites. Coupons.com’s marketing materials claim more than 1500 such sites, including the LA Times, Washington Times, and Philly.com.

Coupons.com’s online advertising strategy raises trust and privacy questions similar to those presented by Coupons.com’s coupon-printing software. Twice this year I’ve seen and recorded Coupons.com ads shown through spyware: First through the FullContext ad injector (which put Coupons.com ads into the top of Google.com, above Google’s logo), and later through Targetsaver full-screen pop-up ads. Screenshots. Both programs are widespread and known for installing without consent, among other anti-consumer practices. To be a respected player in the online advertising economy, Coupons.com must do more to avoid funding these spyware vendors and the unsavory ecosystem they represent.

Update on Coupons.com’s Response, My Critique, and TRUSTe’s Decision (September 23, 2007)

After I posted the article above, Coupons.com circulated a two-page response. Among other claims, the response argues that the specified registry keys and filenames are "not deceptive." I emphatically disagree. The components are intentionally named to look like they’re part of Windows, and they’re placed in locations where Windows components ordinarily appear. These practices are exactly intended to mislead users as to the components’ purpose. That’s the essence of deception.

Coupons further claims the "user ID" I describe is in fact a "device ID." As a threshhold matter, that would change none of my analysis. But the word "user" comes directly from Coupons.com’s own source code. Coupons’ JavaScript code references a function called "GetUserCode()" (emphasis added) and passes a OBJECT PARAM tag with value USERID (emphasis added). Elsewhere, Coupons.com uses the abbreviation "txtUID" — i.e. a text field storing a user ID. With these repeated "user" references appearing in code written by Coupons.com, Coupons.com cannot credibly claim I err in my use of that same term.

Coupons.com goes on to argue it ought not be responsible for third parties using Coupons.com’s software to obtain user IDs. Coupons says "it is hard to imagine how a third party’s unauthorized use of our software — a sort of trespass … — constitutes our violation of our own privacy policy." I disagree. Perhaps Coupons.com should begin by rereading its privacy policy. Within the heading "our commitment to data security," Coupons.com specifically promises to "use[] commercially reasonable physical, managerial, and technical safeguards to preserve the integrity and security of your personal information." Coupons.com cannot in good conscience claim it is a "commercially reasonable" "technical safeguard" to allow any web site to invoke a simple JavaScript method of Coupons.com’s software. Quite the contrary, this is poor design — falling far short of industry norms for data protection.

Meanwhile, Coupons.com has updated its installer to show a new license agreement. If a user scrolls to the second screen of the license agreement, the user is told of "License Keys" to be placed on the user’s computer. To Coupons.com’s credit, the installer now discloses that these files will not be removed upon uninstall. But the files continue to be placed in deceptive locations in the user’s Windows directory and in the dedicated Windows section of the user’s registry — a fact nowhere disclosed to users.

On August 31, I filed a watchdog complaint with TRUSTe as to the Coupons.com practices set out above. In response, TRUSTe told me it will require Coupons.com to change its naming system "to avoid looking like … other popular software" (i.e. Windows). TRUSTe will also require Coupons.com to offer a new version of its software that removes deceptive files and registry entries leftover from prior versions. (TRUSTe’s blog describes these same requirements, albeit in terms less stark than the email TRUSTe sent me.) These are certainly steps in the right direction. Were the decision mine to make, I doubt I’d keep Coupons.com on the Trusted Download whitelist during a period when the company’s practices are known to fall short. But that’s a topic for another day.

Meanwhile, Coupons.com continues litigation against John Stottlemire. I’ve been in touch with John. I’ve learned that his software — which would have removed Coupons.com’s deceptive files and registry entries upon a user’s specific request — was actually never distributed to anyone but Coupons.com. (John’s web server detected Coupons.com’s IP addresses and granted them access, even before John was prepared to make the software available to anyone else.) This fact leaves me all the more doubtful of Coupons.com’s litigation strategy. John’s software was never used by even a single user. And John’s software would have done nothing more than remove the deceptively-named components TRUSTe is now ordering Coupons.com to remove itself. I remain hopeful that Coupons.com will withdraw this ill-fated attempt to silence a critic. Pending that, I’ve added John’s plight to my spyware threats page.

Finally, Coupons.com’s sneaky tactics continue to undermine its standing in the security community. Some top anti-spyware programs now detect Coupons.com — and rightly so, in my view. Users with Coupons.com software deserve extra information — not forthcoming from Coupons.com — about what the software does and why users might not want it.