W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1997

Re[2]: errata for cookie spec

From: Eric Holstege <Eric_Holstege@broder.com>
Date: Thu, 6 Feb 1997 09:35:12 -0800
Message-Id: <0000C9CC.1407@broder.com>
To: Fisher Mark <FisherM@is3.indy.tce.com>, Matthew Rubenstein <ruby@name.net>
Cc: Dave Kristol <dmk@research.bell-labs.com>, Benjamin Franz <snowhare@netimages.com>, HTTP Working Group <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>, www-talk <www-talk@www10.w3.org>
Hooray, finally some sense. Practically every application in the world stores 
information on the user's hard drive. A web site today is nothing more than an 
application that happens to run partly on a server. 

The data that can be stored by a web site with cookies on the user's hard drive 
is so trivial compared to the data that *could* be stored by any retail 
application as to not be worth worrying about. Yet there is a big hullabaloo 
about cookies and none about the fact that Microsoft Internet Explorer gets to 
see every URL and every keystroke (and no, I don't think *it* does anything 
scary with this information either). 

Unlike with a retail application (or an ActiveX applet), you can't use cookies 
to read arbitrary files from the user's hard drive, despite what we have read 
from time to time in otherwise reputable magazines.

Furthermore, unless *you* volutarily type in your real name and address, all 
that can be tracked with cookies is what your *browser* did. Any connection to a
real, specific human is entirely voluntary.

Cookies are currently the only efficient way to implement many of the functions 
and features that commercial web sites need to provide. 99% of the web users out
there just want to get on with their browsing and this scare about cookies is 
just causing confusion and delay in making real useful web applications.


All that said, I do think that loopholes that allow a server in one domain to 
read cookies supposedly only available to another domain violates the basic 
security idea of cookies and should be prevented.

I don't like waiting for or looking at banner ads any more than anyone else, 
but, as for Doubleclick, it sell ads. Ads give sites revenue. This allows sites 
to do more neat stuff and provide better service to customers, i.e., us. 
Doubleclick's ability to track demographics means they can charge more for their
ads, which means more site revenue, more neat features and better service to us.
More power to them.


______________________________ Reply Separator _________________________________
Subject: Re: errata for cookie spec
Author:  Matthew Rubenstein <ruby@name.net> at Internet
Date:    2/6/97 10:45 AM


At 09:59 AM 2/6/97 EST, Fisher Mark wrote: 
>
>Benjamin, you wrote:
>>This needs to be strengthened. This is *ALREADY* a major problem, 
>>with a number of 'banner services' such as 'doubleclick.com' currently 
>>exploiting inlined images to track people across domains. Perhaps 
>>something like 'User agents MUST NOT allow the setting of cookies
>>on inlined or embeded objects if the enclosing document and the inlined or 
>>embedded object would be precluded from directly sharing a cookie by the 
>>other domain exclusion rules.' should be added to 4.3.2.
>
>I think this is a little strong.  I would prefer something like: 'By 
>default, user agents MUST NOT allow the setting of cookies on inlined or 
>embedded objects if the enclosing document and the inlined or embedded 
>object would be precluded from directly sharing a cookie by the other domain 
>exclusion rules.  User agents SHOULD allow turning off this option for the 
>cases where cross-domain cookie sharing is appropriate.'  (Off hand, I don't 
>know of any cases of appropriate cross-domain cookie sharing, but these may 
>come up in an Intranet environment.)
>
>BTW, the silent rejection of cookies, esp. by domain name, is a good idea.

        I've been tracking the progress of this thread, which gives a good
insight into the specifiers' position on when to deny storing of cookies for 
"security reasons". I will add that I have been doing so by watching the 
messages accumulate in quoted responses, rather than storing in my RDBMS and 
querying for status.

        As a WWW developer since 1994, I was relieved by the arrival of
cookies as a client state storage mechanism. No longer would I degrade 
performance or double app development time by having a dozen HTML files 
returned by a separate CGI, merely to preserve the PATH_INFO or QUERY_STRING 
stored state in every URL embedded in the returned file, just to preserve 
the user's entered name from the first application page to the last, where 
we say "Goodbye, <name>.". Then we began to use cookies to store Java applet 
state between invocations. Client state storage is now a cornerstone for 
most serious applications. Suggestions from the UA that the user turn off 
cookies for "security" merely break these apps, while keeping failing to 
keep any info "private".

        Client state that might be stored in a cookie can be exactly
replicated by having user authentication via htauth or otherwise, and 
storing state in a server DB. Cross-domain cookie sharing can be performed 
via any server peer-peer communication, from Notes Replication to email. The 
illusion of "anonymity" only makes it more likely that someone will do 
something "infamous" (in the limited domain of the Web).

        The primary victims of eviscerating this symmetrical client/server
state architecture is the "small developers", and their users. As indicated, 
the functionality of cookies can be replicated by applying URL-encapsulated 
state, server DB storage and inter-server messaging. However, these 
techniques have higher cost to apply than cookies. So "small", 
"non-commercial", "rapid application development" or "tight budget" sites 
will be forced back into a class of lower functionality. Sites fueled by 
large budgets will continue to "violate the security" of their users, thereby 
delivering interactive, mass-customized, first-class apps.

        Let's keep "security" meaning access authorization to systems, and
"privacy" meaning access authorization to info about actions taken. By 
crippling cookies, we're not protecting the user from apps. If anything, 
we're only protecting big-budget developers from small-budget developers - 
who are responsible for most of the interest in the Web as a new publishing 
medium.


>fisherm@indy.tce.com                   Indianapolis, IN 
--
Matthew Rubenstein                     North American Media Engines 
Toronto, Ontario   *finger matt for public key*       (416)943-1010

               They also surf who only stand on waves.
Received on Thursday, 6 February 1997 10:02:15 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:26 EDT