Crucially, IAC remains substantially dependent on Google for monetization of IAC’s search services. A rigorous application of Google’s existing rules would put a stop to many of IAC’s practices, and sensible updated rules — following the stated objective of Google’s existing policies — would end much of the rest.

In this piece I examine current IAC toolbar installation practices (including targeting kids and soliciting installations when users are attempting to install security updates), the effects of IAC toolbars once installed (including excessive advertising and incomplete uninstall), and IAC’s search arbitrage business. I conclude by flagging advertisements with impermissibly large clickable areas (for both toolbars and search arbitrage), and I call on Google to put an end to Ask’s practices.

IAC Toolbar Installation

IAC’s search toolbar business is grounded in placing IAC toolbars on as many computers as possible. To that end, IAC offers 50+ different toolbars with a variety of branding — Webfetti (“free Facebook graphics”), Guffins (“virtual pet games”), religious toolbars of multiple forms (Know the Bible, Daily Bible Guide, Daily Jewish Guide), screensavers, games, and more. One might reasonably ask: Why would a user want such a toolbar?

The Television Fanatic toolbar is instructive. IAC promotes this toolbar with search ads that promise “free online television” and “turn your computer into a TV watch full TV episode w free app.” It sounds like an attractive deal — many users would relish the ability to watch free live broadcast television on an ordinary computer, and it would not be surprising if such a service required downloading some sort of desktop application or browser plug-in. But in fact Television Fanatic offers nothing of the sort. To the extent that Television Fanatic offers the “free online television” promised in the ad, it only links to ordinary video content already provided by others. (For example, I clicked the toolbar’s “ABC” link and was taken to http://abc.go.com/watch/ — an ordinary ABC link equally available to users without Television Fanatic. That’s a far cry from IAC’s promise of special access to premium material.

Meanwhile, IAC’s Guffins toolbar distinctively targets kids. IAC promotes Guffins via search ads for terms like “virtual pet”, and the resulting ad says Guffins offers “puppy, cats, bunny, dragons & more” which a user can “feed, play, [and] care for.” The landing page features four animated animals with oversized faces and overstated features, distinctively attractive to children. Under COPPA factors or any intuitive analysis, IAC clearly targets kids. Indeed, ad tracking service iSpionage reports Guffins ads touting “Free Kids Games Download”, “Free Kids Computer Games”, “Play Kids Games Online”, and more — explicitly inviting children to install Guffins. Of course kids are ill-equipped to evaluate IAC’s offer — less likely to notice IAC’s disclosures of an included toolbar, less likely to understand what a search toolbar even is, and less able to evaluate the wisdom of installing such a toolbar in exchange for games.

While IAC’s ads often promise an “app” (including as shown in the ad screenshots at right), IAC actually offers just toolbars — add-ins appearing within web browsers, not the freestanding applications that the ads suggest. That’s all the more deceptive: IAC enticed users with the promise of genuine distinct programs offering exceptional video content and rich gaming. Instead IAC provided browser plug-ins that claim valuable screen space whenever users browse the web. And far from providing exclusive content, IAC toolbars send users to material already on the web and driving traffic to IAC’s advertising displays (as detailed in the next section). That’s strikingly inferior.

IAC’s toolbar installation practices stack up unfavorably vis-a-vis applicable Google policies, industry standards, and regulatory requirements. Google’s Software Principles call for “Upfront disclosure” with no suggestion that an app may promise one thing in an initial solicitation, then something else in a subsequent landing page. (IAC is obliged to comply with Google’s rules because IAC toolbars show ads from Google, as discussed in the next section.) Meanwhile, the Anti-Spyware Coalition specifically flags installations targeting children, allowing bundling by affiliates, and modifying browser settings as risk factors making software a greater concern. Even decades-old FTC rules are on point, disallowing “deceptive door openers” that promise one thing at the outset (like IAC’s initial promise of “free online television”) but later deliver something importantly different (a search toolbar).

Web searches reveal numerous user complaints about IAC toolbars. Consider search results for “televisionfanatic”. A first result links to product’s official site. Second is a Sitejabber forum with 20 harsh reviews. (17 reviewers gave Television Fanatic just one star out of five, with comments systematically reporting surprise and annoyance at the toolbar’s presence.) The third result advises “How to uninstall a Television fanatic toolbar”, and the fourth is multiple Yahoo Answers discussions including a user asking “Is television fanatic toolbar a virus?” and others repeatedly complaining about unintended installation. Clearly numerous users are dissatisfied with Television Fanatic.

So too for DailyBibleGuide. In a Q1 2011 earnings call, IAC CEO Greg Blatt touted the DailyBibleGuide toolbar as a new product IAC is particularly proud of. But a Google search results for “DailyBibleGuide” include a page advising “do not download Dailybiblestudy, Dailybibleguide, or Knowthebible extension.” There and elsewhere, users seem surprised to receive IAC’s toolbars. Reading users’ complaints, it seems their confusion ultimately results from IAC’s decision to deliver bible trivia via a toolbar. After all, such material would more naturally be delivered via a web page, email newsletter, or perhaps RSS feed. IAC chose the odd strategy of toolbar-based delivery not because it was genuinely what users wanted, but because this is the format IAC can best monetize. No wonder users systematically end up disappointed.

By all indications, a huge number of users are running IAC toolbars. The IAC toolbars discussed in this section all send users to mywebsearch.com, a site users are unlikely to visit except if sent there by an IAC toolbar. Alexa reports that mywebsearch.com is the #41 most popular site in the US and #71 worldwide — more popular than Instagram, Flickr, Pandora, and Hulu.

Some of IAC’s browser configuration changes remain in place even if a user removes an IAC toolbar. I installed then uninstalled an IAC Television Fanatic toolbar and received a prompt instructing “Click here for help on resetting your home page and default search settings.” The resulting page specified four different procedures totaling 16 steps — far more lengthy than the initial installation. I can see no proper reason why uninstall is so difficult. Indeed, IAC’s incomplete uninstall specifically violates Google’s October 2012 requirement that “During the uninstall process, users must be presented with a choice that gives them the option of returning their browser’s user settings to the previous settings.” Google’s Software Principles are also on point, instructing that uninstall must be “easy” and must disable “all functions of the application” — whereas IAC’s automated installer does not undo all of IAC’s changes, and IAC’s manual 16-step process is the opposite of “easy.”

The Special Problems of IAC Ask Toolbar Installed by Oracle’s Java Updates

Ongoing Oracle Java updates also install the IAC Ask Toolbar. I discuss these installations in this separate section because they raise concerns somewhat different from the IAC toolbars discussed above. I see five key problems with Oracle Java updates that install IAC toolbars:

First, as Ed Bott noted last week, the “Install the Ask Toolbar” checkbox is prechecked, so users can install the Ask toolbar with a single click on the “Next” button. Accidental installations are particularly likely because the Ask installation prompt is step three of five-screen installation process. When installing myriad software updates, it’s easy to get into a routine of repeatedly clicking Next to finish the process as quickly as possible. But in this case, just clicking Next yields the installation of Ask’s toolbar.

Second, although the Ask installation prompt does not show a “focus” (a highlighted button designated as the default if a user presses enter), the Next button actually has focus. In testing, I found that pressing the enter or spacebar keys has the same effect as clicking “Next.” Thus, a single press of either of the two largest keys on the keyboard, with nothing more, is interpreted as consent to install Ask. That’s much too low a bar — far from the affirmative indication of consent that Google rules and FTC caselaw call for.

Third, in a piece posted today, Ed Bott finds Oracle and IAC intentionally delaying the installation of the Ask Toolbar by fully ten minutes. This delay undermines accountability, especially for sophisticated users. Consider a user who mistakenly clicks Next (or presses enter or spacebar) to install Ask Toolbar, but immediately realizes the mistake and seeks to clean his computer. The natural strategy is to visit Control Panel – Programs and Features to activate the Ask uninstaller. But a user who immediately checks that location will find no listing for the Ask Toolbar: The uninstaller does not appear until the Ask install finishes after the intentional ten minute delay. Of course even sophisticated users have no reason or ability to know about this delay. Instead, a sophisticated user would conclude that he somehow did not install Ask Toolbar after all — and only later will the user notice and, perhaps, proceed with uninstall. Half a decade ago I found WhenU adware engaged in similar intentional delay. Similarly, NYAG litigation documents revealed notorious spyware vendor Direct Revenue intentionally declining to show ads in the first day after its installation. (Direct Revenue staff said this delay would “reduce the correlation between the Morpheus download [which bundled Direct Revenue spyware] and why they are seeing [Direct Revenue’s popup] ads” — confusion that DR staff hoped would “creat[e] less of a path to what they [users] should uninstall.”) Against this backdrop, it’s particularly surprising to see IAC and Oracle adopt this tactic.

Fourth, IAC makes changes beyond the scope of user consent and fails to revert these changes during uninstall. The Oracle/IAC installation solicitation seeks permission to install an add-on for IE, Chrome, and Firefox, but nowhere mentions changing address bar search or the default Chrome search provider. Yet the installer in fact makes all these changes, without ever seeking or receiving user consent. Conversely, uninstall inexplicably fails to restore these settings. As noted above, these incomplete uninstalls violate Google’s Software Principles requirement that an “easy” uninstall must disable “all functions of the application.”

Finally, the Java update is only needed as a result of a serious security flaw in Java. It is troubling to see Oracle profit from this security flaw by using a security update as an opportunity to push users to install extra advertising software. Java’s many security problems make bundled installs all the worse: I’ve received a new Ask installation prompts with each of Java’s many security updates. (Ed Bott counts 11 over the last 18 months.) Even if the user had declined IAC’s offer on half a dozen prior requests, Oracle persists on asking — and a single slip-up, just one click or keystroke on the tenth request, will nonetheless deliver Ask’s toolbar.

A security update should never serve as an opportunity to push additional software. As Oracle knows all too well from its recent security problems, users urgently need software updates to fix serious vulnerabilities. By bundling advertising software with security updates, Oracle teaches users to distrust security updates, deterring users from installing updates from both Oracle and others. Meanwhile, by making the update process slower and more intrusive, Oracle reduces the likelihood that users will successfully patch their computers. Instead, Oracle should make the update process as quick and easy as possible — eliminating unnecessary steps and showing users that security updates are quick and trouble-free.

Toolbar Operations and Result Format

Once a user receives an IAC toolbar, a top-of-browser stripe appears in Internet Explorer and Firefox, and IAC also takes over default search, address bar search, and error handling. That’s an intrusive set of changes, and particularly undesirable in light of the poor quality of IAC’s search results.

If a user runs a search through an IAC toolbar or through a browser search function modified by IAC, the user receives Mywebsearch or Ask.com results page with advertisements and search results syndicated from Google. The volume of advertisements is remarkable: On a 800×600 monitor, the entire first two screens of Mywebsearch results presented advertisements (screen one, screen two) — four large ads with a total of seven additional miniature ads contained within. The first algorithmic search result appears on the third on-screen page, where users are far less likely to see it. At Ask.com, ads are even larger: fully seven advertisements appear above the first algorithmic result, and three more ads appear at page bottom — more than filling two 800×600 screens.

IAC obtains these advertisements and search results from Google, but IAC omits features Google proudly touts in other contexts. For example, Google claims that its maps, hotel reviews, and hotel price quotes benefit users and save users time — but inexplicably IAC Mywebsearch lacks these features, even though these features appear prominently and automatically for users who run the same search at Google. In short, a user viewing IAC results gets listings that are intentionally less useful — designed to serve IAC’s business interest in encouraging the user to click extra advertisements, with much less focus on providing the information that IAC and Google consider most useful.

The ad format at IAC Mywebsearch and Ask.com makes it particularly likely that users will mistake IAC ads for algorithmic results. For one, IAC omits any distinctive background color to help users distinguish ads from algorithmic results. Furthermore, IAC’s voluminous ads exceed beyond the first screen of results for many searches. A user familiar with Google would expect ads to have a distinctive background color and would know that ads typically rarely completely fill a screen — so seeing no such background color and similar-format results continuing for two full screens, the user might well conclude that these are algorithmic listings rather than paid advertisements.

Traffic Arbitrage

IAC buys traffic from Google and other search engines. The resulting sequence is needlessly convoluted: A user runs a search at Google, clicks an IAC ad purporting to offer what the user requested], then receives an IAC landing page with the very same ads just seen at Google. For example, I searched for [800 number look up] at Google and clicked an Ask ad. The resulting Ask page allocated most of its the above-the-fold space to three of the same ads I had just seen at Google! This process provides zero value to the user — indeed, negative value, in that the extra click adds time and confusion. But IAC monetizes its site unusually aggressively — for example, regularly putting four ads at the top of the page, where Google sometimes puts none and never presents more than three. Of course these extra ads serve IAC’s interest: By pushing a fraction of users to click multiple ads, IAC can more than cover its costs of buying the traffic from Google in the first place.

