1. 

   Honey takes payments that would otherwise go to influencers who recommended products users buy. (video at 2:50) MegaLag shows Honey claiming payments in four scenarios: i) if a user activates a function to search for coupons (even if none are found), ii) if a user activates a function to claim Honey Gold (no matter how meager the rebate), iii) if the user gets the message “We searched for you but didn’t find any deals” and merely presses the button “Got it”, and iv) If Honey shows the message “Get Rewarded with PayPal” “Shop eligible items to earn cash off future purchases” and the user presses “checkout”.

2. Honey doesn’t actually get the best deals for users. If a merchant joins Honey (and begins to pay Honey affiliate commissions), Honey allows the merchant to limit which coupons Honey shows to users. MegaLag points out that letting merchants remove discounts from Honey is squarely contrary to Honey’s promise to users that it will find “the Internet’s best discount codes” and “find every working promo code on the Internet.” (video at 16:20)

16 million views and growing, MegaLag’s video has prompted a class action lawsuit and millions of users uninstalling Honey.

I’m a big fan of MegaLag.  I watched most of his other videos, and they’re both informative and useful—for example, testing Apple AirTags by intentionally leaving items to be taken; exploring false claims by DHL about both package status and their supposed investigations.  Meanwhile, nothing in MegaLag’s online profile indicates prior experience in affiliate marketing.  But for a first investigation on this subject, he gets most things right, and he uses many appropriate methods including browser dev tools and screen-capture video.  Based on its size and its practice, Honey absolutely deserves the scrutiny it’s now getting.  Kudos to MegaLag.

Nonetheless there’s a lot MegaLag doesn’t say.  Most notably, he doesn’t mention contracts—the legal infrastructure that both authorizes Honey to get paid and sets constraints on when and how it may operate.  Furthermore, he doesn’t even consider whether merchants get good value for the fees they pay Honey.  In this piece, I explore where I see Honey most vulnerable—both under contract and for merchants looking to spend their marketing funds optimally.

The contracts that bind Honey

Affiliate marketing comprises a web of contracts.  Most affiliate merchants hire a network to track which affiliate sent which traffic, to provide reports to both merchant and publishers, and to handle payments.  For a single affiliate-merchant relationship, an affiliate ends up subject to at least two separate contracts: the network’s standard rules, and any merchant-specific rules.  Of course there are tens of thousands of affiliate merchants, and multiple big networks.  So it’s impossible to make a blanket statement about how all contracts treat Honey’s conduct.  Nonetheless, we can look at some big ones.  Numbering added for subsequent reference.

Commission Junction Publisher Service Agreement

C1 “You must promote Advertisers such that You do not mislead the Visitor”

C2 “the Links deliver bona fide Transactions by the Visitor to Advertiser from the Link”

C3 “You must accurately, clearly and completely describe all promotional methods by selecting the appropriate descriptions and providing additional information when necessary.”

C4 “You agree to: (i) use ethical and legal business practices”

C5 “Software-based activity must honor the CJ Affiliate Software Publishers Policy requirements (as such requirements may be modified from time to time), including but not limited to: (i) installation requirements, (ii) enduser agreement requirements, (iii) afsrc=1 requirements, (iv) requirements prohibiting usurpation of a Transaction that might otherwise result in a Payout to another Publisher (e.g. by purposefully detecting and forcing a subsequent click-through on a link of the same Advertiser) and (v) non-interference with competing advertiser/ publisher referrals.”

Rakuten Advertising Downloadable Software Applications (DSAs) Overview, Testing Process, Policies

R1 “Your DSA should become inactive on the sites of any advertisers who opt-out or stand down on those that do not want you to redirect their traffic.  Publishers who fail to comply with this rule will jeopardize their relationship with advertisers as well as with Rakuten Advertising.”

R2 “[W]e expect your DSA to: Stand down when it recognizes any publisher links”

R3 “[A]ll software must recognize Supplier domains and the linksynergy tracking links. When a Supplier domain or the linksynergy code is detected, the software may not operate or redirect the consumer to the advertiser site using the Software Publisher tracking ID (also known as Supplier Affiliate ID or Encrypted ID). We do not allow any DSA software that interferes with or deters from any Publisher or Advertiser website.”

R4 “The DSA must stand-down and not display any forms of sliders or pop-ups to prompt activation if another publisher has already referred an end user.”

R5 “The DSA must not force clicks or “cookie stuff”. The DSA must not insert a cookie onto the user’s computer without the user knowingly taking an action that results in the cookie being placed.”

R6 “The end user must click through the offer that is presented. Placing the mouse over an offer, only viewing it or viewing all offers is not a click through.”

R7 “The DSA must not automatically drop a cookie when the end user is only viewing offers. The cookie should only be dropped once the end user clicks on a specific offer.”

Awin including ShareASale – Code of Conduct, Awin US Publisher Terms, SAS US Publisher Agreement

A1 “’Click’ means the intentional and voluntary following of a Link by a Visitor as part of marketing services as reported by the Tracking Code only;”

A2 “Publishers only initiate tracking via a tracking link used for click tracking if the user voluntarily and intentionally interacted with the Ad Media or Tracking link.”

A3 Publishers only initiate tracking for a specific advertiser if the consumer interacted directly with ad media for this advertiser.”

A4 ”do not mislead consumers”

A5 “transparency about traffic sources and the environment that ads are displayed in”

