Page Updated: Tuesday, October 10th, 2000

MAJOR NEWS!! Senator John Edwards
Introduces 'Spyware Control Act'
What do the NetZip-descended
file downloaders whisper when
they think you are not listening?

OVERVIEW:  How Does This Affect YOU ?

As you will see on the page below, if you use the RealNetworks RealDownload, Netscape/AOL Smart Download, or NetZip Download Demon utilities in their default configuration . . .

EVERY TIME you use one of these utilities to download ANY FILE from ANYWHERE on the Internet, the complete "URL address" of the file, along with a UNIQUE ID TAG that has been assigned to YOUR machine, and — in the case of Netscape's SmartDownload only — YOUR computer's individual Internet IP address, is immediately transmitted to the program's publisher.

This allows a database of your entire, personal, file download history to be assembled and uniquely associated with your individual computer . . . for whatever purpose the program's publishers may have today, or tomorrow.

VERY IMPORTANT: When I re-examined my findings in the face of RealNetworks' insistence that I was absolutely wrong about my conclusions, I caught something that I had missed before: My exact personal name and private eMail address was being sent back to RealNetworks whenever I downloaded a file. When I confronted RealNetworks with this, they explained that it was due to the fact that I had purchased a product from them in the past, and the "cookie" my system had received during the purchase was being returned to them.

That certainly makes file downloads seem far less "anonymous" than RealNetworks continues to allege. (Full details are provided below.)

Friday,
July 14 I download fresh copies of all three Download Demon-descended file downloading utilities and conduct a series of tests to verify the rumors I've heard about their "phoning home" behavior.

In each case, the behavior I examined resulted from each program's "default configuration" which is enabled unless deliberately disabled by the user. I confirmed that all three programs send a report back to their publishers whenever the program is used to download any file through the Internet. This report includes the full URL of the file being downloaded and an "ID Tag" which could be used to uniquely identify the downloading computer.

In the case of Netscape's Smart Download, the computer's individual Internet IP address is also sent as a "cookie header" which would tend to defeat IP-masking proxies and anonymizers.