Longstanding Google rules exactly prohibit IAC’s search arbitrage. Google’s AdWords Policy Center instructs that “Google AdWords doesn’t allow the promotion of websites that are designed for the sole or primary purpose of showing ads.” Google continues: “One example of this kind of prohibited behavior is called arbitrage, where advertisers drive traffic to their websites at low cost and pay for that traffic by earning money from the ads placed on those websites”

Why isn’t Google enforcing its rules against arbitrage? An October 2012 Search Engine Land article quotes a reader who wrote to Google AdWords support, where a representative replied with unusual candor: “Since Ask.com is considered a Google product, they are able to serve ads at the top of the page when the search query is found to be relevant to their ads.” Of course Ask.com is not actually “a Google product” — it’s a Google syndicator, showing Google ads in exchange for a revenue share, just like thousands of other sites. But with IAC reportedly Google’s biggest advertising customer, special privileges would be less than surprising. Meanwhile, Google lets IAC do Google’s dirty work — showing extra ads to gullible users — which could let Google collect additional ad revenue from those users’ clicks. Still, that’s no help to users (who get pulled into extra page-views and less useful pages with more advertisements) or advertisers (whose costs increase as a result). And once the public recognizes Google’s role in authorizing this scheme, selling all advertising, and funding the entirety of IAC’s activity, Google ends up looking at least as culpable as IAC.