In addition, all networks indicate that publishers must disclose their practices to both networks and merchants.  Awin Code of Conduct is representative: “Publishers proactively disclose all promotional activities and obtain advertiser approval for their activities.”  Rakuten’s Testing Process is even more prescriptive, requiring that an affiliate both to submit a first version and to notify Rakuten about any changes to its software so it can retest; plus requiring publishers to answer 16 questions about their software including technical details such as DOM ID and Xpath of key functions.

Honey violates network policies

MegaLag’s video show violations of these network policies.  I see three clusters of violations.

(1) Honey invokes its affiliate links although users did not fairly request any such thing.  Consider “We searched for you but didn’t find any deals” with button labeled “Got it” (MegaLag scenario iii above). “Got it” doesn’t indicate that the user wants, expects, or agrees that Honey will invoke its affiliate link.  That’s certainly misleading (contrary to rule C1).  Nor can Honey claim that a user who clicks “Got it” is “knowingly taking an action that results in the cookie being placed” (R5) because clicking “Got it” isn’t the kind of action that rule contemplates.  Rakuten rules R6 and R7 are equally on point, disallowing invoking an affiliate link based on an activity that doesn’t indicate intent (such as a mouseover), and requiring that an affiliate link only be invoked “once the end user clicks on a specific offer.”  “Got it” isn’t an offer, so under R7, that’s not grounds for invoking a Rakuten link.  So too for Awin, where A1 defines “click” to include only links that are “part of marketing services” (but “Got it” is not marketing service).  See also A2 and A3 (allowing links only as part of “ad media”, but “Got it” is not ad media); and of course A4 (“do not mislead consumers”).

Honey’s invocation of affiliate links upon a “Get rewarded with PayPal” message (MegaLag scenario iv above) is on similarly shaky ground.  For example, responding to a PayPal offer is not “knowingly taking an action that results in the cookie being placed” (R5) – the user knows only that he’s closing the message, not that he’s requesting an affiliate referral back to the merchant.  Similarly, a PayPal offer is not “marketing services” or “ad media” for an Awin merchant (rules A1-A3).

The rule to invoke affiliate links only when a user so requests is no mere technicality.  In affiliate marketing, an affiliate may be paid if 1) the user sees a link, 2) the user clicks the link, and 3) the user buys from the specified merchant.  Skipping step 2 sharply increases the circumstances in which a merchant has to pay commission—not a term a merchant would agree to.  When an affiliate skips step 2, it’s cookie-stuffing.  Publishers have gone to jail for this (and had to pay back commissions received).  Honey didn’t quite stuff cookies as that term is usually used—the user did click something.  But when nothing on the button (not its label, not the surrounding message, not any principle of logic or engineering) indicates or even suggests the button will activate an affiliate link—that’s terrible value for the merchant.

(2) Honey presents its affiliate links although a user recently clicked through another publisher’s offer.  (MegaLag at 2:50)  But networks’ rules require Honey to stand down if another publisher has made a referral.  See rule C5.v (“non-interference with competing advertiser/ publisher referrals”) and R2 (“Stand down when it recognizes any publisher links”).  Rakuten even makes explicit that the stand-down obligation applies not just to automatic clicks (which, uh, aren’t permitted in any event) but also to sliders and popups: “The DSA must stand-down and not display any forms of sliders or pop-ups to prompt activation if another publisher has already referred an end user.” (R4)

Here too, this is no technical violation.  Other publishers need “stand down” rules so they have a fair chance to earn commission for their work promoting a given merchant.  Standing down from another affiliate’s click is the most fundamental affiliate network rule for downloadable software and browser plug-ins.

(3) Honey falls short of disclosure obligations.  “You must accurately, clearly and completely describe all promotional methods by selecting the appropriate descriptions and providing additional information when necessary” (C3).  Publishers must provide “transparency about traffic sources and the environment that ads are displayed in” (A5).  I’m open to being convinced that Honey told networks and merchants it would invoke affiliate links with buttons as weakly labeled as “Got it.”  I don’t buy it.  Merchants have a clear contractual basis to expect complete and forthright disclosures—it is literally their money being paid out.  And merchants authorized networks to collect and evaluate these disclosures for them.  No shortcuts.

One might object that networks can waive rules or create exceptions for key partners.  Not so fast!  Merchants and publishers rely on networks to enforce their published rules exactly as promised.  In fact, in 2007, both merchants and publishers sued ValueClick to allege that it had been less than diligent in enforcing its rules.  ValueClick’s Motion to Dismiss argued that it could do what it wanted, that it had disclaimed all warranties, and that it made no promises that merchants or publishers were entitled to rely on.  But the court denied ValueClick’s motion, eventually yielding a settlement requiring both improved efforts to detect affiliate fraud as well as certain refunds to merchants and payments to publishers.  There’s room to disagree about how much benefit the settlement delivered.  (Maybe the settlement promised changes that ValueClick was going to do anyway.  Maybe the monetary payments were a small fraction of the amount lost by merchants and publishers.)  But the fundamental principle was clear: Networks must follow their contractual representations including policies about prohibited behaviors.  And while networks may try to disavow quality responsibilities, for example via disclaimers in contracts, courts are skeptical of the unfettered discretion these provisions purport to create.  A network that promises to track affiliate transactions ultimately ought to do so accurately, and should neither grant arbitrary waivers nor look the other way about serious misconduct.

How did we get here?

Honey’s one-sentence response to MegaLag was “Honey follows industry rules and practices, including last-click attribution.”  It’s no surprise that Honey claims compliance.  But I was surprised to see affiliate thought-leaders agree.  For example, long-time affiliate expert Brook Schaaf remarked “Honey appears to be in compliance with network standards.”  Awin CEO Adam Ross says MegaLag’s video “portray[s] performance marketing attribution as a form of theft or scam”—suggesting that he too thinks Honey did nothing wrong.

