Re: errata for cookie spec

Matthew Rubenstein wrote:
> 
> 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.
> 
>         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>.". 

I didn't know we were discussing your capabilities as a web site creator.

However, the kind of usage you are talking about is not covered at all by
the proposed wording changes.  Provided that all the scripts are being
served from the same machine (or machines in the domain quoted in the
Set-Cookie header) you aren't affected.  


> Then we began to use cookies to store Java applet
> state between invocations.

What kind of size of data are we talking about here?  

> 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".

In what way does refusing a cookie fail to keep any info private? 

OK.  We'll change the messages in browsers to say privacy instead of
security.  Problem solved?  Actually it's not that simple, since Referer
headers can be used to get around the need for cookies at all if you're
trying to track user trails (like doubleclick.com mentioned above).

In my opinion, the risks are reduced quite a lot provided the client uses
the domain rules correctly, however, they are not by any means eliminated.

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

I thought that the major application of cookies would be to allow client
state to be help server side in a database and the cookie used as a key to
retrieve state when required.  Obviously depends on the size of the
state, though.  I don't fancy having an extra 16K of download just to save
you a bit of trouble storing it in a database and sending me the key.


> 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).

If I don't sent you a cookie, you can't pass it to anybody who I wouldn't
want it to be passed to.  I may decide that I trust you not to pass it on.
Chances are that if I'm paranoid, I don't trust you and I disable all
cookies.

If I have some level of assurance (due to the domain attribute for
Set-Cookie) that my user agent won't pass the cookie to somewhere else
without my consent, I'm likely to be a bit happier and may choose to
enable cookies.


>         The primary victims of eviscerating this symmetrical client/server
> state architecture is the "small developers", and their users.

Don't agree. The primary victims of enforcing strict rules on cookie
sharing are professional spamming companies and other people building
up private databases about user habits that they have no right to know
about.

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

Sites use cookies & referer NOW to abuse client privacy.  Getting the
rules for rejecting cross-domain cookies right will mean that users can
accept cookies provided they accept that the cookie can be passed to
servers in the quoted domain and will enable small non-commerical, RAD,
tight budget sites to use cookies.

I've had a look at www.doubleclick.com - the example mentioned at the
top - (with images & referer: & from: & cookies disabled).  I'm
absolutely certain that I don't want any cookies sent to
www.doubleclick.com when I view other sites.  I've now got an entry in my
web killfile for the domain doubleclick.com that blocks any requests
being sent to it.  I certainly don't want any cookies sent to it for them
to store away and profile me with.

-- 
Stewart Brodie, Electronics & Computer Science, Southampton University.
http://www.ecs.soton.ac.uk/~snb94r/      http://delenn.ecs.soton.ac.uk/

Received on Thursday, 6 February 1997 11:51:40 UTC