Ads with Oversized Clickable Areas

IAC’s ads also flout industry practice and Google rules as to the size of an ad’s clickable area. Both in arbitrage landing pages and in toolbar results, IAC’s search result pages expand the clickable area of each advertisement to fill the entire page width, sharply increasing the fraction of the page where a click will be interpreted as a request to visit the advertiser’s page.

See the screenshot at right. (To create the red-outlined box showing the shape of the clickable area, I clicked an empty section of the ad and began a brief drag, causing my browser to highlight the ad’s clickable area in red as shown in the screenshot.)

Ask is an outlier in converting whitespace around an ad into a clickable area. Every other link on Ask.com landing pages — every link other than an advertisement — follows standard industry practice with only the words of the link being clickable, but not the surrounding whitespace. Indeed, at Google, Bing, and Yahoo, white space is never clickable. At Google and Bing, only ad titles are clickable, not ad domain names, or ad text. (See Google screenshot at right, showing the limited clickable area of a Google ad.) At Yahoo, only ad titles and domain names are clickable, not ad text or white space.

IAC has taken intentional action to expand its ads’ clickable area to cover all available width. As W3schools explains, “A block element is an element that takes up the full width available.” To expand ad hyperlinks to fill the entire width, Ask tags each ad hyperlink with the CSS STYLE of display:block.