I’ll update this piece with when others dig into the contracts and compare Honey’s practices with the governing requirements.  But after more than 20 years working on affiliate fraud—my first piece on this subject was, wow, 2004—let me offer four observations.

One, it’s easy to get complacent.  Much of what Honey does is distressingly normal among browser extensions.  Test the Rakuten Cashback app and you’ll find much the same thing.  Above, I linked to litigation against Honey, but there’s also now similar litigation against Capital One, alleging that its Capital One Shopping browser extension does much the same.  Brook and Adam are right that Honey’s tactics aren’t a surprise to anyone who’s been in the industry for decades.  Many people have come to accept behaviors that don’t follow the literal meaning of stated policies.

Two, networks’ incentives are mixed.  On one hand, networks want affiliate marketing to be seen as trusted and trustworthy, which requires eliminating practices widely seen as unfair.  At the same time, affiliate networks typically charge a commission on every dollar of commission paid.  As a result, networks directly benefit from anything that increases the number of dollars of commission paid—such as allowing browser plug-ins to change noncommissionable traffic into commissionable traffic.  Merchants should be skeptical of networks too quickly declaring traffic compliant when networks literally get paid for that finding.  With Rakuten operating both a cashback service (with browser plugin) and an affiliate network, their incentives are particularly muddy: If Rakuten Advertising declares a given browser plugin tactic to be permitted, Rakuten Cashback can then use that tactic, increasing both Cashback fees (the Cashback margin on each dollar of rebate) and Advertising fees (the network margin on each dollar of affiliate activity).  I like and respect Rakuten and its leaders, but their complicated incentives mean serious people should give their pronouncements a second look.

Three, most people read the governing contracts hastily if at all.  I’m proud to have pulled out the 17 rules above, and I encourage readers to follow my links to see these and other rules in the larger policy documents.  Fact is, there’s lots of material to digest.  I’ve found that networks’ compliance teams often build rules of thumb that diverge from what the rules actually say, and ignore rules that are in some way seen as inconvenient or overly restrictive.  To me, all this is a mistake.  The rules may not be holy, but they have the force of contract, and there’s real money at issue.  Networks are spending other people’s money­­­—making sure normal publishers get every dollar they fairly earned; and making sure merchants pay the correct amount, but not a penny more.  This calls for a high level of care.  We’re two weeks into the response to MegaLag.  How many people posted video-responses, blogs, or other remarks without finding, reading, and applying the governing policies?

Four, personalities and work styles invite even merchant staff to accept what Honey is doing.  Representative short-hand: “Go along to get along.”  Many marketers chose this line of work to make connections, not to play policeman.  Attend an affiliate marketing conference and you’re a lot more likely to see DJs and beer (party!) than network sniffers and virtual machines (forensic tools).  Meanwhile, it’s awfully easy for an affiliate manager to tell a boss “we’re working with Honey, the billion-dollar product from PayPal”—then head to the Honey gala at an industry conference.  Conversely, consider the affiliate manager who has to explain “we wasted $50k on Honey last month.”  People have been fired for less.  Ultimately, online marketing plays a procurement function—trying to spend an employer or client’s money as skillfully as possible, to get as much benefit as possible for as little expenditure as possible.  But that’s hard work.  I don’t fault those who want an easier path.  And I don’t fault those who prefer the networking and gala side of marketing over the software forensics.  Nonetheless, collective focus elsewhere goes a long way towards explaining how problems can linger for years.

Is Honey profitable for merchants?

For a merchant evaluating Honey, the fundamental question is pretty simple: Does Honey bring the merchant incremental sales and positive ROI?  Clearly Honey’s browser extension positions it to claim credit on purchases users were already going to make, but incremental sales are what matter to merchants—purchases made only thanks to Honey.

My hypothesis is that Honey is ROI negative for most merchants.  If a user goes to (say) dell.com, the user is already interested in Dell.  Why should Dell let Honey’s browser plug-in jump in and claim a commission on that user’s purchase?  Maybe Honey will increase the user’s conversion rate from 5% to 5.1% (by proclaiming what a good deal the user has found, or by touting a Honey Gold sweetener).  But with payment to Honey, Dell’s margin will drop from (say) 7% to 5%.  Would Dell prefer 7% profit on 500 sales, or 5% profit on 510?  That math is pretty easy.

Of course the numbers in the preceding paragraph are just hypotheticals.  If users sufficiently trust Honey (whether correctly or otherwise), their conversion rate might increase enough to justify Honey’s fees to merchants.  If Honey could somehow persuade users to spend more—“add one more item to your cart, and you can get this $10 coupon”—that could increase value to merchants too (though I’ve never seen Honey deliver such a message).  Some merchant advisors think this is plausible.  I have my doubts.

Alarmingly, many merchants decide to work with Honey (and other “loyalty” software) without rigorously measuring incrementality (or even trying).  Most merchants take some steps to measure the ROI of search and display ads.  For years, affiliate ROI has been more challenging.  But I recently devised a rigorous method that’s doable for most merchants.  I’d enjoy discussing with anyone interested.  When I have findings from a few merchants, with their permission I’ll share aggregate results.

Looking ahead

It’s easy to watch MegaLag’s piece and come out sour on affiliate marketing.  (“What a mess!”)  For that matter, the affiliate marketing section of my site has 28 articles over 20+ years, almost all about some violation or abuse.

