and TRUSTe: Lots of Talk, Too Little Action updated March 20, 2008

Six and a half months ago, I reported a variety of bad practices at Key among my concerns: stored data in deceptive filenames and registry entries designed to look like part of Windows — with names like c:\WINDOWS\WindowsShellOld.Manifest.1 and HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Controls Folder\Presentation Style. Furthermore, failed to remove these files upon a user’s specific request to uninstall.

Because was certified by TRUSTe Trusted Download, I reported these behaviors through TRUSTe’s Watchdog form. TRUSTe investigated and, it claimed, required to make changes. Last month, TRUSTe declared success: "Coupons, Inc. rolled out a number of significant changes …. To improve registry key and naming (s.i.c.), the new version of the software uses an improved security scheme that writes only one registry key placed in a typical location, named in an appropriate manner." TRUSTe concluded by giving itself a pat on the back — calling this sequence "an excellent outcome" in that "[a] user found a problem, filed a complaint, and TRUSTe worked with the Participant to make necessary corrections."

I wanted to see for myself whether TRUSTe’s oversight is as effective as TRUSTe claims. So I downloaded’s current software onto an ordinary computer in my lab. (I couldn’t use a VMware virtual machine because detects VMware and refuses to install.) To my dismay,’s software continued to create the same deceptively-named files and registry keys I reported in August:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Controls Folder\Presentation Style
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\UrlDecoding

I prepared a screen-capture video to confirm and memorialize the deceptively-named files and registry keys. (My video begins by showing the New York Times front page, to demonstrate the date of testing.)

I then used Control Panel – Add/Remove Programs to attempt to uninstall’s software. I found that the specified files and registry keys all remained in place — even though TRUSTe further promised that "[t]he new version uninstaller removes the files."

What’s going on? Maybe TRUSTe tested a different version of’s software than the version offered to the public. Maybe posted the wrong file. But whatever the reason, TRUSTe’s claims are inconsistent with my test results.

TRUSTe’s Oversight and What to Do Next

My testing indicates that has not made the changes TRUSTe specified. In particular, continues to use multiple registry keys and filenames with intentionally deceptive locations and names — exactly contrary to TRUSTe’s claim that "only one registry key" is used and that it is placed in a "typical location" with an "appropriate" name. Furthermore, leaves these files and registry keys after uninstall — exactly contrary to TRUSTe’s claim that the new uninstaller "removes the files left behind."

Far from TRUSTe’s self-congratulatory rhetoric,’s practices reflect badly on TRUSTe: Despite clear violations widely reported 6+ months ago and a supposed investigation by TRUSTe, the problems continue to this day.

Worse, through two different channels, TRUSTe has falsely told users they can trust First, has continuously remained on TRUSTe’s Trusted Download "whitelist" despite my initial report. That is, TRUSTe continued to certify even when TRUSTe knew of’s deceptive practices and even when there was no dispute that the practices were ongoing. A better strategy, per my September 2007 recommendation, would be to suspend violators until they have fully corrected their practices. Otherwise, a user looking at the "whitelist" cannot know which companies are truly in good standing, versus which have fallen short and are must make improvements.

Second, TRUSTe has posted announcements (1, 2) that falsely characterize the status of’s improvements: In September TRUSTe promised the changes would be "completed within 90 days" — but in fact, they’re still not in place 180 days later. In February TRUSTe proclaimed the changes complete — but in fact’s software still has the same problems I previously identified.

These failings go to the core of TRUSTe’s promise to "make privacy your choice." TRUSTe claims to be giving users the information they need to make informed decisions. However, TRUSTe’s information is systematically in error — to the benefit of the companies that pay TRUSTe to get certified, but to the detriment of any users who mistakenly rely on TRUSTe’s investigations.

An Additional Violation: Executable Software Left Behind After Uninstall

My recent tests also revealed a new file I hadn’t noticed in prior tests: c:\WINDOWS\system32\cpnprt2.cid. How did I miss this file? It appears only after a user first prints a coupon — not when a user initially installs software. So this file wasn’t created in my prior testing.

Despite the file’s unusual .CID extension, the file is actually a DLL containing executable code. Although "cpnprt" bears some relationship to’s product name ("CouPoN PRinTer"), I can see no proper reason to place this file within c:\WINDOWS\ rather than in c:Program Files\Coupons with’s other files. So’s improper file locations include not only data files (like those listed above), but also executable code.