Monday,
July 17 By Certified Mail I receive RealNetworks' threat letter — which I ignore because it's just so much nonsense — and proceed to initiate a very constructive dialog with two representatives of RealNetworks. Their V.P. of Government Affairs and Privacy informs me that I am absolutely, totally, and completely mistaken and insists that I immediately take this page down and retract all of my public statements to everyone who has received them. (I guess he must have read Robert Kimball's letter too.)

I refuse to remove the page based solely upon his forceful representations and assurances. But I worry — in the face of their legal threats — that I might somehow have been completely mistaken. So I quickly post a big red notice at the top of this page to notify its readers that RealNetworks is very sure that I am completely wrong, and that I am immediately working to re-verify all of my findings.

Then a much more serious RealDownload
privacy concern rears its ugly head:

It's Monday afternoon, and everything still comes out just the way it did Friday. (In other words, I was right all along.) However, this time I happen to notice that my actual first and last name, and my own private eMail alias address are also being transmitted to RealNetworks as a result of each file download. So I immediately forward the captured packet to the RealNetworks representatives with whom I'm working and ask them what is going on.

By phone the technical manager with whom I'm speaking asks if I've ever purchased anything from Real? I explain that a few months ago I purchased "Real Producer" in order to produce streaming content for my web site. So she explains that my purchase and interaction with their eCommerce server left a "cookie" on my computer which included my real name and personal eMail address from the purchase transaction.

I see.  So now my private information — which was obtained by RealNetworks during a SECURE PURCHASE TRANSACTION with an explicit commitment for security, privacy, and secrecy — is being sent back to Real — months later — "in the clear" with no security, every time I download arbitrary files from the Internet using their utility — along with the full name of the file I downloaded and the unique ID that could be used to identify my computer.

I think that's a "Real" problem. And it would certainly seem to contradict RealNetworks' repeated statements that it is not possible for them to associate my use of RealDownload with any personally identifiable information. If my name and private eMail address aren't "personally identifiable information", what is? Moreover, that personal information could be easily associated with the file download which directly triggered the transmission of that information.

Based upon my understanding of how and why this happens, this is easily reproducible and is apparently going on all the time with RealNetworks customers . . . like right now. If what I've been told by the RealNetworks technical manager is true — and it certainly fits the facts and logic — it appears that anyone who has purchased a RealNetworks product through their eCommerce system receives an insecure, plaintext, cookie containing their actual name and eMail address. I certainly did. And this cookie is then sent back to RealNetworks . . .

. . . even in situations where users of RealNetworks'
products have been repeatedly and even forcefully
assured of their absolute anonymity.

Whoops.

On a Technical Point:

RealNetworks has stated repeatedly that they care about their user's privacy. And they tell us that they are "the leader in the delivery of Internet media." Monday they told me that they employ 400 programmers. With all that, wouldn't you be inclined to presume that they had a grasp on Internet Technology?

If they care about our privacy, why are they storing
my real name and private eMail address — from an
eCommerce transaction — as "plain text" in a cookie,
and sending it out without any security whatsoever?

Even if it weren't being sent back due to a file download it would still be a significant privacy concern. Why not, instead, use a cookie the way it was intended to be used? A cookie should be an "opaque token"; an apparently meaningless string of characters, which only has meaning to the entity which created it.

But none of that was the problem I was facing at the moment. (Perhaps we'll deal with that one next.) I was working to demonstrate to the RealNetworks representatives the absolute truth of what I'd been saying about the transmission of a system-unique ID.

So, using RealDownload, I downloaded three different files over the course of several hours and from different Internet servers. I captured each resulting 'downloadid' as it was leaving my computer on its way to RealNetworks:

downloadid=9B1450495BF211D4A025002018252799
                  *
downloadid=9B14504A5BF211D4A025002018252799
                  *
downloadid=9B14504B5BF211D4A025002018252799

As you can see, they differ by a single character, and that character is changing from "9" to "A" to "B" which indicates standard hexadecimal counting. So I sent these 'downloadids' to the RealNetwork representatives. This apparently puzzled Real's technical manager who said that she'd have to get back to me on it. When she called back she explained that, sure enough, they had succeeded in duplicating the same behavior in their labs and . . . that it must be a bug.

A "bug"??   Yeah . . . okay . . . I guess that would be a big one?

She explained that she had just learned that the last 24 characters of the "downloadid"'s 32-characters, were derived from a Windows GUID.

"GUID" stands for "Globally Unique IDentifier" and is a technology standard specified by the Open Software Foundation (OSF) to create unique and non-repeating "ID Tags". Such "ID Tags" are generated once then stored, typically in the Windows Registry.

If you're really curious, use the Windows "RegEdit" program to look under this key name: HKEY_CLASSES_ROOT\CLSID and you'll see a billion GUID's (Don't change anything!)

In the past, the use of GUID's has aroused the wrath and concern of privacy advocates the world over, since they are like "serial numbers" which can be used to uniquely identify software users.

Okay. So now we know how and where RealNetworks gets the last 24-characters of their 'downloadid'. It is a non-changing unique identifier, different for every computer. Today, they may not like the fact that their use of a deliberately unique and fixed identifier has severe privacy overtones, nor that they have been caught in an outright lie about their use of an identifier which is being transmitted and could be used to track the software download habits of their RealDownload users. But I never expected that forcing them to publicly confess the truth would make them particularly happy.

downloadid=9B145049 / 5BF211D4A025002018252799

It appears to be quite likely that the first eight characters are a hexadecimal representation of a 32-bit binary quantity that is incremented for every download — that, in any event, is the behavior I witnessed. So the first portion which appears to be incremented for each download functions like a "download session ID". Whereas the last 24 characters are exactly what I have always asserted: A "download machine ID." Together, they create a deliberately concocted, unique identifier, which, when transmitted from any user's computer could be used to track their users' download behavior over time and to assemble a download profiling database.

Tuesday,
July 18 Things were much quieter today. I was told that RealNetworks staff was "in meetings" most of the day.

Then, at the end of this long day of "meetings" — which were apparently spent carefully wording the following document — RealNetworks produced this formal statement:

REALNETWORKS PRIVACY STATEMENT 7/18/00

In response to recent questions regarding certain technical functions of its RealDownload product, RealNetworks today issued the following statement:

"We emphatically disagree with the implications raised by certain members of the technical community about the behavior or planned behavior of RealDownload. To be clear: RealDownload does not transmit personally identifiable user information to RealNetworks without informed consent. It does not monitor users’ behavior and it does not log download URL information. Because we do not log download URL information and the product does not transmit registration information identifying the RealDownload user, we cannot and do not store download URLs with personal information — and we never have.

"We work very hard to ensure that our products comply with all of our privacy policies. We have even taken the extra step of hiring Arthur Andersen to independently review our compliance with our own strict privacy policies. Through its eSure audit program, Arthur Andersen has independently verified that RealNetworks does not store URLs transmitted from the RealDownload product.

"Because of the way RealDownload interoperates with the APIs of certain versions of the Windows operating system, it creates for each download a new, 32-character code that does not contain any personal information, but apparently does not fully randomize during each download. Now that we are aware of this technical issue, and because the 32-character code serves no purpose, we are removing it from forthcoming versions of RealDownload.

"As the leader in the delivery of Internet media, we at RealNetworks set for ourselves and will adhere to the highest privacy standards. We appreciate the ongoing diligence of privacy experts and we will continue to develop RealNetworks products in a manner that respects customers’ privacy."

Tuesday Evening . . .

July 18 — ZDTV's Leo Laporte and I discuss the
current situation on Leo's ScreenSavers show.
Are you being watched when you download?

Wednesday,
July 19 Regarding RealNetworks' Statement:

Since I am in the hot seat here, being the "certain members of the technical community" who has "raised implications", the world will be looking for my reaction to this statement from RealNetworks. I received their statement first from RealNetworks directly, then subsequently from several members of the media. Everyone has wanted my reaction. Here it is:

I am unconcerned and unimpressed with most of RealNetworks' Statement. They specifically failed to address the reason for the presence of the "insufficiently random" 32-character code whose very existence they had previously denied emphatically. I am, however, pleased to learn that they have decided that it now "serves no purpose" and will forthwith be removed from the product. The sooner the better for everyone involved.

We are still left with what is, arguably, a much bigger problem: The undeniable transmission of personal and private "personally identifiable" information as a direct consequence of the use of RealDownload. See the full technical 'dissection' below . . .

Thursday,
July 20 Everything I hear from RealNetworks indicates that they are taking every issue I have raised on this page very seriously . . . and not just paying them lip-service, but really doing something quickly:

I am told — but have not yet verified — that the opportunity for the significant "personally identifiable" information leakage has already been fixed. That's got to be a record — I only published my discovery of it this morning!

WHOOPS! Spoke too soon. NOT
FIXED as of end of day Friday!

As I detail below, the potential breach arose from RealDownload images being served from the eCommerce site's domain, thus exposing an eCommerce derived cookie during a RealDownload transaction. But since the image URL's were being provided on-the-fly by the RealDownload server, their source server could be changed with no change to the product. By serving the RealDownload images from the RealDownload (non-commerce) server, eCommerce cookie disclosures will no longer be triggered.

Tomorrow I will verify that this is, in fact, now happening.

We are still left with the problem of RealNetworks' storage and transmission "in plaintext form" of information which was received by them over a secure connection. I will publish an analysis and discussion of this issue tomorrow.

I am told that RealNetworks may release a new version of RealDownload tomorrow . . . thus breaking another retooling speed record. So we might soon have a new version of RealDownload that does not, and can not send unique "per-computer" identifiers back to RealNetworks' servers.

Any Internet server is typically able to determine the Internet (IP) address of a connected client — such as the user's computer when it sends a file download report. That's how my own 'ShieldsUp' security testing system operates. Therefore, RealDownload users who are extremely security conscious, and who have non-dynamic IP addresses (most non-dial up users) may still desire to disable RealDownload's "per file" reporting function so that all "per-download" reporting is disabled.

We'll see what tomorrow brings. Things are looking up.

Friday,
July 21

July 21 — RealNetworks Inc. admitted today its
RealDownload software could be used to track
specific users’ exact download habits.
http://www.msnbc.com/news/436070.asp

My determination to dig out the WHOLE truth takes an unexpected turn today. Curious about the fact that the size of a full Windows GUID is exactly the same as the size of RealNetworks' infamous 'downloadid', I write my own little program to request GUIDs from the Windows operating environment. Running this program three times on the same computer which performed Monday's results, generates the following three GUIDs:

Three Successive Windows GUIDs WITHOUT reboots

GUID = CCDE2D405EF811D4A025002018252799
GUID = CCDE2D415EF811D4A025002018252799
GUID = CCDE2D425EF811D4A025002018252799

Notice that, EXACTLY like the three successive downloadids generated by RealDownload on Monday, these GUIDs differ from each other in exactly one character, that this character is counting, and most significantly, the LAST 20 CHARACTERS of the GUIDs I generated exactly match the tail of the 'downloadid':

      GUID = CCDE2D405EF8 11D4A025002018252799
downloadid = 9B1450495BF2 11D4A025002018252799

Next, I use my GUID-maker program to generate three GUIDs, but I restart Windows each time:

Three Windows GUIDs WITH REBOOTS

GUID = A7F1BFC05FD811D4A025002018252799
GUID = 39CC01805FD911D4A025002018252799
GUID = 8ADA6EE05FD911D4A025002018252799

We see that the first 12 characters of the GUIDs are different (especially the first eight), whereas the 20 character GUID tail is absolutely constant, even across reboots of a single system.

Network adapters are designed to possess "globally unique" MAC addresses in order to prevent physical address collisions when communicating across a local network segment. This means that Network adapter MAC addresses are a good source for some guaranteed-to-be-unique "bits". Therefore, the Open Software Foundation's (OSF) GUID creation scheme incorporates the machine's LAN adapter MAC address, when available, into the GUIDs creation. Since the tests have so far been conducted on a networked machine with a LAN adapter, the next logical step would be to perform them on a machine without a network card:

Three Windows GUIDs WITH REBOOTS
and NO LAN Adapter MAC Address

GUID = 7A9196805FE811D4BA1DA6C968FAE763
GUID = 147026E05FE911D4BA1D8FF112DACE63
GUID = 9C1C35205FE911D4BA1DA55166FEC463

As you can see above, without a LAN adapter's static MAC address available, the situation again changes. Now a region in the center of the the GUIDs is static across GUID generation and across reboots, but the last 12 characters, which had previously never changed, are now very different after each reboot.



So What Does it All Mean?

It means this is a big mess. All of the evidence indicates that RealNetworks' 'downloadid' actually is nothing more or less than a standard Windows GUID.

downloadid == GUID

The RealNetworks technical manager told me, Monday, that the last 24 characters of their 'downloadid' were "derived from" a Windows GUID. And while I suppose that's technically correct, it's a bit misleading, since I am now virtually certain that their 'downloadid' is exactly and without 'derivation' a Windows GUID.

"Huh? They're using dynamically generated
Windows GUIDs as their download IDs?"

Yeah . . . I know . . . It is a really weird and dumb thing to do:

As we have clearly seen, it is not reliably static enough to use as a trustworthy per-computer identifier, yet it is one, sort of, most of the time, maybe. But neither is it random enough to be used as an opaque per-transaction identifier (as I believe it was intended) without the serious privacy concerns that I originally raised.

Here's exactly what I believe happened:

The copy of NetZip's Download Demon I analyzed exhibits precisely the same behavior as RealNetworks' RealDownload. Therefore, I believe that prior to RealNetworks' acquisition of Download Demon from NetZip, some programmer at NetZip wasn't the least bit concerned about privacy issues. (This is certainly still more the rule than the exception today.) So this programmer innocently uses a Windows GUID as a convenient unique tag for their Demon's transaction tracking. This programmer never stops to consider, if he or she even knew, that the GUID contains — by design and specification — the machine's absolutely unique LAN adapter MAC address, or some other relatively invariant machine-specific tagging information if the system has no LAN card.

Next, RealNetworks apparently commits two blunders:

They employ Arthur Andersen to provide a third-party blessing of a second-party product. Since I doubt that the folks from Arthur Andersen are grossly incompetent, it can only be that they don't really care about, or understand, the nature and requirements for personal privacy. They put the Arthur Andersen eSeal of Approval on a product which is not only sending a unique identifier, but managing to transmit its user's unique MAC adapter address across the Internet while intimately associating it with every file download. Yikes!

RealNetworks, for its part, either didn't perform its own effective or useful code review on a second-party acquired product, or it, too, is not sufficiently aware of the requirements for personal privacy. Oh sure, RealNetworks has license agreements, privacy policies, and rampaging lawyers galore, but its actual products suffer time and again from significant privacy concerns.

RealNetworks has, undeniably, fumbled their acquisition of Download Demon and the release of RealDownload, but . . .

A completely fair reading of the
evidence suggests that RealNetworks
never meant to violate anyone's privacy.

And, significantly, this is absolutely different from the conclusion I would draw from the design of Netscape's superficially similar Smart Download product. As you will see below, Smart Download creates an ID Tag in the registry of any machine it's installed on and transmits that Tag with every file download report.

Tuesday,
July 25 CONFIRMED: The currently downloadable new version of RealDownload omits the infamous downloadid from its "phoning home" per-file download reports. The reports (enabled by default) continue to be sent, but any user-tracking would be much less accurate now, needing to be based upon the user's potentially dynamic IP address. ("Phoning home" is a fundamentally non-private action for any Internet software.)

CONFIRMED: Previous version(s) of RealDownload continue to retrieve images from RealNetworks' eCommerce server domain. RealNetworks customers who received an insecure personal cookie containing their name and address, will have this private and personally identifiable information transmitted as a result of the use of previous version(s) of RealDownload. I was told this privacy breach would be eliminated five days ago . . . yet it continues.

Thursday,
August 3 RealNetworks continues to bend the
truth and fails to take responsibility
for the behavior of their software.

I receive a copy of an eMail from its recipient. It is reproduced here in full so that the excerpt below can be seen in context. This was apparently generated and sent by RealNetworks' Vice President of Government Affairs and Privacy — the person with whom I have been dealing at RealNetworks.

It may be, at least in part, a form letter sent to anyone who questions RealNetworks about the conduct of RealDownload. If that is the case; if this is the message everyone is receiving; I need to address the glaring inaccuracy it promotes since it is the main topic of concern:

"Unfortunately, recent reports have incorrectly
stated that RealNetworks is capable of tracking
or somehow "monitoring" individuals' downloads.

If the folks at RealNetworks really believe what they are saying, they must be using a very odd definition of the term "monitoring" since we all know that in its default configuration (unless deliberately disabled by the end user) RealDownload transmits a report for every file that any user downloads, which is received and accepted by web servers at RealNetworks'. And furthermore, by their own admission, they do employ this information for customizing the advertisements which their users' see, based upon the type of file downloaded. They also claim to use this information for other purposes when dealing with "partner web sites." As far as I know, the nature of those "other purposes" has never been clearly articulated. But in any event, it is simply not true that RealNetworks is incapable of monitoring individuals' downloads. They clearly are, and they apparently do.

In order to confirm or deny the reports alleging that the Real Networks and Netscape/AOL download utilities might be spying on their users by secretly "phoning home" with detailed reports of every file their users download, I used a readily available "packet sniffer" to monitor the data being sent from one of my machines when downloading a handful of my own website's files.

I was able to quickly confirm that the NetZip-descended downloaders used by Real Networks and Netscape/AOL were, indeed, sending detailed reports of every download "back to base" every time they were used to download a file.

These reports contained the complete Internet URL of the file being downloaded and were accompanied by an apparently unique "ID Tag" which was associated with each machine. To confirm this, I experimented with downloads from several different computers. In every case the "apparently unique ID" being sent out never changed on the same computer, and each computer has its own.

Netscape's Smart Download goes one step further by including the computer's IP address in a separate "cookie" header. This is troubling, since "cookie" headers tend to be left alone as they pass through proxies and anonymizers. This would thwart deliberate attempts at keeping the computer's IP address confidential.

When you consider that each user's computer is uniquely identified, and that reports are being sent back for every file downloaded — and accompanied by a unique ID tag (and, in the case of Netscape, the machine's unique IP address) . . .

