W3C home > Mailing lists > Public > www-talk@w3.org > March to April 2000

Re: Security: Cookies

From: Kevin J. Dyer <kdyer@draper.com>
Date: Mon, 20 Mar 2000 12:09:35 -0500
To: Clover Andrew <aclover@1VALUE.com>, "'www-talk@w3.org'" <www-talk@w3.org>
Message-id: <4.2.2.20000320110209.00d0dd40@imap>
At 08:53 AM 3/20/00 , Clover Andrew wrote:
>Kevin J. Dyer <kdyer@draper.com> spake thusly:
>
> > But the cookie can only travel from the User Agent to www.a.com or if
> > it was set as a domain cookie all of a.com or conversely b.com.
>
>Yes, the cookie is set on b.com. The user simply doesn't realise that
>any information has been sent to b.com because the URL bar says a.com.

You shouldn't be able to plead ignorance here.  How it works has been well
documented over the last 7+ years.  I'll grant you that a large portion of the
public still thinks it's some sort of magic and we do need to have the
User Agent defaults set to a more sheltered mode vs a most promiscuous
mode.  The servers and agents do not give out any more information
than they are told about, in theory.  So don't enter "private" information 
onto
a website if you want it to stay "private".

> > Unless you have given a.com and b.com specific information that they
> > can place in their cookies.
>
>The information is something you don't have to give, because it is
>inherent in the request: the URI of the document on a.com. It's
>clear that a.com needs to know this to service the request, but it
>often then passes the information along to b.com by embedding that
>information in part of a URI your browser will proceed to request
>from b.com. Typically this is done in the query-string of an
><img> src attribute.

It doesn't have to stop at an <img>, any href or src is susceptible.  But
IMHO, you are throwing the baby out with the bath water.  Right now
and for the foreseeable future a ticket or token embedded in a URI
to b.com, generated by a.com, is the best way to transfer viable
initial session information between loosely federated domains.
Like it or not what we are seeing is a loosely federated system
of data collection.  It is a collaboration between those that maintain
the origination servers and the banner advertisers.

>So then your browser sends something that identifies you to b.com
>(the cookie) and something that identifies what you are doing on
>a.com (the URI) to the unrelated site b.com.
>
>This is badness.

I don't disagree with you, but don't forget that even if a.com didn't
add anything to the URI to b.com.  Your own User Agent can and
usually does send a Referer: header up with the request.

We also have to look at it from the other side as well.  We can not
stop someone from "legally" collecting data, statistical or directed,
data from your, known or anonymous, clicking around the web.

As you pointed out, companies like double-click have amassed
significant relational databases on our travels about the public
web.  Some statistical, some directed that would give someone
insight into your buying, social, or other deviations.  If you look at
how you spend, plastic or store discount cards, they are gaining
directed insight into your buying, social, or other deviations, with
your full knowledge.  What's the difference?


>--
>Andrew Clover
>Technical Support
>1VALUE.com AG

===========================================================
Kevin J. Dyer				     Draper Laboratory  MS 35
Email: <kdyer@draper.com>		     555 Tech. Sq.
Phone: 617-258-4962			     Cambridge, MA 02139
FAX: 
617-258-2061                                   http://www.draper.com 

---------------------------------------------------------------------------- 
------------------------------------------
	    _/_/_/_/    _/          _/  _/  _/        _/     _/_/_/_/
	   _/      _/   _/_/     _/_/  _/  _/_/     _/   _/
	  _/       _/  _/ _/   _/ _/  _/  _/  _/   _/    _/_/_/
	 _/      _/   _/  _/ _/  _/  _/  _/    _/ _/            _/
	_/_/_/_/   _/    _/    _/  _/  _/        _/  _/_/_/_/
        Data Management & Information Navigation Systems
=========================================================== 
Received on Monday, 20 March 2000 12:10:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 27 October 2010 18:14:24 GMT