Moreover, I see no proper reason for calling the file a .CID rather than the DLL that it is. This misnaming serves to further obfuscate the file’s purpose and to prevent typical users from determining that the file contains executable software code.

In separate testing, I confirmed that this file remains on a user’s computer even after the user removes’s software. (This too is shown in my screen-capture video.) So leaves behind not just data, but also executable software. Leaving executable code stands starkly in contrast to’s license agreement which mentions only that "license keys wil not be removed when the Software is uninstalled" — but says nothing about software code left behind. violates TRUSTe Trusted Download requirements when it leaves executable code after a user’s uninstall request. Trusted Download rule 7.(a)(ii) requires a complete uninstall and allows only limited exceptions — none of them applicable here. (The closest exception allows "properly disclosed anti-fraud … measures" — but this practice is not "properly disclosed," nor is surviving executable code required to track whatever practices might conceivably be at issue.)’s cpnprt2.cid file therefore constitues another violation of applicable Trusted Download rules.’s Ongoing DMCA Litigation with John Stottlemire

Last summer I mentioned’s misguided DMCA litigation against John Stottlemire. The case drags on: John’s blog reports ongoing events, including John’s motion to dismiss, the court’s granting of that motion,’s second amended complaint, and John’s second motion to dismiss.

My view remains that this litigation is ill-advised for has too much work to do, improving its own software and its own business practices, to waste management time and attention on pursuing a user who merely helped others remove deceptively-named files and registry keys. has nothing to gain here: Even if can force John to stop telling users how to remove unwanted software, others will immediately pick up where John left off.

There’s plenty more to be said about the case — especially, concern at using the DMCA to stifle useful public-interest discussion of how to remove unwanted software from an ailing computer. But I’ll leave that to others: TechDirt, Wired, and various bloggers.

Update (March 20, 2008)

TRUSTe’s Response and My Hands-On Testing

In a March 19 posting, TRUSTe claims that the issues described above reflected software available only between March 15 and March 17. But TRUSTe stands behind its February report that had "addressed [the] concerns" TRUSTe previously raised based on my prior article. I emphatically disagree. In particular, my hands-on testing, memorialized in video records, clearly demonstrates that continues to violate TRUSTe’s prior instructions and applicable TRUSTe rules. Consider my March 19 video:

1. At 0:02, I demonstrate the current date and time. I then run an InCtrl scan to record existing files and registry keys.

2. At 1:15, I begin to browse the site, and at 1:25 I attempt to print a coupon. 

3. At 1:33, I begin to install the Coupon Printer program, including providing a name and email address when requested (2:20). 

4. At 2:55, I browse c:\WINDOWS\ to show the newly-created and deceptively-named CID file (as discussed above).  I then proceed to find a file by the same name placed in c:\WINDOWS\system32 also.

5. At 3:30, I rerun Inctrl to identify newly created files and registry keys.  The results are visible beginning at 5:35.  I notice the HKEY_CLASSES_ROOT\English.cpl registry key in the listing (5:45), and at 5:50 I use Regedit to confirm that the key is indeed present. 

6. At 6:30, I request an uninstall in the usual way (Control Panel – Add or Remove Programs).  I then show that deceptively named file remains in c:\WINDOWS\ (7:14) and c:\WINDOWS\system32 (7:08); despite my uninstall request, these files were not removed.  I show that the deceptively-named registry key remains also (7:02). 

The Violations Revealed by My Hands-On Testing

The preceding video presents three separate different violations of TRUSTe rules and of TRUSTe’s prior representations of’s supposed compliance:

A) Step 4 shows a deceptively-named file placed on a user’s computer. There is no proper reason to call this file a .CID rather than the DLL that it is. Nor is there any proper reason for to place the same file in both c:\WINDOWS\ and c:\WINDOWS\system32. Indeed, my tests indicate that sometimes uses one of those folders, sometimes the other, and sometimes both — a randomization procedure with no proper purpose, but with the natural effect of confusing users and hindering detection and removal.