After installing RealNetworks' RealDownload utility, I clicked on a web link to download the file "id.exe" from my server at "grc.com". The following TCP/IP data packet was immediately sent out of my computer to one of Real's servers:

MAC source address: 00-20-18-25-27-99
MAC dest address:   00-90-7F-01-21-E8
Frame type:         IP
Protocol:           TCP->HTTP
Source IP address:  207.71.92.206
Dest IP address:    207.188.30.49
Source port:        1107
Destination port:   80
SEQ:                3073973
ACK:                169605441
Packet size:        417

Packet data:
0000:  00 90 7F 01 21 E8 00 20 18 25 27 99 08 00 45 00 ....!.. .%'...E.
0010:  01 93 1C 0A 00 00 40 06 43 58 CF 47 5C CE CF BC ......@.CX.G\...
0020:  1E 31 04 53 00 50 00 2E E7 B5 0A 1B F9 41 50 18 .1.S.P.......AP.
0030:  FF FF 44 5A 00 00 47 45 54 20 2F 73 61 32 2E 61 ..DZ..GET /sa2.a
0040:  73 70 3F 70 72 6F 64 75 63 74 3D 52 65 61 6C 44 sp?product=RealD
0050:  6F 77 6E 6C 6F 61 64 26 76 65 72 73 69 6F 6E 3D ownload&version=
0060:  34 2E 30 2E 30 2E 31 38 26 70 6C 61 74 66 6F 72 4.0.0.18&platfor
0070:  6D 3D 57 69 6E 39 38 26 65 76 65 6E 74 3D 64 6F m=Win98&event=do
0080:  77 6E 6C 6F 61 64 53 74 61 72 74 26 75 72 6C 3D wnloadStart&url=
0090:  68 74 74 70 25 33 41 25 32 46 25 32 46 67 72 63 http%3A%2F%2Fgrc
00A0:  2E 63 6F 6D 25 32 46 66 69 6C 65 73 25 32 46 69 .com%2Ffiles%2Fi
00B0:  64 2E 7A 69 70 26 72 65 66 75 72 6C 3D 67 72 63 d.exe&refurl=grc
00C0:  2E 63 6F 6D 26 66 69 6C 65 73 69 7A 65 3D 31 32 .com&filesize=12
00D0:  33 32 38 26 6D 69 6D 65 3D 61 70 70 6C 69 63 61 328&mime=applica
00E0:  74 69 6F 6E 25 32 46 7A 69 70 26 70 65 72 63 65 tion%2Fzip&perce
00F0:  6E 74 3D 30 26 64 6F 77 6E 6C 6F 61 64 69 64 3D nt=0&downloadid=
0100:  39 42 31 34 35 30 34 39 35 42 46 32 31 31 44 34 9B1450495BF211D4
0110:  41 30 32 35 30 30 32 30 31 38 32 35 32 37 39 39 A025002018252799
0120:  26 73 62 69 64 3D 26 73 70 6F 6E 73 6F 72 3D 72 &sbid=&sponsor=r
0130:  64 62 61 73 69 63 20 48 54 54 50 2F 31 2E 30 0D dbasic HTTP/1.0.
0140:  0A 48 6F 73 74 3A 20 73 61 2E 6E 65 74 7A 69 70 .Host: sa.netzip
0150:  2E 63 6F 6D 0D 0A 41 63 63 65 70 74 3A 20 2A 2F .com..Accept: */
0160:  2A 0D 0A 43 6F 6F 6B 69 65 3A 20 4C 61 73 74 49 *..Cookie: LastI
0170:  6E 66 6F 49 44 3D 31 30 30 32 3B 73 62 69 72 73 nfoID=1002;sbirs
0180:  68 61 72 65 3D 72 64 62 61 73 69 63 0D 0A 52 61 hare=rdbasic..Ra
0190:  6E 67 65 3A 20 62 79 74 65 73 3D 30 2D 0D 0A 0D nge: bytes=0-...
01A0:  0A