Yet I am fundamentally a fan of affiliate marketing.  Incentives aren’t perfectly aligned between affiliate, network, and merchant, but they’re a whole lot closer than in other kinds of online advertising.  One twist in affiliate is that when a rogue affiliate finds a loophole, they can often exploit it at scale—by some indications, even more so than in other kinds of online advertising.  Hence the special importance of networks and merchants both providing fairness and being perceived as providing fairness.  MegaLag’s critique of Honey shows there’s no shortage of work to do.

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

<capture>
<md5>ee593c14f70c1b7f8b3341a91c3e3639</md5>
<version>1.0</version>
</capture>

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

<capture>
<md5>ee7e3174db149d0d97f51b10db9ac58d</md5>
<version>1.0</version>
</capture>

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

<capture>
<md5>352732ac9ee0d9e970f3c65d62ed03b1</md5>
<version>1.0</version>
</capture>

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

<capture>
<md5>26830cfab132bb3122fcf40d8cd0f2f9</md5>
<version>1.0</version>
</capture>

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.

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.

ComScore’s tracking software is remarkably invasive. The privacy policy for ComScore’s RelevantKnowledge tracking program purports to grant ComScore the right to track users’ name and address, browsing, shopping, and even “online accounts … includ[ing] personal financial [and] health information.” Based on these privacy concerns, well-respected security researchers have long warned about ComScore’s software. For example, in 2004 Cornell University began blocking all communications with ComScore’s MarketScore tracking servers. Multiple other universities (including Columbia University and Indiana University) followed up with special warnings to their users.

At least as serious are ComScore’s installation practices. ComScore pays independent distributors to install ComScore software onto users’ computers. Predictably, some of these distributors install ComScore software without getting user consent. Some specific examples:

• On Wednesday (June 27, 2007), I browsed ExitExchange, a well-known banner farm widely loaded in popups and popunders by various sites (as well as some spyware programs). ExitExchange showed several ads, one of which performed a security exploit that installed ComScore’s RelevantKnowledge. See video proof. Notice the exploit beginning at 0:12. When I ran a HijackThis scan to check for infections (0:29), I found RelevantKnowledge’s “rk.exe” already running (1:10), even though I had not granted permission for it to install. Packet log analysis indicates that the installation was performed by Topinstalls and by Searchclickads. The installation was predicated on two simultaneous attempted exploits — one using a Java vulnerability, another using a Microsoft MSXML vulnerability. Also installed (all without my consent): Deskwizz/Searchingbooth, Look2me, and WebBuying, among others not yet identified.
• I previously observed and recorded a substantially similar nonconsensual installation of RelevantKnowledge (by these same distributors) on April 26, 2007.
• Spyware researchers at Sunbelt Software observed a nonconsensual installation of RelevantKnowledge, seemingly by these same distributors, earlier in June 2007. Sunbelt staff browsed FirstStolz and received an exploit that installed TopInstalls and Searchclickads, which in turn installed RelevantKnowledge.
• In August-September 2006, I repeatedly observed RelevantKnowledge installed by DollarRevenue, a notorious spyware bundler (subsequently shut down by Dutch law enforcement). In my testing, DollarRevenue installed RelevantKnowledge software without users’ consent. ComScore staff later admitted they had “engaged in partnership negotiations with DollarRevenue.” ComScore claims it never paid DollarRevenue — but I personally observed and recorded DollarRevenue installing ComScore software onto my testing systems.
• In November 2005, I observed ComScore’s MarketScore software installed by PacerD, a notorious spyware bundler that installed through widespread exploits syndicated through ad networks. PacerD installed RelevantKnowledge without user consent.
• In April 2007, I observed ComScore’s MarketScore software installed when users request and install a media converter program. The inclusion of MarketScore was disclosed only if users scrolled to page four of a box simply labeled “License Agreement.” No on-screen label indicated that multiple documents were concatenated into that single scroll box, nor did any short notice or other prominent text make any mention of RelevantKnowledge’s presence or effects. These omissions stand in stark contrast to recent FTC precedent requiring “clear and prominent disclosure of material terms prior to and separate from any end user license agreement.”

ComScore’s nonconsensual installations are particularly notable because TRUSTe’s Trusted Download program recently granted a certification (albeit “provisional”) to ComScore’s RelevantKnowledge software. I’ve previously criticized other TRUSTe certifications — concerned that TRUSTe-certified sites may be no safer than other sites, and arguably less safe. That said, to TRUSTe’s credit, Integrated Search Technologies’ Vomba is no longer on TRUSTe’s Trusted Download list — albeit a result that TRUSTe attributes to Vomba’s financial concerns rather than to security researchers‘ critique of Vomba’s practices and lineage. Whatever the reasons for IST’s removal, perhaps ComScore’s MarketScorecould stand for an equally thorough review.

ComScore also boasts a “WebTrust” seal from Ernst & Young. See the associated Audit Report. Ernst & Young indicates that it “test[ed] and evaluat[ed] the operating effectiveness” of ComSCore’s internal controls but concedes that “error or fraud may occur and not be detected.”

Update – TRUSTe’s Response (July 26, 2007)

On Friday July 20 — well after the close of the East Coast business day, and fully three weeks after I first reported the nonconsensual installs described above — TRUSTe announced that ComScore’s RelevantKnowledge has been removed from the Trusted Download whitelist for three months.

I have mixed views about this outcome. On one hand, it’s certainly an improvement from prior TRUSTe practice, during which companies as notorious as Direct Revenue were allowed to continue to hold TRUSTe privacy seals despite widespread nonconsensual installations. But a comment from Sunbelt Software’s Eric Howes offers compelling concerns. Eric explains:

