On "PattyMail" disclosure, ZDNet to lead by example

As cliche as it sounds, my father always impressed upon me that actions speak louder than words. So, this is a blog post about the transparent action that ZDNet is willing to take in the name of both Internet and privacy advancement.
Written by David Berlind, Inactive

As cliche as it sounds, my father always impressed upon me that actions speak louder than words. So, this is a blog post about the transparent action that ZDNet is willing to take in the name of both Internet and privacy advancement.

Last Friday, I posted two blogs regarding the notion that PattyMail (the kind of trackable/traceable HTML-based e-mail that HP used to smoke out whoever was leaking sensitive information) might be spyware. The first of these (see Was HP's PattyMail Spyware? You decide) simply questioned whether the traceable nature of PattyMail qualifies it as spyware. During last week's Congressional hearing in Washington, D.C. regarding a privacy scandal that has rocked HP's executive offices to their core, at least one Congressman referred to an e-mail containing falsified product information  that was sent to News.com's Dawn Kawamoto as such. In a second post (see TRUSTe: Intent qualifies HP's bugged PattyMail as spyware), TRUSTe.org executive director Fran Maier goes on record as saying that the e-mail in question may not have technically satisfied the accepted definition of spyware, but that its deceitful nature essentially takes precedence over any technicalities, thus qualifying it as spyware.

As such, the incident raises some important questions regarding what should and shouldn't be disclosed to recipients of HTML-based e-mail when that e-mail as been enabled with traceable elements that allow the sender to glean certain information about those recipients. More than likely (I haven't done a survey), most e-mail users don't distinguish between text, rich text, or HTML-based email, nor do they realize that, by opening HTML-based email, that the sender can learn certain things about them. For example, their IP addresses and the date and time at which a particular e-mail was opened. In my interview with TRUSTe's Maier, she noted that this sort of tracing is becoming more of a concern to her and other privacy advocacy organizations as more and more people moved to fixed IP addresses (from which identities can easily be determined through database cross-querying).

When someone or some organization sends "PattyMails" that include traceable elements in them, should they disclose the usage of those traceable elements without forcing the recipients to visit a privacy policy on the sender's Web site (that, by itself, a trackable event)? My personal feeling on the issue is why not? If the sender has nothing to hide and is certain that the information included in the e-mail is of real value to the recipient(s), then there shouldn't be any harm in disclosing the degree to which "surveillance" has been enabled in the e-mail. But, to the extent that we here at ZDNet have enabled the HTML-versions of our Tech Update e-mail newsletters for tracking, it would be hypocritical of me to  speak up about such lack of disclosure as long as our own HTML newsletters don't set the example.  

So, I pinged CNET Business Portfolio vice president Stephen Howard-Sarin (the ultimate decision maker on such issues) to find out if he'd approve the insertion of a disclosure into to the daily and weekly versions of ZDNet's Tech Update newsletters (the two newsletters that I share responsibility for) that indicates the inclusion of trackable elements. The short answer, thankfully, was yes. But just as important, the phone call included a discussion of what we do to enable tracking in our newsletters, what data we gather, and what we do with that data. This, in many ways, gets to the intent issue discussed with TRUSTe's Fran Maier

According to Howard-Sarin, ZDNet's HTML-based newsletters are enabled for tracking using a technique known as a clear gif file. To the extent that graphically-oriented Web pages and HTML-based e-mails rely on GIF, JPG, or PNG formatted image files, clear gifs are unobstrusive GIF-based images that are typically hidden from view to the naked eye in the final presentation (the HTML page or email).  Nevertheless, in order for your browser or e-mail client to include that clear GIF when a page or e-mail is finished displaying on your screen, it must retrieve the associated file from our servers. Provided you've enabled your e-mail client to view e-mail borne graphics (in Outlook for example, this can be done on a global, by recipient, or on an per e-mail basis), the act of opening an e-mail is what triggers the retrieval of the clear GIF's file from our servers (as well as any other images that are on the page).

Unless you've gone to special lengths to "anonymize" or cloak your connection to the Internet, each time your computer connects to our servers to retrieve text or images (be it the clear GIF file or not), there's a certain amount of information that can be extracted from that connection. For example, the IP address of your computer and the time you connected.  But, as far as our newsletter is concerned, you can throw away any conspiracy theories.  According to Howard-Sarin, we're basically just incrementing a counter:

That number tells us what percentage of the audience is opening each edition of each newsletter. It helps to understand if our subject lines are well written and if the newsletter has strong or weak appeal. And if an individual account doesn't open its email for a number of months, we notice that too and we stop sending them the newsletter.

The implication of that last bit about cancelling sends is that there must be a unique GIF file for each addressee we send our newsletters to. Otherwise, how would we know who exactly opened their newsletters and who didn't? Howard-Sarin confirmed this saying:

That's right. There's a unique clear GIF for everyone. We know who each newsletter was sent to, what newsletter it is (eg: the daily vs. the weekly), and which specific edition it is (for example, the Monday edition vs. the Saturday edition). If no one is opening the e-mails on Saturday, maybe we shouldn't send emails on Saturday anymore. 

To some, that sort of tracking (where every newsletter to every recipient is also retrieving it's own uniquely coded clear GIF file) may seem too intimate -- like, we've got too much information on you. But, before we could create a unique GIF just for you, you had to subscribe to our newsletter. In fact, we jump through more hoops than most mass emailers in order to protect your privacy. Before you can get one of our newsletters, you must create a user account on our systems. Then, you must deliberately indicate which of the newsletters you want.  If that's not enough, we then send you an e-mail with links in it that you must click before your subscription(s) can be confirmed. So, to the extent that you've gone to the trouble of subscribing to our newsletters, our ability to track their performance on a personal level is what enables us to determine when our newsletters are no longer useful to you. Not only that, sending newsletters that are of no use to their recipients is disrespectful to the Internet's bandwidth and those who use it.

Finally, going back to Howard-Sarin's willingness to disclose that our HTML newsletters have trackable elements in them, he was pretty straightforward about it:

I don't see why not. We've got nothing to hide. So, I think we should give it a shot and I'd love to hear back from ZDNet's audience to see what they think.

One side note: If after reading this, you still think we've got something to hide or that we're not being above board, keep in mind that we offer text versions of our newsletters as well.  They're not trackable. 

So, sometime this week, once we've had a chance to adjust our newsletter templates, you will begin to see a disclosure statement that mentions the usage of trackable elements in the HTML versions of the daily and weekly editions of Tech Update. These are, as I said earlier, the newsletters that I have some say in. CNET Networks obviously has many other newsletters that I cannot speak for. That said, I'm a big believer in transparency. It's my hope that, in including this new disclosure (one that you won't find on many other HTML mailings, if at all), we've taken a lead that others both in- and outside of CNET can follow.

Editorial standards