This rather intimidating looking hexadecimal data block (above) can be easily "parsed" into something far more intelligible. Breaking the block of ASCII text (over in the right hand column) into individual lines (at the '&' delimiter), and translating the "URL Encoding" (those %3A and %2F which mean ":" and "/" respectively), the first long line we see, which is the "command" being given to RealNetworks' server, is:

GET /sa2.asp?
product=RealDownload
version=4.0.0.18
platform=Win98
event=downloadStart
url=http://grc.com/files/id.exe
refurl=grc.com
filesize=12328
mime=application/zip
percent=0
downloadid=9B1450495BF211D4A025002018252799
sbid=
sponsor=rdbasic
HTTP/1.0

The balance of the data transmitted consists of the additional information "parameters" shown below:

Host:   sa.netzip.com
Accept: */*
Cookie: LastInfoID=1002;sbirshare=rdbasic
Range:  bytes=0-

The complete URL of the file I downloaded was sent to the receiving server: "url=http://grc.com/files/id.exe". The receiving server thus knows the location and full filename of the link I clicked on to download.

My machine and I have been "tagged" by the compound "Key" of:



Which can be broken into its two component parts:



The left chunk is a "counter" which appears to be incremented once for every file downloaded. I believe that this serves as a "session ID" to separate and identify individual downloads being conducted by a single computer.

The right-hand chunk is the "computer ID" which is, according to RealNetworks, based upon a Globally Unique ID (GUID) and is used to uniquely identify the computer into which RealDownload has been installed. 9B145049   5BF211D4A025002018252799 9B1450495BF211D4A025002018252799

When I was re-examining the RealDownload system on Monday, July 17th, something caught my eye that I had missed on the previous Friday:

RealNetworks' repetitious assertions that it is NOT POSSIBLE for them to associate our RealDownload mediated downloads with our actual identity, or that no "personally identifiable information" is transmitted without our informed consent, appear to be no more correct than their previous assertions about the lack of RealDownload's ID tagging.

Just so we're really clear here: I am NOT alleging that RealNetworks IS making this association. I have no evidence of that one way or the other. But I AM proving that they absolutely COULD if they chose to. Furthermore, for some reason which is not known to me, they have repeatedly stated that they CAN NOT.

MAC source address: 00-20-18-25-27-99
MAC dest address:   00-90-7F-01-21-E8
Frame type:         IP
Protocol:           TCP->HTTP
Source IP address:  207.71.92.206
Dest IP address:    208.147.89.135
Source port:        1108
Destination port:   80
SEQ:                3074088
ACK:                3078494647
Packet size:        339

Packet data:
0000:  00 90 7F 01 21 E8 00 20 18 25 27 99 08 00 45 00 ....!.. .%'...E.
0010:  01 45 1E 0A 00 00 40 06 05 79 CF 47 5C CE D0 93 .E....@..y.G\...
0020:  59 87 04 54 00 50 00 2E E8 28 B7 7E 19 B7 50 18 Y..T.P...(....P.
0030:  FF FF 05 FB 00 00 47 45 54 20 2F 61 64 73 2F 68 ......GET /ads/h
0040:  6F 75 73 65 5F 6A 75 6B 65 62 6F 78 31 2E 67 69 ouse_jukebox1.gi
0050:  66 20 48 54 54 50 2F 31 2E 31 0D 0A 41 63 63 65 f HTTP/1.1..Acce
0060:  70 74 3A 20 2A 2F 2A 0D 0A 41 63 63 65 70 74 2D pt: */*..Accept-
0070:  4C 61 6E 67 75 61 67 65 3A 20 65 6E 2D 75 73 0D Language: en-us.
0080:  0A 41 63 63 65 70 74 2D 45 6E 63 6F 64 69 6E 67 .Accept-Encoding
0090:  3A 20 67 7A 69 70 2C 20 64 65 66 6C 61 74 65 0D : gzip, deflate.
00A0:  0A 55 73 65 72 2D 41 67 65 6E 74 3A 20 4D 6F 7A .User-Agent: Moz
00B0:  69 6C 6C 61 2F 34 2E 30 20 28 63 6F 6D 70 61 74 illa/4.0 (compat
00C0:  69 62 6C 65 3B 20 4D 53 49 45 20 35 2E 30 3B 20 ible; MSIE 5.0; 
00D0:  57 69 6E 64 6F 77 73 20 39 38 3B 20 44 69 67 45 Windows 98; DigE
00E0:  78 74 29 0D 0A 43 6F 6F 6B 69 65 3A 20 52 4E 45 xt)..Cookie: RNE
00F0:  63 6F 6D 6D 3D 76 65 72 32 2E 30 7C ?? ?? ?? ?? comm=ver2.0|xxxx
0100:  ?? ?? ?? ?? ?? ?? ?? ?? ?? 7C 53 74 65 76 65 7C xxxxxxxxx|Steve|
0110:  47 69 62 73 6F 6E 7C 4F 46 46 7C 39 58 33 47 38 Gibson|OFF|9X3G8
0120:  0D 0A 43 6F 6E 6E 65 63 74 69 6F 6E 3A 20 4B 65 ..Connection: Ke
0130:  65 70 2D 41 6C 69 76 65 0D 0A 48 6F 73 74 3A 20 ep-Alive..Host: 
0140:  69 6D 61 67 65 73 2E 72 65 61 6C 2E 63 6F 6D 0D images.real.com.
0150:  0A 0D 0A                                        ...