[TRUSTe has] essentially decided to continue working with ComScore, provided ComScore spends a token amount of time in the “naughty corner.” … Who loses as a result? Consumers and web surfers ultimately, as ComScore will be allowed to continue plying its trade of surreptitious, underhanded installs of its RelevantKnowledge software to support some very aggressive and intrusive data collection on unsuspecting users’ machines, all with PR cover from TRUSTe.

Eric also cites a June 27 exchange between Sunbelt CEO Alex Eckleberry and TRUSTe’s Colin O’Malley. Transcribing from the audio recording of the Anti-Spyware Coalition‘s public workshop :

Alex Eckelberry: “So what if you have an application that is installing through an exploit? Do those guys go through a probationary process, or do they just get cut off? Are they just gone?”

Colin O’Malley: “If they’re installing through an exploit, that’s covered in what’s described in what we describe as our prohibited activities. That’s not an activity that is acceptable by any level of notice, and so they’re terminated immediately.”

Alex Eckelberry: “Good. OK.”

Remarkably, TRUSTe’s spokesperson now claims Colin promised termination only when a vendor itself uses exploits, but not when its distributors do so. Reports Vnunet: “‘Colin [O’Malley]’s remarks were specifically about a company that is directly responsible,’ the spokesperson explained. ‘In this case, it was the affiliate that was exploiting the flaw.'”

I’ve read and reread the exchange, and listened repeatedly for good measure. On my interpretation, Colin plainly promised to terminate any vendor whose software is becoming installed through exploits — no matter whether the vendor itself performs the exploit, or whether the exploit is performed by one of the vendor’s distributors. I reach this conclusion for two separate reasons:

1) The plain language of Alex’s question is intentionally inclusive as to who is doing the installation. Notice the broad “that is installing” — vague as to how exactly the installation is occurring.

2) Distributor-perpetrated exploit installs have been standard practice in the “adware” industrry. That’s what I widely observed as to 180solutions, Direct Revenue, eXact Advertising, and so many others. Meanwhile, vendor-perpetrated exploit installs are few and far between — common only among little-known companies, and even then usually comingled with installing third parties’ software. So if Colin had wanted to remark only on the (unusual or unprecedented) vendor-perpetrated exploits, he would have needed to say that specifically.

Perhaps TRUSTe regrets the breadth of Colin’s promise. But Colin made a tough commitment for good reason: As Colin spoke to dozens of anti-spyware researchers already suspicious of Trusted Download, his big promises helped bolster TRUSTe’s credibility. Had Colin told the ASC what now seems to be TRUSTe’s policy — that some exploit-based installs yield only a temporary suspension — I gather Alex would have questioned Colin further to emphasize the need for a tougher response. Other meeting attendees would probably have done the same.

In any event, if Colin’s goal was to build support among anti-spyware researchers, his efforts don’t seem to be succeeding. Eric continues:

Th[is] case was significant in that it was the first big public test of how well TRUSTe would perform when called to defend the standards that allegedly undergird the Trusted Download program. When push came to shove, though, TRUSTe demonstrated itself to be lacking the backbone to deliver on its word. [This is] another illustration of why we at Sunbelt place no value whatsoever in TRUSTe’s whitelisting and certifications.

Added FaceTime’s Chris Boyd:

For Gods sake, when are we going to stop gimping around and actually break out some actual punishments for people? Either kick someone from your program and be done with it, or … just give up already.

TRUSTe’s extreme delay further compromises the standing of Trusted Download: Three weeks elapsed before TRUSTe responded to my documentation and proof of nonconsensual ComScore RelevantKnowledge installations. Throughout that period, the Trusted Download whitelist continued to list RelevantKnowledge — falsely suggesting that RelevantKnowledge was in good standing. Internet users deserve better: When TRUSTe learns of an infraction of such seriousness, all applicable web pages ought to be updated promptly, lest the Internet community mistakenly proceed in reliance on TRUSTe’s supposed diligence.

For Display Advertisers and Display Networks

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

• Advertisements loaded invisibly, including in invisible IFRAMEs, nested IFRAMEs, invisible CSS layers, and similar. (Examples: Sony’s Crackle receiving invisible traffic, Mytoursinfo creating dozens of invisible IFRAMEs, each with 3+ advertisements)
• Advertisements loaded in popups, popunders, and other windows users did not request.
• Advertisements loaded in spyware/adware popups and popunders. (Examples: Vonage advertising through full-screen popups covering competitors’ sites, various video sites buying spyware/adware popup traffic.)
• Advertisements loaded in “injectors” that insert ads into publishers’ sites without publishers’ approval and without payment to publishers. (Example: networks and advertisers funding AddLyrics, PeachFuzz, and Sambreel WebCake, Vonage advertising through Fullcontext injector, Travelocity and Cingular (AT&T) advertising through Fullcontext injector.)
• Automatic/rapid reload of advertisements. (Example: Inqwire reloading advertisements every nine seconds.)
• Publishers presenting multiple ads stacked on top of each other, such that even “above the fold” ads are not actually visible to users. (Example: Global-store covering some advertisements with other advertisements.)
• Publishers and brokers “multi-serving” multiple ads into a space that can hold only one.
• Publishers and brokers making false statement of placement location, i.e. claiming that an ad is placed in one site when it is actually loaded somewhere entirely different.
• Advertisements in typosquatting and parked domains.

For Affiliate Advertisers and Affiliate Networks

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

