From: Bill Stewart <stewarts@ix.netcom.com>
Date: Wed, 7 Aug 1996 20:24:07 +0800
To: cypherpunks@toad.com
Subject: Stealth cookies
Message-ID: <199608070259.TAA17434@toad.com>
MIME-Version: 1.0
Content-Type: text/plain



At 03:48 PM 8/5/96 -0400, Anne Eisenberg <aeisenb@duke.poly.edu> wrote:
>All of the discussion on the list to do with
>cookies is related to Netscape.  Does this mean that if one switches to
>Microsoft Explorer one can avoid the problem?  Many thanks.

MSIE also does cookies.  Netscape 3.0b5 has a nice option to let you
choose whether to accept a cookie or not.  However, what's the problem
you're trying to solve?  Sites have several ways to find out information
about you, which they can use immediately or coordinate with other things
0) Stuff the site knows about itself, like contents and time
1) Stuff you tell them by filling in forms
2) Your IP address (not always very useful...)
3) Information your browser sends (somewhat adjustable.)
4) Information your browser sends that a site asked you to keep for it
        (i.e. cookies.)

For the most part, this doesn't leak a lot of information;
even cookies can only pass things the sites already knew between sessions.
The cookie spec is well-designed, only allowing cookies to be retrieved
by the machine or domain that set them in the first place.

However, there's a way to cheat the cookie spec; I don't know
if this was intentional, but it was realized quickly by the market :-)
The issue is that your browser sends along an HTTP_REFERRER variable,
which points to the last page you visited before the current page.
It's useful for sites to find out where their pages are being referenced,
and they may (legitimately) want to only give out information if you're
coming from one of their previous pages.  This does also mean that
a page (www.alice.com/interesting.html) can hand its name to another page
or program (www.bob.com/cgi/count-stuff.pl)  by including an inline reference
to it.  But that site can send your browser a cookie marked bob.com, which is 
accessible by _it_, not by the referring page.  This means that 
if you later connect to www.carol.com/foo.html, which references bob's
count-stuff program, bob.com can retrieve the bob.com cookie that 
has information about your connection to alice.com.  If alice.com and
bob.com store some identifying information (e.g. alice.com records
a connection from 192.9.200.1 at 12:34:59 UTC, and bob.com records 
a connection from 192.9.200.1 at 12:35:01 UTC, and bob.com stores a reference
to that in the cookie (either storing the information directly, or more
likely, storing a record-id number referencing a database entry,
and carol.com and bob.com similarly share a reference, then alice, bob,
and carol can coordinate what happened in the two sessions.
Maybe Bob just knows that there's market correlation between viewers of
Alice's Brownie Company and Carol's Congressional Consulting, or maybe
they also share the credit card number, flavors, and addresses you gave
alice.com
with the search criteria you gave carol.com to find you've been donating
special brownies to that congresscritter you've been lobbying.
Without the cookie hack, the ability to correlate is limited to the
common information that you've given the two sites, which tells
them that some Netcom user with Mozilla 3.2b7.7 did it,
which isn't enough to run a targeted campaign donation request
or send out the FBI or whatever.

Doubleclick.com is the site that's wellknown for exploiting the feature,
and their web site is interesting.  If you're using 3.0b5, try
different combinations of accepting or rejecting cookie requests....

#			Thanks;  Bill
# Bill Stewart, +1-415-442-2215 stewarts@ix.netcom.com
# <A HREF="http://idiom.com/~wcs"> 	Defuse Authority!