W3C home > Mailing lists > Public > www-talk@w3.org > January to February 1997

Re: errata for cookie spec

From: Jeremey Barrett <jeremey@veriweb.com>
Date: Fri, 7 Feb 1997 01:23:34 -0800 (PST)
Message-Id: <199702070923.BAA15720@descartes.veriweb.com>
To: koen@win.tue.nl
CC: ruby@name.net, www-talk@w3.org
Cc: jeremey@veriweb.com

> Matthew Rubenstein:
> [...]
> >        Domains' cookies should be partitioned from one another. However,
> >preventing a domain from sending its cookie to another domain's server for
> >parsing only forces the sender to use out-of-band communication between
> >servers - higher cost, especially in syncing the timing with the user's
> >navigation between the servers.
> This higher cost and difficulty of syncing is not a bug, it is a feature!
> And this syncing is going to get more difficult still when we get country
> level proxies.
> Servers have no business sharing information without the user's consent, and
> I therefore see not reason why sharing information in a sneaky way should be
> particularly cheap or easy.  If they want to share, let them embed the info
> in a link where the user can see it.

Exactly. The user-agent is the _user_ _agent_. Not the server agent.
Obviously the user-agent needs to give _some_ information to servers,
else they could not function. Cookies provide this. But the user-agent
should serve the interests of the user, and they are _not_ served by
allowing hidden tracking of users across sites. I can think of _no_
other application of the "container document from site A containing img 
sent out by a CGI from site B which also happens to set/retrieve cookies"
scheme. If one does arise, well the behavior should be configurable.

BTW, for those looking to avoid the all images on altavista, including
some from doubleclick.net which set/retrieve cookies _and_ get your query
sent to them, use this instead:


> >Matthew Rubenstein                     North American Media Engines
> Koen.

- -- 
Jeremey Barrett                                  VeriWeb Internet Corp.
Senior Software Engineer                         http://www.veriweb.com/

PGP Key fingerprint =  3B 42 1E D4 4B 17 0D 80  DC 59 6F 59 04 C3 83 64

Version: 2.6.2
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

Received on Friday, 7 February 1997 04:23:52 UTC

This archive was generated by hypermail 2.4.0 : Monday, 20 January 2020 16:08:21 UTC