Re: errata for cookie spec

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:52:28 UTC