W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1996

Re: draft-ietf-http-state-mgmt-01.txt LAST CALL

From: Benjamin Franz <snowhare@netimages.com>
Date: Fri, 14 Jun 1996 16:19:11 -0700 (PDT)
To: Koen Holtman <koen@win.tue.nl>
Cc: marc@ckm.ucsf.edu, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <Pine.LNX.3.93.960614154922.7265C-100000@ns.viet.net>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/938
On Sat, 15 Jun 1996, Koen Holtman wrote:

> Marc Salomon:
> >
> [On sharing of cookies across domains, in an earlier message:]
> >Sharing would be possible only when there were multiple domains in
> >the Set-Cookie header.  Sharing with permission is OK, but leaking is
> >bad.
> Whose permission: permission of the user or permission of service
> authors collaborating to do cross-server user tracking?
> Many end users are very concerned about the way current netscape
> cookies can violate their privacy expectations (there has even been a
> WSJ article about this: `Internet Users Say they would Rather Not Share
> the Cookies').  The state management draft tries to address these
> concerns by, among other things, limiting the possible sharing of
> cookies to one domain.
> While this limitation rules out some applications, as your example
> shows, it is necessary in order to address the privacy concerns.

I hate to rain on your parade - but you can't stop sharing of cookie info
across cooperating domains. At all. No matter _how many_ restrictions you
put on who clients give cookies to. If the *ONLY* possible way I could
inform another site of the contents of a cookie and who it belonged to in
my domain was to use HTTP state related headers - maybe. Or maybe not. I
think you radically underestimate the ingenuity of site authors. 

But I am not (as a site author)  limited to the HTTP state headers. If
nothing else I could open a private connection to another site to give
them the cookie information, and then boot a person using a Location
header with attached GET method data to identify them as the person I just
gave cookie data on so they can be matched to the cookie. I could even put
the cookie information in the URL I boot them over with.  Heck, if I
chained redirects I could probably do it all but invisibly in many

I could even not use offical cookies at all - instead just shoving all my
state tracking into the URLs:  the way *most* sites needing session
tracking do right now. Or I could use the IP address and other browser
identifying specifics to make a really good guess as to who is who and
pass all the matching information through a private 'out of band' channel
in advance. Utterly invisible and it can approach 100% accuracy - even
with proxy servers trying to mess things up.

Basically - you can achieve nothing except making me work *slightly*
harder to share information with a cooperating domain. If your cookie
headers won't do what I want - there are other headers I can mis-use quite
well.  The best you can hope to achieve is restricting the leaking of
cookie information between *non*-cooperating domains. Don't fool yourself
into thinking you can achieve any stronger protection than that:
You can't. 

Benjamin Franz
Received on Friday, 14 June 1996 16:22:17 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:17 UTC