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:05:38 -0800 (PST)
Message-Id: <199702070905.BAA15404@descartes.veriweb.com>
To: ruby@name.net
CC: www-talk@w3.org
Cc: jeremey@veriweb.com
-----BEGIN PGP SIGNED MESSAGE-----


> >Misinformation about the privacy risks of cookies is very damaging to 
> >the many legitimate applications that require them. However, I know
> >of _no_ case where as an application developer or a user I would want 
> >a user-agent to send cookies to a domain that does not match that of 
> >the enclosing document.
> >
> >This should be configurable of course, perhaps with the ability to block
> >cookies to particular sites.
> >
> >Maintaining privacy does _not_ break legitimate apps, in fact it makes them
> >less likely to break. Currently, many people turn off cookies altogether
> >in fear of the privacy risks. Certainly that will break cookie-requiring
> >apps.
> 
>         We're in complete agreement. I didn't say that UAs should allow any
> receiving "domain" access to cookies stored by another; _that_ access could
> be a security breach. A domain can encrypt the cookie and "secure" the data
> from everyone: this technique can be employed to keep a usage counter
> current and accurate, in spite of attempted user intervention.

The worry is not a cookie leaking from one domain to another, user-agents
already prevent that, but rather cookies being sent to domain B because 
of an object/image/what-have-you embedded in document A from a different 
domain than B.

> 
>         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. Whether this feature is outside the scope of
> a data format/protocol for recording domain-specific state is a valid
> concern to implementors of the UA, but end-runs around its intended
> "security" (acually privacy) aspect are so readily available that it merely
> shuts out legitimate developers with no appreciable gain.

I don't see your point here. Web server A in domain A cannot set a cookie
to be retrieved by server B in domain B. That's not up for debate, are
you proposing such should be allowed?

As far as communication from web server to web server (why?), it can
be done _much_ more efficiently via means other than HTTP. I don't
see why you'ld want to send a cookie from A to B _unless_ you were
implementing an information gathering/user tracking system. Perhaps
there are applications of this, but the privacy of the user is far
more important.

> 
>         We can all get what we want from cookies. Proprietary Net clients
> can save state; there's no reason to cripple the "universal client" that WWW
> UAs strive to be for no effective gains. 

Cripple it how?

The only thing we're talking about is forcing user-agents to by default
_not_ send cookies to domains which would be excluded from receiving
them by the normal cookie/domain rules as applied to the _enclosing_
document. i.e. ad.doubleclick.net can't get or set a cookie from an
<img> embedded in a web page on a different site.

- -- 
=-----------------------------------------------------------------------= 
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
=-----------------------------------------------------------------------=

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

iQCVAwUBMvrwVS/fy+vkqMxNAQHeswP/QNvhHhmjAkN7F2W9810MPjnrPk0iR5fI
Icnc8u/Zd45i9wukUKMELdERzmtyzMkPaytSprS6PgjCadEN00mo4bnJ5jnb6JkE
iBflEV1ejtHrNQwqIpemN3ltaPFl5QPeDAD9EUebrGVP5Sb8XdZDccn0cTXaD8F8
3OXVB0KU3Q4=
=jx8A
-----END PGP SIGNATURE-----
Received on Friday, 7 February 1997 04:05:45 GMT

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