GET /ads/house_jukebox1.gif HTTP/1.1
Accept: */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt)
Cookie: RNEcomm=ver2.0|xxxxxxxxxxxxxxxxxx|Steve|Gibson|OFF|9X3G8
Connection: Keep-Alive
Host: images.real.com

Cookie: RNEcomm=ver2.0|xxxxxxxxxxxxxxxxxx|Steve|Gibson|OFF|9X3G8

I am guessing that the "RNEcomm=ver2.0" string stands for "Real Networks Electronic Commerce version 2.0".

The string of 'xxxxxxxxxxxxxxxxxx' shown above was, when captured on its way out of my computer, my personal and private eMail address alias which would have been used during an online eCommerce purchase. I hope that you (the reader) will understand that I desire to protect its privacy here even if RealNetworks hasn't.

The next two fields: "Steve" and "Gibson" are rather clear. If this isn't "personally identifiable information" being sent during the use of RealDownload, I can't imagine what would be.

I can't guess what the last two fields: "OFF" and "9X3G8" might refer to. But logic would indicate that the "9X3G8" is an identifier which refers in some way to my past purchase of "Real Producer" which the RealNetworks technical manager concluded was the event which planted this very persistent cookie onto my computer for subsequent re-transmission at various odd (and in some cases potentially awkward — and certainly non-anonymous) moments . . . such as whenever using their supposedly anonymous RealDownload agent.

