More on

by brian d foy

Preston Gralla recently mused about a new web service, DidTheyReadIt, that claims to notify you when and for how long someone read your email.

I was playing around with Rampell Software's DidTheyReadIt service which claims to be able to tell you for how long the recipient of a message had your message open. Their other products are various forms of spy ware, too.

I thought that DidTheyReadIt was probably a refresh trick: just keep reloading the image. However, the actual HTML is very simple (and not even valid):

test.<br />
<br />
this page has a little "web bug" in it. that's an image that loads. <br />
supposedly from that the DidTheyReadIt folks can tell me when, where,<br />
and for how long you read this email (although you have to click on<br />
"display external images" in Gmail.<br />
<br />
<br><img src=""
width="1" height="1" />

I tried accessing the URL in Firefox and in lynx. Data kept coming down the pipe as long as I let it. Other people tried the same thing with the same result. DidTheyReadIt just keeps pushing data at you.

I was amazed at how stupidly they did this. On a slow link, this just about killed my bandwidth (although I was loading it in three different user-agents). Imagine if your business got a lot of mail from another business using this. That's a lot of open connections and a lot of data clogging your pipe.

Not only that, though, imagine the poor system engineers at Rampell who will have to deal with the amount of data and the number of processes they will have to run to service every open email if they get as successful as any business hopes to be! They have really set themselves up for failure, or at least lots of bandwidth charges.


2004-06-11 15:56:08
Bad Network Design
Imagine if your business got a lot of mail from another business using this.

If that were to happen, there are about seven places to redirect traffic from to the innermost circles of hell. It's not so much a case of if the network support staff can blackhole these webbugs, but who gets the bonus for doing it first.

2004-06-11 21:13:23
Killed your bandwidth?

On a slow link, this just about killed my bandwidth

From my meager tests, it looks like the data rate is very close to 1 byte per second (8 bps). I think "killed my bandwidth" might be a little extreme, unless I'm missing something.

2004-06-11 23:49:20
Killed your bandwidth?
I'm on a very slow link at times. There is something wierd with the network I'm on, and I'm not the only one using it.
2004-06-12 12:50:11
just do this from the command prompt:
Here's what happens when you issue the HTTP request yourself, using telnet. As brian said, it sends about 1 byte per second, and with the chunked-encoding overhead, it's actually a few bytes per second:

% telnet 80
Connected to
Escape character is '^]'.
GET /index.php/worker?code=844eea38c4f0ab9bd2220f65f4107dbe HTTP/1.1

HTTP/1.1 200 OK
Date: Sat, 12 Jun 2004 19:46:35 GMT
Server: Apache/1.3.29 (Unix) PHP/4.3.6 mod_ssl/2.8.16 OpenSSL/0.9.7a
X-Powered-By: PHP/4.3.6
Set-Cookie: PHPSESSID=b3f4727a4dfd69f80f29520e4ef00129; expires=Sun, 13-Jun-2004 19:46:41 GMT; path=/;
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Connection: close
Transfer-Encoding: chunked
Content-Type: image/jpeg












2004-06-12 13:26:37
just do this from the command prompt:
It's a lot more than just that though, because you have to figure in the transport too. I watched it with tcpdump:

sudo /usr/sbin/tcpdump -lx -i -s 1024 dst port 80 and src host

I watched that several times, and each time captured around 120 packets just for that 1x1 pixel image. That's a lot of extra bytes, and that's not even counting the wireless packets that were around those packets.

2004-06-14 07:44:36
It's a standard technique
Pure-CGI, browser based chat systems do this do make the browser wait before it refreshes the chat pane HTML, by giving it a byte every so often, keeping the connection alive until someone else in the chatroom says something. The server then closes the connection, which allows the browser to "finish" loading, at which point its reload fires.

It is also the same technique exploited for the SMTP teergrube spamming countermeasure.

I don't think it's that stupid. What's stupid might be the extent to which they want to deploy this.

If spammer harvester bots pick up these URLs though, then maybe we have a partial solution to email scum — feed them their own dog food…

2004-06-26 19:17:37
I cant find any reason why i should pay for that :D
I was starting to use similar technique couple years ago, whit much more detailed information then does, you need a little bit easy programming, and ya have much better control panel & results then they have. Clever idea to make money of something so easy :D

& any one, who does NOT want to let other people know when they read someone’s mail, knows how easy it is to do so :)

2004-06-28 11:40:25
spy mail in general
If you use Outlook, I wrote a plugin to outlook which detects this kind of spy mail - basically any email that contains images that are tracking programs rather than real images. It catches didtheyreadit like a charm; it also catches a lot of spammers that use similar techniques to improve their marketing campaigns. Anyway, if you want to try it - its free.