These deceptive filenames are exactly contrary to TRUSTe’s claim that it has resolved the problem of’s “inappropriately-named files.” These deceptive filenames and randomized locations also violate TRUSTe rule 14(e)(v), which prohibits "using randomized or intentionally deceptive file names … for the purpose of avoiding detection and removal."

B) Step 5 shows a deceptively-named registry key. Coupons is not, and is not commonly known as, "English.cpl." Indeed, the file extension "CPL" indicates a Control Panel applet or extension — but offers no such extension. Neither does have any proper basis to place its configuration data in HKCR — a registry area reserved for file extensions and COM class registrations. Rather, clearly chooses this area to store its configuration data because users would never think to look here. Indeed, in repeated testing, I found that sometimes used other keys instead. For example, in a separate video early on March 19, I found that used HKCRWeb.Template.URL rather than HKCREnglish.cpl. Randomization of registry keys further confirms that uses these registry locations to avoid detection.

These randomized and intentionally-deceptive registry keys are exactly contrary to TRUSTe’s claim that all registry keys are “placed in a typical location [and] named in an appropriate manner.” These deceptive filenames and randomized locations also violate TRUSTe rule 14(e)(v), which prohibits "using randomized or intentionally deceptive … registry entries for the purpose of avoiding detection and removal."

C) Step 6 shows that fails to remove all its files and registry keys upon a user’s specific request to uninstall.

The retention of these files is exactly contrary to TRUSTe’s claim that the “new version uninstaller removes the files left behind.” The retention of these files also violates TRUSTe rule 7.(a)(ii), requiring a complete uninstall and allows only limited exceptions — none of them applicable here.

The retention of these files also violates’s license agreement — which mentions only that “license keys will not be removed when the Software is uninstalled,” but says nothing about software code left behind. Although TRUSTe’s Trusted Download rules do not specifically require that a company comply with the provisions of its license agreement, I take such compliance to be so obvious that it does not require a specific mention.’s violation of representations in its own license agreement therefore constitutes yet another violation of TRUSTe requirements.

Additional Violations: Retrieving Windows CD key and system serial numbers

In testing using API and registry-monitoring tools, I have determined that retrieves a wide variety of sensitive Windows registry keys and computer configuration settings including Windows Product ID, Windows CD key, motherboard serial number, and hard drive serial number. These numbers serve to identify a specific individual computer, and these numbers persist over the lifetime of a computer. These practices stand in sharp contrast to’s representations to users:

  • The "promo" promises that "The Coupon Printer does not gather or ask for any personal information about … your computer." Yet my testing indicates that gathers detailed computer-specific information about each computer on which it is installed.
  •’s privacy policy similarly promises that "The Coupons, Inc. software … only collect[s] information about what coupons have been printed and redeemed from your computer" — again, directly at odds with my observation that collects far more information.
  •’s license agreement discloses this information collection only by admitting that the "software uses anonymous, assigned numbers and/or anonymous information about your computer or device." But the numbers at issue are not anonymous: These numbers identify a specific individual user based on the user’s unique and unvarying Windows CD key, motherboard serial number, and hard drive serial number. TRUSTe rule 1.qq defines such information to be pseudonymous ("information that may correspond to a person [such as] machine ID"), while rule 1.i defines anonymous information to exclude all pseudonymous information. thus errs in characterizing these numbers as "anonymous." Moreover, errs in disclosing this data collection practice only in its license agreement; because this practice speaks to user privacy, it belongs in’s privacy policy.

TRUSTe’s Ineffective Investigation and Response

TRUSTe staff could have identified each of these defects when they tested software in February. Instead, TRUSTe staff issued a boilerplate endorsement — failing to identify shortcomings that would have been apparent in any careful analysis.

Remarkably, even after my post above and even after John Stottlemire’s March 18 post detailing many of these issues in great detail, TRUSTe nonetheless described’s problems as "corrected." TRUSTe even called this process "a good example of how the [Trusted Download] program should work." I emphatically disagree: remains flagrantly in violation of TRUSTe’s instructions and rules, and TRUSTe has failed either to obtain suitable corrections or to eject from its whitelist.

To this day, is in breach of TRUSTe’s rules, and TRUSTe knows it. Yet remains listed on TRUSTe’s whitelist as if its practices are beyond reproach and as if the company is in good standing vis-a-vis TRUSTe’s rules. That’s outrageous, and users should demand better.