Because this represents an extremely great concern for all of us, and especially for privacy advocates, I want to be very clear again that I am not alleging that such associating of these two separate communications IS being done, but only that RealNetworks' repeated assertion that it COULD NOT BE DONE, appears to be patently false.



Dissecting Smart Download's Packet Traffic

After installing Netscape's Smart Download utility, I clicked on a web link to download the file "tip.exe" from my server at "grc.com". The following TCP/IP data packet was immediately sent out of my computer to one of Netscape's servers:

MAC source address: 00-20-18-25-27-99
MAC dest address:   00-90-7F-01-21-E8
Frame type:         IP
Protocol:           TCP->HTTP
Source IP address:  207.71.92.206
Dest IP address:    207.200.75.206
Source port:        1041
Destination port:   80
SEQ:                330513
ACK:                750466305
Packet size:        450

Packet data:
0000:  00 90 7F 01 21 E8 00 20 18 25 27 99 08 00 45 00 ....!.. .%'...E.
0010:  01 B4 9C 00 40 00 80 06 15 97 CF 47 5C CE CF C8 ....@......G\...
0020:  4B CE 04 11 00 50 00 05 0B 11 2C BB 35 01 50 18 K....P....,.5.P.
0030:  22 38 44 F5 00 00 47 45 54 20 2F 63 67 69 2D 62 "8D...GET /cgi-b
0040:  69 6E 2F 73 64 5F 73 65 72 76 65 72 2E 63 67 69 in/sd_server.cgi
0050:  3F 70 6C 61 74 66 6F 72 6D 3D 77 69 6E 39 38 26 ?platform=win98&
0060:  76 65 72 73 69 6F 6E 3D 31 2C 2B 31 2C 2B 30 2C version=1,+1,+0,
0070:  2B 36 36 26 75 72 6C 3D 68 74 74 70 25 33 41 25 +66&url=http%3A%
0080:  32 46 25 32 46 67 72 63 2E 63 6F 6D 25 32 46 66 2F%2Fgrc.com%2Ff
0090:  69 6C 65 73 25 32 46 74 69 70 2E 65 78 65 26 4B iles%2Ftip.exe&K
00A0:  65 79 3D 42 52 55 4E 4F 33 39 36 44 46 32 37 33 ey=BRUNO396DF273
00B0:  20 48 54 54 50 2F 31 2E 30 0D 0A 50 72 61 67 6D  HTTP/1.0..Pragm
00C0:  61 3A 20 6E 6F 2D 63 61 63 68 65 0D 0A 43 6F 6E a: no-cache..Con
00D0:  6E 65 63 74 69 6F 6E 3A 20 4B 65 65 70 2D 41 6C nection: Keep-Al
00E0:  69 76 65 0D 0A 55 73 65 72 2D 41 67 65 6E 74 3A ive..User-Agent:
00F0:  20 4E 65 74 5A 69 70 2D 44 6F 77 6E 6C 6F 61 64  NetZip-Download
0100:  65 72 2F 31 2E 30 2E 36 32 20 28 57 69 6E 33 32 er/1.0.62 (Win32
0110:  3B 20 44 65 63 20 20 37 20 31 39 39 38 29 0D 0A ; Dec  7 1998)..
0120:  48 6F 73 74 3A 20 63 67 69 2E 6E 65 74 73 63 61 Host: cgi.netsca
0130:  70 65 2E 63 6F 6D 3A 38 30 0D 0A 52 61 6E 67 65 pe.com:80..Range
0140:  3A 20 62 79 74 65 73 3D 30 2D 0D 0A 41 63 63 65 : bytes=0-..Acce
0150:  70 74 3A 20 2A 2F 2A 0D 0A 41 63 63 65 70 74 2D pt: */*..Accept-
0160:  4C 61 6E 67 75 61 67 65 3A 20 65 6E 0D 0A 41 63 Language: en..Ac
0170:  63 65 70 74 2D 43 68 61 72 73 65 74 3A 20 69 73 cept-Charset: is
0180:  6F 2D 38 38 35 39 2D 31 2C 2A 2C 75 74 66 2D 38 o-8859-1,*,utf-8
0190:  0D 0A 43 6F 6F 6B 69 65 3A 20 55 49 44 43 3D 32 ..Cookie: UIDC=2
01A0:  30 37 2E 37 31 2E 39 32 2E 32 30 36 3A 30 39 36 07.71.92.206:096
01B0:  33 35 33 33 30 30 32 3A 32 33 38 32 31 31 0D 0A 3533002:238211..
01C0:  0D 0A

This rather intimidating looking hexadecimal data block (above) can be easily "parsed" into something far more intelligible. Breaking the block of ASCII text (over in the right hand column) into individual lines, and translating the "URL Encoding" (those %3A and %2F which mean ":" and "/" respectively), the first long line we see, which is the "command" given to the Netscape server, is:

GET /cgi-bin/sd_server.cgi?platform=win98
&version=1,+1,+0,+66&url=http://grc.com/
files/tip.exe&Key=BRUNO396DF273 HTTP/1.0

This long line can then be further broken down into its various components:

GET /cgi-bin/sd_server.cgi
platform=win98
version=1,+1,+0,+66
url=http://grc.com/files/tip.exe
Key=BRUNO396DF273 
HTTP/1.0

The balance of the data transmitted consists of the additional information "parameters" shown below:

Pragma:          no-cache
Connection:      Keep-Alive
User-Agent:      NetZip-Downloader/1.0.62(Win32;Dec 7 1998)
Host:            cgi.netscape.com:80
Range:           bytes=0-
Accept:          */*
Accept-Language: en
Accept-Charset:  iso-8859-1,*,utf-8
Cookie:          UIDC=207.71.92.206:0963533002:238211