<a id=”lindp” class=”ptbs pl20 pr30 ptsp pxl” style=”display:block;padding-bottom: 0px;” …

Google’s rules prohibit IAC’s expanded clickable areas. Google requires that “clicking on space surrounding an ad should not click the ad.” Yet IAC nonetheless makes a clickable area out of the area surrounding each ad, extending all the way to the right column.

IAC’s expanded ads invite accidental clicks. Accidental clicks are particularly likely from the inexperienced users IAC systematically targets for toolbar installations, and also from users searching on tablets, phones, and other touch devices. These extra clicks waste users’ time and drive up advertisers’ costs — but every such click yields extra revenue for IAC and Google.

What Comes Next

Google should enforce its rules strictly. No doubt IAC can offer Google some short-term revenue via extra ad-clicks from unsophisticated or confused users. But this isn’t the kind of business Google aspires to, and Google’s public statements indicate no interest in such bottom-feeding. Indeed, a fair application of Google’s existing AdWords rules would disallow both IAC’s toolbar ads (using AdWords to solicit installations) and IAC’s search arbitrage ads (using AdWords to send users to IAC pages presenting syndicated AdWords ads). Meanwhile, numerous Google AdSense rules are also on point, including prohibiting encouraging accidental clicks, prohibiting site layout that pushes content below the fold, and limiting the number of ads per page. So too for Software Principles requiring up-front disclosure as well as “easy” and complete uninstall.

As a publicly-traded company, IAC should benefit from the oversight and guidance of its outside directors. But the New York Times commented in 2011 that “IAC’s board is filled with high-powered friends of Mr. Diller,” calling into question the independence and effectiveness of IAC’s outside directors. Of particular note is Chelsea Clinton, who joined IAC’s board in September 2011. Ms. Clinton’s prior experience includes little obvious connection to Internet advertising or online business, suggesting that she might need to invest extra time to learn the details of IAC’s business. Yet she also has weighty commitments including ongoing doctoral studies, serving as an Assistant Vice Provost at NYU, and reporting as a special correspondent for the NBC Nightly News — calling into question the time she can devote to IAC matters. The Times questioned why IAC had brought in Ms. Clinton, concluding that “This is clearly an appointment made because of who she is, not what she has done.” Indeed, Ms. Clinton’s background means she will be held to a particularly high standard: if she fails to stop IAC’s bad practices, the public may reasonably ask whether she has done her duty as an outside director.