• Spyware and adware invoking affiliate links, claiming commission on merchants’ organic/type-in traffic. (Examples: Six rogue affiliates overcharging VistaPrint, ten rogue affiliates overcharging Hydra Media advertisers, rogue Dell affiliate claiming commission on Dell’s organic traffic, Zango/180solutions using multiple visible and invisible methods to claim commission from affiliate merchants, six further Zango examples and four Viraltube Toolbar examples.)
• Spyware and adware invoking affiliate links, covering merchants’ competitors’ sites. (Examples: Rogue Dell affiliate covering competing PC makers’ sites with adware popups, rogue Gateway affiliate presenting popunder for Gateway when users browse the Dell site.)
• Typosquatting domains invoking affiliate links, claiming commission on typographic errors of merchants’ domain names.
• Web pages loading affiliate links invisibly, without an affirmative end-user click on an affiliate link (“cookie-stuffing”). (30+ examples, cookie-stuffing using encoded JavaScript, hack-based cookie-stuffing, cookie-stuffing using display Google’s ad network as a traffic source, further examples.)
• Web pages loading affiliate links in popups and popunders, without an affirmative end-user click on an affiliate link.
• Banner advertisements loading affiliate links invisibly, without an end-user click on an affiliate link. (Example: Allebrands banner invisibly loads three affiliate links.)
• Email messages promoting affiliate links in violation of merchants’ rules.
• Adware, “loyalty programs,” and similar software automatically invoking affiliate links when users request merchants’ sites.
• Adware, “loyalty programs,” and similar software presenting affiliate links, and covering a portion of merchants’ sites with such links, while users browse merchants’ sites.
• ISP network configurations that claim commission on organic/type-in traffic. (Example: Aspira Networks.)

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

For Advertisers in Comparison Shopping Engines

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

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

Methods

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

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

Please contact me to learn more about my reports.

Last updated: May 21, 2016

But the SAHS site doesn’t tell the whole story. My testing demonstrates that SAHS software is often installed without users wanting it, requesting it, or even accepting it. (Details.) When users receive an unwanted SAHS installation, SAHS still claims commissions on users’ purchases — but typical users will never see a penny of the proceeds. (Details.) Meanwhile, whether requested by users or not, SAHS’s commission-claiming practices seem to violate stated rules of affiliate networks. (Details.)

Despite these serious problems, SAHS boasts a superstar list of clients — the biggest merchants at all the major affiliate networks, including Dell, Buy.com, Expedia, Gap, and Apple. Why? Affiliate networks have little incentive to investigate SAHS’s practices or assure compliance with stated rules. (Details.) SAHS and affiliate networks profit, but users and merchants are left as victims. (Details.)

Update (October 14): Commission Junction has removed SAHS from its network, thereby ending SAHS’s relationships with all CJ merchants. No word on similar actions by LinkShare or Performics.

Wrongful Installations – No Consent, and Tricky So-Called “Consent”

ShopAtHomeSelect is widely known to become installed without meaningful consent — or, in many cases, without any consent at all. Most egregious are installations through security exploits, without any notice or consent. I continually test these installations in my lab, and I have repeatedly observed SAHS appearing unrequested — more than half a dozen such installs, occurring on distinct sites on distinct days. I posted one such video in May, and I retain the others on file.

SAHS’s improper installations extend to many of SAHS’s bundling partners. I have repeatedly seen (and often recorded) SAHS disclosed midway through lengthy license agreements; users often have to scroll through dozens of pages to learn of SAHS’s inclusion. Even worse, some programs that bundle SAHS nonetheless fail to mention SAHS’s inclusion. See e.g. 3D Flying Icons, which shows a 12-page 2,286-word license that makes no mention of SAHS, yet 3D installs SAHS anyway. (Screenshot at right.)

In other instances, ActiveX popups pressure users to accept multiple advertising programs in the guise of “browser enhancements” (or similar). In February 2005, I observed an ActiveX popup that labeled itself “website access” and “click yes to continue,” but immediately installed SAHS if users pressed yes once. More recently, I posted an analysis of the PacerD ActiveX. (Screenshot at left.) PacerD’s ActiveX popup links to a license agreement which discloses installation of eight advertising programs — but doesn’t mention SAHS, though Pacer in fact does install SAHS. So even when careful users take the time to examine Pacer’s 1,951-word license, in hopes of learning what they’re getting, there’s no way to learn that SAHS will be installed, not to mention grant or deny consent.

I’m not the only observer to notice SAHS installed improperly. Earlier this month, VitalSecurity.org reported SAHS installed via IM spam: Users receive an unsolicited instant message, and clicking the message’s link installs SAHS (among other programs) without any notice or consent. Last month, PC Pitstop (1, 2) and VitalSecurity.org reported SAHS bundled with porn videos distributed by BitTorrent — so a user seeking adult entertainment would unwittingly receive SAHS too. In my testing of these BitTorrent videos, SAHS was listed in a license agreement preceding the videos, but users had to scroll past four pages of other text to learn of SAHS’s inclusion, and even then SAHS’s mention was only a single sentence — without even a link to an external SAHS license agreement, and without any description of the privacy effects of installing SAHS software. (See screenshot at right.) Furthermore, these BitTorrent videos aren’t SAHS’s only tie to porn videos. In January, I analyzed ActiveX popups triggered by porn videos. These popups falsely claimed to be required to view the videos, but in fact they were mere ploys seeking to install SAHS and other advertising software.

In short, a user receiving SAHS cannot reasonably be claimed to have wanted SAHS, nor to have granted informed consent. Perhaps some SAHS users run SAHS willingly and knowingly, but many clearly do not.