The complete URL of the file I downloaded was sent to Netscape: "url=http://grc.com/files/tip.exe". Netscape thus knows what site I was visiting and what file(s) I clicked on to download.

My machine and I have been "tagged" by the "Key" of: "BRUNO396DF273"

Interestingly, "Bruno" is the name of the machine I used for this testing. So, the machine's name is being sent as part of my "ID". Also, I performed this experiment SEVERAL TIMES, shutting down the machine and rebooting . . . and the key's value never changed. Thus, it is clearly serving as a "persistent tag" and is being used to uniquely identify me from one use of the download utility to the next.

After seeing the "BRUNO396DF273" tag being sent, I searched the Windows Registry for that tag string. I found it in my machine's Registry at:

HKEY_LOCAL_MACHINE\Software\Nsda\1.1\Options\UserID

This makes it pretty clear that the tag is, indeed, a persistent "UserID" (by their own label) which has been assigned to my machine for the purpose of long-term, unique, identification.

Note that any time Netscape (or anyone else) ever wants to, they could access that public registry key and immediately tie me, and this machine, to my entire past download history.

IMPORTANT!: Users of Netscape's Smart Download utility, who unwittingly joined Netscape's "NetCenter" system, are especially at risk of privacy violation because NetCenter members also have their NetCenter logon ID and their personal eMail address sent with each file download report!