Recent research from Goldman analyst Heath Terry flags investor concerns at IAC’s tactics. In a December 4, 2012 report, Terry downgraded IAC to sell due to vulnerability from Google policy changes. A January 9, 2013 follow-up noted IAC changing its uninstall practices to comply with Google policy as well as slowdown in arbitrage. Terry flags some important factors, and I share his bottom line that IAC’s search practices are unsustainable. But the real shoe has yet to drop. If Google is embarrassed at IAC’s actions — and it should be — Google is easily able to put an end to this mess.

I prepared a portion of this article at the request of a client that prefers not to be listed by name. The client kindly agreed to let me include that research in this publicly-available posting.

Run the Google Toolbar, and it’s strikingly easy to activate “Enhanced Features” — transmitting to Google the full URL of every page-view, including searches at competing search engines. Some critics find this a significant privacy intrusion (1, 2, 3). But in my testing, even Google’s bundled toolbar installations provides some modicum of notice before installing. And users who want to disable such transmissions can always turn them off – or so I thought until I recently retested.

In this article, I provide evidence calling into question the ability of users to disable Google Toolbar transmissions. I begin by reviewing the contents of Google’s "Enhanced Features" transmissions. I then offer screenshot and video proof showing that even when users specifically instruct that the Google Toolbar be “disable[d]”, and even when the Google Toolbar seems to be disabled (e.g., because it disappears from view), Google Toolbar continues tracking users’ browsing. I then revisit how Google Toolbar’s Enhanced Features get turned on in the first place – noting the striking ease of activating Enhanced Features, and the remarkable absence of a button or option to disable Enhanced Features once they are turned on. I criticize the fact that Google’s disclosures have worsened over time, and I conclude by identifying changes necessary to fulfill users’ expectations and protect users’ privacy.

"Enhanced Features" Transmissions Track Page-Views and Search Terms

Certain Google Toolbar features require transmitting to Google servers the full URLs users browse. For example, to tell users the PageRank of the pages they browse, the Google Toolbar must send Google servers the URL of each such page. Google Toolbar’s “Related Sites” and “Sidewiki” (user comments) features also require similar transmissions.

With a network monitor, I confirmed that these transmissions include the full URLs users visit – including domain names, directories, filenames, URL parameters, and search terms. For example, I observed the transmission below when I searched Yahoo (green highlighting) for "laptops" (yellow).

GET /search?client=navclient-auto&swwk=358&iqrn=zuk&orig=0gs08&ie=UTF-8&oe=UTF-8&querytime=kV&querytimec=kV &features=Rank:SW:&q=info:http%3a%2f%2frds.yahoo.com%2f_ylt%3dA0oGkl32p1tLT2EB8ohXNyoA%2fSIG%3d18045klhr%2f
EXP%3d1264384374%2f**http%253a%2f%2fsearch.yahoo.com%2fsearch%253fp%3dlaptops%2526fr%3dsfp%2526xargs%3d12KP
jg1itSroGmmvmnEOOIMLrcmUsOkZ7Fo5h7DOV5CtdY6hNdE%25252DIfXpP0xZg6WO8T7xvSy7HBreVFdJGu277WVk0qfeG%25255FGOW%2
5255F772GnNVme5ujWkF3s%25252DJ%25255F0%25252Dmdn4RvDE8%25252E%2526pstart%3d7%2526b%3d11&googleip=O;72.14.20
4.104;226&ch=711984234986 HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; GoogleToolbar 6.4.1208.1530; Windows XP 5.1; MSIE 8.0.6001.18702)
Accept-Language: en
Host: toolbarqueries.google.com
Connection: Keep-Alive
Cache-Control: no-cache
Cookie: PREF=ID=…

HTTP/1.1 200 OK …

Screenshots – Google Toolbar Continues Tracking Browsing Even When Users "Disable" the Toolbar via Its "X" Button

Consistent with modern browser plug-in standards, the current Google Toolbar features an “X” button to disable the toolbar:

I clicked the “X” and received a confirmation window:

I chose the top option and pressed OK. The Google Toolbar disappeared from view, indicating that it was disabled for this window, just as I had requested. Within the same window, I requested the Whitehouse.gov site:

Although I had asked that the Google Toolbar be "disable[d] … for this window " and although the Google Toolbar disappeared from view, my network monitor revealed that Google Toolbar continued to transmit my browsing to its toolbarqueries.google.com server:

See also a screen-capture video memorializing these transmissions.

These Nonconsensual Transmissions Affect Important, Routine Scenarios (added 1/26/10, 12:15pm)

In a statement to Search Engine Land, Google argued that the problems I reported are "only an issue until a user restarts the browser." I emphatically disagree.