In contrast, affiliate networks’ rules set a high burden for installation disclosure and consent. LinkShare’s Shopping Technologies Addendum (PDF) requires that disclosure be “full and prominent,” a standard met neither by SAHS’s nonconsensual installations, nor by its installation when bundled with porn videos. Commission Junction’s Publisher Code of Conduct requires that disclosure be “clearly presented to and accepted by” users, and CJ specifically prohibits software that is “installed invisibly” (as in the nonconsensual installations detailed above).

SAHS may claim that these wrongful installations have stopped. But that’s just not credible. I’ve continued to see (and record) these installations as recently as the past few days.

SAHS may say these wrongful installations are the fault of its distributors. (SAHS offered that argument when PC Pitstop inquired as to SAHS bundling with porn videos.) But affiliate networks’ rules do not forgive wrongful installations merely because the installations were performed by others. To the contrary, affiliate networks set out high consent requirements which apply no matter who installs the software. Furthermore, with so many diverse wrongful installations over such an extended period, it’s clear that something is fundamentally wrong with SAHS’s installation methods; SAHS can’t escape responsibility by vague finger-pointing.

Wrongful Operation – Forced Clicks

In addition to regulating installation methods, affiliate networks’ rules limit the ways in which affiliates may claim affiliate commissions. Commission Junction’s Publisher Code of Conduct prohibits claiming commissions on “non-end-user initiated events” — invoking affiliate links without an “affirmative end-user action.” LinkShare’s Shopping Technologies Addendum (PDF) lacks a corresponding prohibition of non-end-user initiated events, but LinkShare’s Affiliate Membership Agreement repeatedly calls for affirmative user actions as a necessary condition to earning commission. For example, LinkShare’s provision 1.1 says commissions are payable only for “users who activate the hyperlink” (emphasis added); the “users … activate” wording specifically contemplates a user taking an affirmative action, not merely a software program automatically opening a link. (Since LinkShare’s special Addendum lacks any provision to the contrary, these Agreement terms still apply.)

There are good reasons for these rules: Affiliate merchants often make substantial payments if an affiliate link is activated and a user makes a purchase. (For example, Dell could easily pay $10+ for a single purchase through a single link.) So software programs aren’t allowed to “click” on affiliate links automatically. Instead, users must actually show some interest in the links — protecting merchants from being asked to pay commissions when an affiliate did nothing to earn a fee.

Although applicable network rules require that clicks on affiliate links be affirmative and that such clicks actually be performed by users (not just by software), SAHS software opens affiliate links and claims commissions without users taking any specific action. See e.g. this SAHS-Dell video, showing a user requesting www.dell.com on a computer with SAHS installed. SAHS immediately redirects the user to its affiliate link to Dell (video at 0:06), and LinkShare affiliate cookies are created (0:08), all without a user affirmatively clicking on any SAHS affiliate link. See also a corresponding SAHS video for Buy.com, showing affiliate link being loaded (0:06) and cookies created (0:10), again without any user interaction.

So SAHS’s operation constitutes an apparent violation of applicable network rules — claiming affiliate commission without the required user click on an affiliate ad, seemingly contrary to network rules.

Affiliate Networks’ Motives

I began this piece with the claim that affiliate networks have allowed SAHS to remain in their networks, notwithstanding the violations set out above. Why?

One possibility is that the affiliate networks simply never noticed the violations. But that’s a suggestion I can’t accept. Consider the many articles above, each reporting wrongful installations. Much of this work received extensive media coverage, including discussions on industry sites of record. Furthermore, most of these findings can be verified easily using any ordinary PC. So affiliate networks can’t credibly claim ignorance of what was occurring.

More persuasive, in my view, is the theory that affiliate networks declined to punish SAHS because SAHS’s actions are profitable for affiliate networks. When an affiliate merchant pays a commission to an affiliate, that merchant must also pay a fee to the intermediary affiliate network. Commission Junction’s public pricing list reports that this fee is 30% — so for every $1 of commission paid to SAHS, CJ earns another $0.30. As a result, affiliate networks have clear financial incentives to retain even rogue affiliates. (Indeed, at the same time that adware has exploded to infect tens of millions of PCs, CJ and LinkShare are reporting unusually strong earnings. [1, 2])

I don’t want to overstate my worry of affiliate networks’ profit motivation. In recent months, affiliate networks have repeatedly kicked out long-time rule-breakers, even where the rule-breakers make money for the networks. (See e.g. LinkShare kicking out 180solutions, and CJ kicking out 180solutions, Direct Revenue and eXact Advertising.) But these actions generally only occur after an extended period of user and analyst outcry. (See e.g. my writing last summer about 180solutions’ effects on affiliate systems.) In contrast, to date, little attention has been focused on SAHS.

Update (October 14): Commission Junction has removed SAHS from its network, thereby ending SAHS’s relationships with all CJ merchants. No word on similar actions by LinkShare or Performics.

Merchants and Users as Victims

As shown in the example video linked above, SAHS claims affiliate commissions even when users specifically request merchants’ sites. Dell and Buy.com get no bona fide benefit from paying 1%-2% to SAHS, as shown in the videos above. SAHS might claim that it pays users rebates as a way to encourage their purchases from participating merchants. But when SAHS arrives on users’ PCs unrequested, and even without users’ acknowledgement or acceptance of its arrival, users are unlikely to be motivated to make purchases from SAHS-participating merchants. So it’s unclear what benefit SAHS can offer merchants under these circumstances.