So much for never including any "personally identifiable" information. This means that the user's NetCenter logon ID — many people simply use their names — and eMail address are both being transmitted along with the name of every file downloaded by Smart Download.

And finally ... check out the "Cookie" field that is being sent! (It is the last field of the last group above.) The glob at the end includes encoded date and time information, but immediately after the "UIDC=" is my machine's IP address!! So Netscape apparently thought that would be a good thing for them to have also.

Since it's in a "cookie" field, it will pass through "anonymizers", "proxies", and NAT routers, which would otherwise obscure the user's true IP address. In other words, since the machine's own IP address has been included in this "cookie", using the Internet through an "IP anonymizing service" will NOT prevent Netscape/AOL from learning the machine's TRUE IP. Netscape receives it directly from their software running in the user's computer.

I am not a Netscape or RealNetworks programmer, so I can only go by the evidence presented through an analysis of the available data.

For most people, the main issue revolves around whether or not a report of every file downloaded with those utilities is transmitted back to their home base . . . and there's just no question any longer that unless deliberately disabled by the user, this is being actively done. If that bothers you, you may wish to immediately remove these downloading tools from your system.

An additional privacy risk involves whether, to what degree, and to what end, historical file downloading profiles are being compiled about individuals, whether or not they are known by name and address and "personally identifiable."

Netscape has been completely silent on this issue, whereas RealNetworks has gone absolutely ballistic over my pointing out what it has apparently lied about and what it could be doing with the data that has been sent to its servers. As I have repeatedly stated, I have no evidence, information, or knowledge either way. But trust is what it all boils down to, and RealNetworks' record on that score seems to be getting shakier with every passing day.

I can only address that larger question by asking: "If these companies do not care about us in any unique way — separate from everyone else (as they claim) — then WHY are they going to all the trouble of uniquely tagging every user's computer and deliberately transmitting not only that unique ID tag, but also — in the case of Netscape — sending the user's Internet IP address with each and every download file report?" This is not required for the purpose of identifying what files are downloaded "in aggregate", or learning when their downloading program is installed or removed from the host computer . . . contrary to what seems to be stated in their various license agreements.

One Final Observation:

The stated purpose behind all of this download profiling (in their respective licenses) is to inform these vendors about the files we are all (collectively) downloading so that they can provide some sort of additional, useful, or auxiliary information to us (this is never really made clear). Yet, the date shown for the NetZip Downloader (version 1.0.62 — which was captured in the outbound TCP/IP data packet shown above) is December 7th of 1998. So, this data gathering has presumably been underway since before that date. That's been quite a while.

When does the payback for all these years of "aggregate" user profiling begin? And who receives the value? And, moreover, given the highly dynamic nature of Internet content, does the whole idea of collecting such data really make any sense anyway?

It makes one wonder what's really going on here . . . doesn't it?



Certainly Newsworthy . . .

Frankly, once all of the facts are exposed and aired, I wouldn't blame anyone for being quite upset by the whole story. We now know, with absolute certainty, that more than 14 million NetZip Download Demon users have been misled by the product's license agreement. And it is this deceived "asset base" which RealNetworks recently purchased. How nice.

So, it's hardly surprising that the online news media has picked up on and reported the news of a Class Action Lawsuit brought against Netscape/AOL over their Smart Download spyware. These stories provide some additional background information about the secret spying activities of these programs:

So, if you are a newcomer to this site and are not already a subscriber to our GRC Corporate News Blog, you might want to consider subscribing (just click the link.) As detailed in our formal Privacy Statement, your eMail address will never be disclosed, and you are completely free to remove yourself from the system if you ever choose to.



For Further Discussion . . .

My findings and the questions they raise — about the behavior of the Netscape/Real Networks/NetZip download utilities — were first disclosed to members of our eMail Notification System. Many of these people, and others, are discussing their concerns and news about this and similar Spyware concerns in our "grc.spyware" discussion forum. If you are interested in learning more, please see our Discussions page for some orientation about our discussion groups, detailed instructions, and links.

And thanks very much for your interest and continued support of my work!