Consider the nonconsensual transmission detailed in the preceding section: A user presses "x", is asked "When do you want to disable Google Toolbar and its features?", and chooses the default option, to "Disable Google Toolbar only for this window." The entire purpose of this option is to take effect immediately. Indeed, it would be nonsense for this option to take effect only upon a browser restart: Once the user restarts the browser, the "for this window" disabling is supposed to end, and transmissions are supposed to resume. So Google Toolbar transmits web browsing before the restart, and after the restart too. I stand by my conclusion: The "Disable Google Toolbar only for this window" option doesn’t work at all: It does not actually disable Google Toolbar for the specified window, not immediately and not upon a restart.

Crucially, these nonconsensual transmissions target users who are specifically concerned about privacy. A user who requests that Google Toolbar be disabled for the current window is exactly seeking to do something sensitive, confidential, or embarrassing, or in any event something he does not wish to record in Google’s logs. This privacy-conscious user deserves extra privacy protection. Yet Google nonetheless records his browsing. Google fails this user — specifically and unambiguously promising to immediately stop tracking when the user so instructs, but in fact continuing tracking unabated.

Google Toolbar Continues Tracking Browsing Even When Users "Disable" the Toolbar via "Manage Add-Ons"

Internet Explorer 8 includes a Manage Add-Ons screen to disable unwanted add-ons. On a PC with Google Toolbar, I activated Manage Add-Ons, clicked the Google Toolbar entry, and chose Disable. I accepted all defaults and closed the dialog box.

Again I requested the whitehouse.gov site. Again my network monitor revealed that Google Toolbar continued to transmit my browsing to its toolbarqueries.google.com server. Indeed, as I requested various pages on the whitehouse.gov site, Google Toolbar transmitted the full URLs of those pages, as shown in the second and third circles below.

See also a screen-capture video memorializing these transmissions.

In a further test, performed January 23, I reconfirmed the observations detailed here. In that test, I demonstrated that even checking the "Google Toolbar Notifier BHO" box and disabling that component does not impede these Google Toolbar transmissions. I also specififically confirmed that these continuing Google Toolbar transmissions track users’ searches at competing search engines. See screen-capture video.

In my tests, in this Manage Add-Ons scenario, Google Toolbar transmissions cease upon the next browser restart. But no on-screen message alerts the user to the need for a browser-restart for changes to take effect, so the user has no reason to think a restart is required.

Google Toolbar Continues Tracking Browsing When Users "Disable" the Toolbar via Right Click (added 1/26/10 11:00pm)

Danny Sullivan asked me whether Google Toolbar continues Enhanced Features transmissions if users hide Google Toolbar via IE’s right-click menu. In a further test, I confirmed that Google Toolbar transmissions continue in these circumstances. Below are the four key screenshots: 1) I right-click in empty toolbar space, and I uncheck Google Toolbar. 2) I check the final checkbox and choose Disable. 3) Google Toolbar disappears from view and appears to be disabled. I browse the web. 4) I confirm that Google Toolbar’s transmissions nonetheless continue. See also a screen-capture video.

Users May Easily or Accidentally Activate “Enhanced Features” Transmissions

The above-described transmissions occur only if a user runs Google Toolbar in its “Enhanced Features” mode. But it is strikingly easy for a user to stumble into this mode.

For one, the standard Google Toolbar installation encourages users to activate Enhanced Features via a “bubble” message shown at the conclusion of installation. See the screenshot at right. This bubble presents a forceful request for users to activate Sidewiki: The feature is described as “enhanced” and “helpful”, and Google chooses to tout it with a prominence that indicates Google views the feature as important. Moreover, the accept button features bold type plus a jumbo size (more than twice as large as the button to decline). And the accept button has the focus – so merely pressing Space or Enter (easy to do accidentally) serves to activate Enhanced Features without any further confirmation.

I credit that the bubble mentions the important privacy consequence of enabling Enhanced Features: “For enhanced features to work, Toolbar has to tell us what site you’re visiting by sending Google the URL.” But this disclosure falls importantly short. For one, Enhanced Features transmits not just “sites” but specific full URLs, including directories, filenames, URL parameters, and search keywords. Indeed, Google’s bubble statement is internally-inconsistent – indicating transmissions of “sites” and “URLs” as if those are the same thing, when in fact the latter is far more intrusive than the former, and the latter is accurate.

