Read an e-mail, Lose Your Privacy

Copyright (c) 2000-2001 by Rich Morin
published in Silicon Carny, January 2000

Assorted cyber-privacy organizations are asking regulators to fix a privacy leak in Web browser software. Rich tells us why this is only a small part of the problem.

"E-Mail May Be Peril to Privacy", shouted the lead headline on the first page of the business section of the Dec. 4 edition of the San Francisco Chronicle. Reading the article by Associated Press writer Kalpana Srinivasan, I was happy to see the issue getting some attention, but hardly surprised to hear about yet another privacy threat.

David Brin, author of The Transparent Society (Perseus Books, ISBN: 0-738-20144-8), writes that a lack of privacy is inevitable. Although I don't agree with everything he says, the odds look pretty good that Brin might be right on this one.

And, while I hope Scott McNealy is using hyperbole when he says, "You have zero privacy now. Get over it," (PC Week "Quote of the Week," Feb. 1, 1999), it's not at all clear that he is. Every time I'm asked to have my signature digitized for posterity during a credit-card purchase (which I refuse, as a matter of principle), I am reminded of just how invasive our society has become.

Hiding HTML links in e-mail

Enough generalized paranoia, however; let's look at some specific threats.

Most Web browsers hide the HTML portion of a link, showing only a highlighted word. Many e-mail clients, particularly those that are embedded in Web browsers, perform this service as well.

This is a useful feature, in most cases. After all, HTML code is both bulky and mysterious; most e-mail users have neither the expertise, time, nor motivation to analyze every incoming bit of HTML. Unfortunately, however, this can leave an unwary user open to privacy attacks.

Let's assume that a porn site sends me some spam, including the following bit of HTML:

    <A HREF=""></A>

No problem so far; is just a Web site, so visiting it should be pretty anonymous. All the site will get from my visit, in general, is an IP number or perhaps a domain name. The site can't use either of these to send me more spam or identify me as a visitor.

Unfortunately, URLs can contain other items, including parameters that can be transmitted back to the site:

    <A HREF=""></A>

If I take the bait and visit the site, my e-mail address,, can be put on a "hot list." Of course, they had already obtained my address from an existing list, but they didn't know I would take the offered bait. Now they do.

This is bad enough, but it gets worse. If I am using such a Web browser to handle my e-mail, even opening the e-mail message may be enough to initiate a serious loss of privacy. Many Web browsers are capable of enhancing e-mail messages with all sorts of (possibly invisible) images, retrieving them when a message is opened from any specified URL. The spammer is free to take advantage of this, by means of an IMG tag that includes my e-mail address in a parameter, as follows:

    <IMG SRC=""></A>

Wanna cookie?

The spammer now knows that I opened his message, but even that's not the worst part. The Web site can also return a cookie to my browser containing my (possibly disguised) e-mail address. This means that any future visit I make to his site (or other, cooperating sites) can be recorded and indexed to my e-mail address.

In short, my privacy will have been severely compromised by my e-mail software, without my knowledge or permission. For more information on this specific kind of attack, see the Electronic Frontier Foundation's press release, or the technical report by security expert Richard M. Smith (see Resources, below).


Unfortunately, these sorts of attacks can take many forms. For instance, it is quite possible to eliminate the need for a parameter altogether. Let's say the image request looks like this:

    <IMG SRC=""> 

This seems pretty innocent, from a privacy perspective, but it might not be. In one possible scenario, the spammer could generate a unique URL for each outgoing e-mail message, joining random names ("susie", "tammy", ...) with random letters ("q," "r," and so on). As each piece of e-mail is sent, the spammer saves the outgoing e-mail address in a database, keyed by the unique portion ("susie_q") of the URL.

When the image request is received, a hidden CGI script ("") can record the request in the database, send me an identifying cookie, and so on. In short, any image request could be "bugged."

Finally, if I am foolish enough to click on an unknown URL, the spammer doesn't need parameters or even "hidden" HTML: 

The same logic applies; because the spammer knows who he told about "susie_q", he knows who is asking to see the Web page. Welcome to spamland, sucker.


Unfortunately, one moral of this story, like that of Ken Thompson's classic paper, "Reflections on Trusting Trust" (see Resources, below), is that Trojan horses can come in many guises, and one should not trust a stranger's offerings, even if they contain no visible threats.

Another moral is that convenient "features," made possible by aggregating pieces of software (in this case, e-mail and Web clients), can lead to unexpected security holes. Microsoft is the most obvious perpetrator here, but Netscape and others have clearly played a part.

In an environment where random miscreants can send e-mail to unsuspecting victims, keeping a few barriers in place seems only prudent. The increasing spate of e-mailed "macro viruses" provides a clear example of the reasons.

Putting macros -- interpretable code -- into word processors and other programs is clearly a powerful and useful idea. Having e-mail software start up a copy of the word processor in order to read formatted mail, is also quite convenient. Unfortunately, the combination allows miscreants to run macros on victim's machines, merely by sending them e-mail.

I don't have any global solutions to offer, but I can offer some advice: Don't use Web browsers or highly integrated systems, such as Microsoft Outlook, as e-mail clients; they're far too accommodating to spammers.

If you must use unsafe e-mail software, try to use it in a conservative manner. Turn off any automated features, such as automated program invocation, that might allow miscreants to take over your machine. Until the vendors add some real security, the risks far outweigh any possible convenience.

Editor's note: The domain name "" was not registered at the time this article was published. Any similarity to an existing domain name or Web site is purely coincidental.


Electronic Frontier Foundation press release

"Reflections on Trusting Trust", by Ken Thompson
"The Cookie Leak Security Hole in HTML E-mail Messages", by Richard M. Smith
"The Transparent Society", by David Brin
Perseus Books

About the author

Rich Morin ( operates Prime Time Freeware (, a publisher of books about Open Source software. Rich lives in San Bruno, on the San Francisco peninsula.