Notwithstanding the problems with SAHS’s business, affiliate networks encourage merchants to make payments to SAHS by listing SAHS as an affiliate in good standing, inviting SAHS staff to conferences, and occasionally even giving awards to SAHS. Whether through these network actions or based on merchants’ own failure to diligently investigate, merchants bear the brunt of SAHS’s bad actions — paying out commissions SAHS has not properly earned under stated affiliate network rules.

Users also suffer from SAHS. As a result of the ill-gotten payments paid to SAHS by merchants, SAHS receives funds with which it can and does purchase additional installations from its software distribution partners (including the nonconsensual and tricky installations shown above). Payments from Dell (and other targeted merchants) ultimately help to fund the infection of more users — slowing down more users’ PCs, making more users’ PCs unreliable, and pouring fuel onto the spyware problem. To the extent that affected users respond by buying new PCs, Dell perhaps benefits indirectly — but I gather Dell does not aspire to fund such infections.

SAHS may claim that users benefit from its presence, even if its initial installation was improper. After all, SAHS claims affiliate commissions based on users’ purchases, and SAHS stands ready to refund a share of these commissions to the responsible users. But from the perspective of users who received SAHS without meaningful disclosures, SAHS’s offer is of dubious value. Where a program arrives unrequested, users’ fears of identity theft or fraud will (rightly!) discourage them from providing the personal information necessary to receive a payment (name, address, etc.). SAHS may be offering users legitimate actual payments — but when SAHS’s installation was nonconsensual in the first place, users have no easy way to distinguish SAHS’s offer from a phishing attempt or other scam. Without payment details, SAHS will simply retain users’ funds — giving users no benefit for the unrequested intrusion on their PCs, but giving SAHS extra profits.

This is an unfortunate situation — but it’s not hopeless. Dell, Buy.com, and other affected merchants need not continue to help fund this mess. LinkShare and Commission Junction need not continue to pass money to SAHS from unwitting merchants, nor need they continue taking 30% cuts for themselves. Stay tuned.

Update (September 13): News coverage discusses the problem of SAHS retaining commissions for users who never requested SAHS and never even registered for rebates. CJ claims that they have not confirmed “SAHS performing redirects on unregistered users,” but admits that this would be a “major violation.” I have provided CJ with screenshot and video proof, showing SAHS doing exactly that.

But another side of Ebates’ business has become controversial: Ebates uses a software download called “Moe Money Maker” (MMM) to automatically claim merchants’ affiliate commissions, then pay users rebates — even if users don’t visit Ebates’ web site, and even if users don’t click through Ebates’ special links.

Why the controversy? I see at least two worries:

1) Aggressive software installations.

• Partial screen-shot taken from video of Ebates installation through a security hole, without any notice or consent.

  Users visiting ebates.com can receive MMM software merely by filling out a form and failing to uncheck the “I would like to download MMM” checkbox (checked by default).

• Users downloading certain third-party programs (screen-savers and the like) receive MMM as part of the bundle — disclosed, in my testing, but often with a long license in a small box, such that many users don’t fully understand what they’re getting.
• Most troublingly, there have been persistent allegations of Ebates installed without any notice or consent whatsoever. I had always discounted these allegations until I saw the proof for myself earlier last month. See video of Ebates MMM installed through security holes.

2) Claiming affiliate commissions that would otherwise accrue to other affiliates. Many web sites receive affiliate commissions when users make purchases through special links to merchants’ web sites. (See e.g. Lawrence Lessig‘s “Get It Here” page.) Network rules (Commission Junction , Linkshare) prohibit Ebates from interceding in these transactions; instead, the independent web sites are to receive the commissions for purchases through their links. But Ebates’ software sometimes claims commissions anyway — specifically contrary to applicable rules. These behaviors have been alleged and reported for years, and recently documented in a series of videos (videos of particular interest. Apple, Cooking.com, Diamonds International, JJill, Lillian Vernon, Sharper Image, Sony). If Ebates’ prohibited interventions were only temporary, they would be easy to sweep away as mere malfunctions. But when problems continue for years, to Ebates’ direct financial benefit and to others’ detriment, the behavior becomes harder to disregard.

Meanwhile, Ebates has inspired copy-cat programs with similar business models but even more controversial execution. I’ve recently made literally scores of videos of eXactAdvertising‘s CashBack by BargainBuddy installed through security holes, and also of TopRebates/WebRebates installed through security holes — always without any notice or consent whatsoever. These programs remain participants in the Commission Junction and LinkShare networks — presumably receiving commissions from these networks and their many merchants (CashBack merchants, TopRebates merchants). I’m surprised that so many merchants continue to do business with these software providers — including so many big merchants, who in other contexts would never consider partnering with software installed without notice and consent.

I think the core problem here is skewed incentives. Affiliate networks (CJ and LinkShare) have no financial incentive to limit Ebates’ operation. Instead, the more commissions claimed by Ebates, the more money flows through the networks — letting the networks charge fees of their own. In principle we might expect merchants to refuse to pay commissions not fairly earned — but merchants’ affiliate managers sometimes have secondary motives too. In particular, affiliate managers tend to get bonuses when their affiliate programs grow, which surely makes them particularly hesitant to turn away the large transaction volume brought by MMM’s automatic commission system. That’s not to say some merchants don’t knowingly and intentionally participate in Ebates — some merchants understand that they’ll be paying Ebates a commission on users’ purchases even when users type in merchants’ web addresses directly, and some merchants don’t mind paying these fees. But on the whole I worry that Ebates isn’t doing much good for many merchants, even as its software comes to be installed on more and users’ PCs, with or without their consent.