The bubble also falls short in its presentation of Google Toolbar’s Privacy Policy. If a user clicks the Privacy Policy hyperlink, the user receives the image shown in the left image below. Notice that the Privacy Policy loads in an unusual window with no browser chrome – no Edit-Find option to let a user search for words of particular interest, no Edit-Select All and Edit-Copy option to let a user copy text to another program for further review, no Save or Print options to let a user preserve the file. Had Google used a standard browser window, all these features would have been available, but by designing this nonstandard window, Google creates all these limitations. The substance of the document is also inapt. For one, “Enhanced Toolbar Features” receive no mention whatsoever until the fifth on-screen page (right image below). Even there, the first bullet describes transmission of “the addresses [of] the sites” users visit – again falsely indicating transmission of mere domain names, not full URLs. The second bullet mentions transmission of “URL[s]” but says such transmission occurs “[w]hen you use Sidewiki to write, edit, or rate an entry.” Taken together, these two bullets falsely indicate that URLs are transmitted only when users interact with Sidewiki, and that only sites are transmitted otherwise, when in fact URLs are transmitted whenever Enhanced Features are turned on.

Clicking the ‘Privacy Policy’ link yields this display. Note the lack of browser chrome — no options to search text, copy to the clipboard, save, or print. Note also the absence of any on-screen mention of the special privacy concerns presented by Enhanced Features.

The first discussion of Enhanced Features appears five pages down. Furthermore, the text falsely indicates that ordinary transmission covers mere domain names, not full URLs. The text says "URL[s]" are transmitted "when you use Sidewiki" and indicates that URLs are not transmitted otherwise.

Certain bundled installations make it even easier for users to get Google Toolbar unrequested, and to end up with Enhanced Features too. With dozens of Google Toolbar partners, using varying installation tactics, a full review of their practices is beyond the scope of this article. But they provide significant additional cause for concern.

Enhanced Features: Easy to Enable, Hard to Turn Off

The preceding sections shows that users can enable Google Toolbar’s Enhanced Features with a single click on a prominent, oversized button. But disabling Enhanced Features is much harder.

Consider a user who changes her mind about Enhanced Features but wishes to keep Google Toolbar in its basic mode. How exactly can she do so? Browsing the Google Toolbar’s entire Options screen, I found no option to disable Enhanced Features. Indeed, Enhanced Features are easily enabled with a single click, during installation (as shown above) or thereafter. But disabling Enhanced Features seems to require uninstalling Google Toolbar altogether, and in any event disabling Enhanced Features certainly lacks any comparably-quick command.

I’m reminded of The Eagles’ Hotel California: "you can check out anytime you like, but you can never leave." And of course, as discussed above, a user who chooses the X button or Manage Add-Ons, will naturally believe the Google Toolbar is disabled, when in fact it continues transmissions unabated.

Google Toolbar Disclosures Have Worsened Over Time

I first wrote about Google Toolbar’s installation and privacy disclosures in my March 2004 FTC comments on spyware and adware. In that document, I praised Google’s then-current toolbar installation sequence, which featured the impressive screen shown at right.

I praised this screen with the following discussion:

I consider this disclosure particularly laudable because it features the following characteristics: It discusses privacy concerns on a screen dedicated to this topic, separate from unrelated information and separate from information that may be of lesser concern to users. It uses color and layout to signal the importance of the information presented. It uses plain language, simple sentences, and brief paragraphs. It offers the user an opportunity to opt out of the transmission of sensitive information, without losing any more functionality than necessary (given design constraints), and without suffering penalties of any kind (e.g. forfeiture of use of some unrelated software). As a result of these characteristics, users viewing this screen have the opportunity to make a meaningful, informed choice as to whether or not to enable the Enhanced Features of the Google Toolbar.

I stand by that praise. But six years later, Google Toolbar’s installation sequence is inferior in every way:

• Now, initial Enhanced Features privacy disclosures appear not in their own screen, but in a bubble pitching another feature (Sidewiki). Previously, format (all-caps, top-of-page), color (red) and language ("… not the usual yada yada") alerted users to the seriousness of the decision at hand.
• Now, Google presents Enhanced Features as a default with an oversized button, bold type, and acceptance via a single keystroke. Previously, neither option was a default, and both options were presented with equal prominence.
• Now, privacy statements are imprecise and internally-inconsistent, muddling the concepts of site and URL. Previous disclosures were clear in explaining that acceptance entails "sending us [Google] the URL" of each page a user visits.
• The current feature name, "Enhanced Features," is less forthright than the prior "Advanced Features" label. The name "Advanced Features" appropriately indicated that the feature is not appropriate for all users (but is intended for, e.g., "advanced" users). In contrast, the current "Enhanced Features" name suggests that the feature is an "enhancement" suitable for everyone.

Google’s Undisclosed Taskbar Button

The Google Toolbar also added a “Google” button to my Taskbar, immediately adjacent to the Start button. The Toolbar installer added this button without any disclosure whatsoever in the installation sequence – not on the toolbar.google.com web page, not in the installer EXE, not anywhere else.

