Re: Comment-URL question

On Mon, 28 Jul 1997, Ted Hardie wrote:

> On Jul 28,  6:15pm, Dave Kristol wrote:
> 
> > The CommentURL mechanism assists the user in making a decision.  With
> > that in mind, the answer to your questions is, I think, the UA tells the
> > user what happened.  If we're talking about an inspection mechanism at
> > "the port of entry" (when a cookie accompanies a new page and before the
> > user has viewed the page), the user probably has a choice of whether or
> > not to accept the cookie.  Examining the comment URL is a way for the
> > user to make an informed choice.  If the UA reports it can't fetch the
> > CommentURL, the user still has that choice, just with less information
> > than s/he hoped for.
> 
> I understand that the comment URL is not meant to be a true
> verfication mechanism, but, like Larry, I worry that the percentage
> gain in providing it may not match the cost.  To deal with a comment
> URL we will already need advice/rules about providing cookies with the
> resource referenced in the comment URL.  I was trying to point out
> that we might also need advice/rules about how to treat the open
> connection to the original resource during an inspection.  If
> inspections are common, we could be asking servers to hold open a
> large number of persistent connections while a relatively slow thing
> (a user inspection) happens.  That has a cost.  If the connection is
> maintained by the UA "pinging" the server with a HEAD, we've also got
> bytes on the wire that impact everybody and aren't actually sending
> information anywhere.
> 
> In contrast, if we don't provide that advice and connections normally
> close while inspections occur, there are consequences either to how
> cookies are created (so that the same client is highly likely to get
> the same cookie back on a request made in a short time frame, rather
> than highly unlikely as now) or how the UA manages the relationship
> between the approved inspection and the cookies it receives.

First, I would hope, though I must admit I've not tested the question,
that UA would receive the complete response w/o consideration for 
whether the user wished to accept the cookie. It would be bad programming
to keep the connection open while asking the user about accepting the
cookie, in particular since there is no suggestion in the cookie
inspection UIs I've used or in the cookie spec that the response should
be suppressed if the user suppresses the cookie. This is already an issue
if the UA cookie dialogs hold the connection open waiting for user
interaction so I don't see it as a significant change in the status quo.

> Frankly, I'm not sure that all of the management cost and user
> education cost is worth the marginal (and hopefully short-term) gain.
> I fully support inclusion of comments which indicate certification or
> even asserted well-known policies.  But doing this with
> individually-inspectable URLs does not seem to be a clear win to me.

Individual URLs are the lingua franca (sp?) of the web. As I've said
before, I'm not convinced that the whole official IETF cookie
definition provides much gain over cost when we consider the real
possiblity that the vast majority of users won't have the opportunity
to use the facilities and protections we've crafted.

But we've defined a baseline. Part of our argument has been for
informed consent. It is hard to argue in my mind that we support
informed consent when the only protocol supported mechanism for 
communication between the application/server and the user is a 
comment string.  URLs are the mechanism of information on the WEB and
as such are the 'right' approach here as well.

> I worry in particular that allowing such URLs will encourage every
> corporate lawyer to have a policy, rather than relying on well know
> policies; that is, admittedly, probably paranoid, but I was raised by

If you grew up with lawyers, then you know that getting two lawyers
to agree on sharing a single well known policy is even harder than
getting an IETF working group to produce a cookie standard, probably
by several orders of magnitude. So we can expect lawyers to insist
on having their own statement.

> lawyers and I know how they can think.  Given the ease of changing
> resources on the web, I would also want to be able to do a HEAD
> against the policy in a comment URL once every session I interacted

With a URL to check and track, you would at least be able to use existing
automated tools which will check web resources for change. W/o the URL,
the only choice would be to read each comment value, which if it was
several lines long, might have a subtle change you'd never see. 

> with the resource, just to be sure the policy hadn't changed.  (Note
> that I do not say I would always use that ability, just that I would
> want *at least* that ability).  If even a small percentage of the net
> behaves as I would, we have a lot of additional overhead.

The difficultly is that I believe it unlikely that a comment value will
be changed when the policy changes ... comment values will be buried in
code unrelated to policy implementation ... code which is on the front
line which if not updated carefully could cause breakage. So I'm a
real skeptic when it comes to believing the comment. I also know it would
be impossible to find a cookie policy on most web sites so the commentURL
allows a protocol defined interoperable mechanism for connecting the
cookie to whatever descriptive material the publisher wants the user
to see.

I think the main benefit of everything we're currently doing with Cookie2
is to provide a foundation upon which something like Dan Jaye's proposal
can build. I believe CommentURL fills a critical gap and complements
Dan's proposals.

Dave Morris

Received on Monday, 28 July 1997 23:55:25 UTC