When I wrote Monday about the new didtheyreadit.com privacy-invading email tracking system, I had no idea that an even more invasive system has been on the market for two years or so. This system, called readnotify.com, was pointed out by commenter Brian Parsons.
readnotify.com is an email tracking system that uses Web bugs (like didtheyreadit) and also uses a trick involving IFRAMEs (unlike didtheyreadit). The IFRAME trick cannot be disabled by the standard countermeasure of turning off remote image loading. There may not be an easy way to disable it in today’s email software, short of turning off HTML email entirely.
Worse yet, readnotify offers a service that lets anyone put hidden tracking bugs in Word documents, Excel spreadsheets, and other OLE-compliant document formats. When somebody opens a document containing one of these trackers, the time of the access is reported, along with the accessor’s IP address (which often reveals their geographic location) and some configuration information about their computer.
The vulnerability in Word that readnotify exploits was discovered back in 2000 by Richard M. Smith. It got some press coverage back then, but was mostly ignored because there were no reports (at that time) of anybody exploiting the vulnerability. Now there are commercial products that exploit it. It’s time for Microsoft to fix this vulnerability.
Privacy invasion for fun or profit
Two different problems related to this topic were mentioned recently: Edward Felten about tracking emails with web bugs and a CSS “exploit” to leak information about the sites you visit….
Ed,
The “web bug” technique is widely used by business to track their direct marketing campaigns. Try spending some time at MarketingSherpa. You’ll be shocked. It’s used by everyone, including Microsoft, to track the behavior of customers when reading email.
While you’re there, try reading MarketingSherpa’s article, “How Microsoft’s Deal with Ironport’s Bonded Sender Affects Bulk Emailer”. This article talks about how charging spammers to by-pass spam filters for access to customers may become the norm.
Steve
There are two (already in use here) easy solutions for all these methods of access, given that the site being contacted is known in some degree and you don’t want to see whatever content (if any) the reference would bring up:
1. DNS blackhole for the domain (can’t find, can’t talk)
2. Use a local proxy server that automatically returns 404s for some requests.
Number 2 works very well against ads of any kind as well; anything containing “/ads/” in the URL receives an immediate 404 here, for example. So do requests to domain names beginning with “ad.”.
(In case anyone’s wondering, the proxy server being used here at the moment was locally written in PERL. The basic components were very short and easy to write.)
Cypherpunk,
Image-rich HTML email need not involve access to a remote server. The images can be included, in-line (using MIME), in the email message itself.
Also, sophisticated users know, if they see what is obviously an image in an email message, that there might have been a server access. Web-bug laden HTML email often tries to look like plain text messages, so that the user doesn’t realize that a server access is occurring. If the user knows that tracking is possible, he’ll be more careful about, e.g., forwarding the email.
There’s one thing about the concern over web bugs in email that always struck me as odd. It is the claim that web bugs are tiny, unobtrusive, hidden, sneaky little 1 by 1 pixel images so you don’t know they’re there.
My usual mail reader (/usr/ucb/mail) doesn’t display html, but when I have had occasion to use one that does, most html mail is full of graphic images. It’s got logos, pictures, all kinds of stuff. This is, after all, why html is being used, in most cases – to provide enhanced, graphics-rich email.
So there’s no need for web bugs to be hidden; the senders of these commercial emails have ample opportunites to know when they are being read just on the basis of when visible graphic elements are fetched. Emphasizing the supposedly secretive nature of web bugs misses the point of what is wrong with them.
Word Tracking Bug Demo and Remover
Alex Halderman has created a page about the Word tracking bugs I described yesterday. He offers an example tracking bug for you to examine, and a scanner program that can find and remove any tracking bugs on your computer….
turn off remote image loading in a web browser, then go to apple.com; that happens, recently less so; today its almost impractical for daily use of an not advanced user.
Here’s an attempt at a list of ways that web-bugs could be embedded in HTML/CSS to work with some or all popular browsers:
HTML elements:
[img]
[iframe]
[style src=””]
[script src=””]
[input type=”image” src=””]
[link rel=”stylesheet”]
[link rel=”next”] (Mozilla pre-fetches under certain circumstances.)
[embed]
[applet]
[object]
[frame]
CSS rules and properties:
@import
background / background-image
list-style / list-style-image
cursor
content
Javascript and other scripting languages: Many possible ways to initiate an HTTP request.
At Security Space, you can find a definition of Web Bug (http://www.securityspace.com/s_survey/data/man.200105/webbug.html)
“What are web bugs? They are objects (images, iframes, etc.) that are imbedded on a web site that cause part of the web page to be retrieved from a completely different web site.”
This implies that images and iframes are not the only things that can be used for web bugs.
An options in mail and other programs like “Don’t load images from another system” is not enough. It should be “Don’t load *anything* from another system”. You could add refinements like “Load only from mydomain.com” or whatever, but that would probably just confuse the average home computer user.