E-mail and privacy
Let’s look at some specific threats. Most Web browsers hide the HTML portion of a link, showing only a highlighted word or two. Many e-mail clients, particularly those embedded in Web browsers, perform this service as well. It is a useful feature, in most cases. After all, HTML code is both bulky and mysterious; and most e-mail users have neither the expertise, time, nor motivation to analyze every incoming bit of HTML. However it can leave a user open to attack.
An e-mail (solicited or unsolicited) can contain a URL address. If just a web site, most visitors assume their visit is anonymous. All the site will get from a visit, in general, is an IP address or perhaps a domain name. The site can’t use either of those to send the visitor more e-mail or identify one as a visitor. However, URLs can contain other items, including parameters that can be transmitted back to the URL site. If the visitor visits the site, the visitor’s e- mail address, can be put on a e-mail mailing list.
The web site managers had already obtained the e-mail from an existing list, but they didn’t know if the recipient address was valid. Now they do. It gets more intrusive. If a Web browser is used to handle e-mail, even opening the e-mail message may be enough to initiate a significant loss of information. 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 sender is free to include an IMG tag that includes the recipient’s e-mail address in a parameter.
How about a cookie? The sender now knows that the sent message has been opened. The sender’s website can also return a cookie to the recipient’s browser containing the recipient’s (possibly disguised) e-mail address. This means that any future visit the recipient makes to sender’s site (or other, cooperating sites) can be recorded and indexed to the recipient’s e-mail address. In short, the sender’s anonymity will have been severely compromised by the recipient’s e-mail software, without the recipient’s knowledge or permission.
These sorts of attacks can take many forms. In one possible scenario, the sender could generate a unique URL for each outgoing e-mail message, joining random names (trixi, bubbles, etc, …) with random letters or numbers (a, b, or 1,2,3). As each piece of e-mail is sent, the sender saves the outgoing e-mail address in a database, keyed by the unique portion (trixi – 1) of the URL. When the image request is received, a hidden CGI script can record the request in the database, send the recipient an identifying cookie. You must remember, any image request could be tagged.
Finally, if the recipient is foolish enough to click on an unknown URL, the sender doesn’t need parameters or even “hidden” code. The same logic applies: Because the sender knows whom he told about trixi – 1, the sender knows who is asking to see the Web page. It is apparent 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 contributed to the situation. This is not about blame; it is about fact, and in truth most of us value convenience over security. In an environment where random miscreants can send e-mail to unsuspecting victims, keeping a few barriers in place seems only prudent. The 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, so you can read formatted mail, is convenient. The combination means that bad people can run macros on a recipient’s machine merely by sending e-mail.
We are aware of no global solutions. However, many feel you shouldn’t use web browsers or highly integrated systems, such as Microsoft Outlook, as e- mail clients: They’re far too accommodating to bad people sending e-mail. If you must use e-mail software with known security holes, try to use it in a conservative manner. Turn off any automated features, such as automated program invocation, that might allow others to take over your machine. Until the vendors add some real security, the user must weigh the risks versus any possible convenience.
Trojan horses can come in many guises, and one should not trust a stranger’s offerings, even if they contain no visible threats.