An in-Taskbar button is not consistent with ordinary functions users reasonably expect when they seek and install a “toolbar.” Because this function arrives on a user’s computer without notice and without consent, it is an improper intrusion.

What Google Should Do

Google’s first step is simple: Fix the Toolbar so that X and Manage Add-Ons in fact do what they promise. When a user disables Google Toolbar, all Enhanced Features transmissions need to stop, immediately and without exception. This change must be deployed to all Google Toolbar users straightaway.

Google also needs to clean up the results of its nonconsensual data collection. In particular, Google has collected browsing data from users who specifically declined to allow such data to be collected. In some instances this data may be private, sensitive, or embarrassing: Savvy users would naturally choose to disable Google Toolbar before their most sensitive searches. Google ordinarily doesn’t let users delete their records as stored on Google servers. But these records never should have been sent to Google in the first place. So Google should find a way to let concerned users request that Google fully and irreversibly delete their entire Toolbar histories.

Even when Google fixes these nonconsensual transmissions, larger problems remain. The current Toolbar installation sequence suffers inconsistent statements of privacy consequences, with poor presentation of the full Toolbar Privacy Statement. Toolbar adds a button to users’ Taskbar unrequested. And as my videos show, once Google puts its code on a user’s computer, there’s nothing to stop Google from tracking users even after users specifically decline. I’ve run Google Toolbar for nearly a decade, but this week I uninstalled Google Toolbar from all my PCs. I encourage others to do the same.

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.

In today’s post, I report notable current Ask practices. I show Ask ads running on kids sites and in various noxious spyware, specifically contrary to Ask’s prior promises. I document yet another installation of Ask’s toolbar that occurs without user notice or consent. I point out why Ask’s toolbar is inherently objectionable — especially its rearrangement of users’ browsers and its excessive pay-per-click ads to the effective exclusion of ordinary organic links. I compare Ask’s practices with its staff’s promises and with governing law — especially “deceptive door opener” FTC precedent, prohibiting misleading initial statements even where clarified by subsequent statements.

Details:

Current Practices of IAC/Ask Toolbars

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 that’s not the worst of AJ’s practices. Over the past six months, I’ve captured a series of videos showing Ask Jeeves’ MyWay and MySearch software installed through security holes — without notice, disclosure, or consent. For example, in a video I made on March 12, I received more than a dozen different programs including the Ask Jeeves MySearch toolbar — without me ever requesting anything, and without me ever clicking “Yes” or “Accept” in any dialog box. Watch the video and see for yourself. Warning: The video is 16+ minutes long. Security exploit occurs at 6:00, and Ask Jeeves MySearch software is first seen at 15:50. In this same testing, I also received installation of 180solutions, multiple programs from eXact Advertising, the IBIS WebSearch toolbar, PeopleOnPage, ShopAtHomeSelect, SurfSideKick, WindUpdates, and many more. The underlying network transmissions show that the security exploit at issue was syndicated through the targetnet.com ad network — Mamma Media, publicly-traded on Nasdaq Small Cap.

I have other videos available upon request, including nonconsensual AJ installations dating back to November 2004. See also my November 2004 exploit video.

I’m surprised that Ask Jeeves allows these nonconsensual installations. Ask Jeeves is a publicly-traded company with a 10-digit valuation (slated to be acquired by InterActiveCorp for $1.85 billion). If Ask Jeeves staff made a serious effort to screen and supervise their distribution partners, they could prevent this kind of mess.

The biggest news last week was a lawsuit filed by the New York Attorney General’s office against Intermix Media, whose KeenValue, IncrediFind, and other programs show popup ads, add extra browser toolbars, and intercept error messages. These practices are objectionable in and of themselves, but the complaint focuses on the programs’ misleading installations. Sometimes the programs install with no notice at all, the complaint says, and sometimes only with hidden or misleading disclosures users are unlikely to notice or understand.

I have the sense that this suit is the first of many. There are certainly plenty of similar offenders, even big companies with major venture capital funding. I have often written about software from 180solutions, Direct Revenue, and eXact Advertising installing through security holes, practices I’ve continued to observe (including in the video linked above). And Claria’s tricky installations share many of the deceptive characteristics the AG attributes to Intermix, like hiding key terms in “lengthy, legalistic license agreements” and using “vague, incomplete” disclosure text. (See NYAG complaint (PDF), paragraph 9.) So I doubt the NY AG’s office would approve of the Ask Jeeves practices I’m documenting today, nor the other misleading tactics on my spyware installation methods index.