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

Re: RFC2109 addition...

From: Jonathan Stark <stark@commerce.net>
Date: Tue, 25 Mar 1997 00:51:32 -0800 (PST)
Message-Id: <199703250851.AAA29785@boa.commerce.net>
To: "David W. Morris" <dwm@xpasc.com>
Cc: stark@commerce.net, http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/2874

Dave Morris said:
> On Mon, 24 Mar 1997, Jonathan Stark wrote:
> > Quoting Dave Morris:
> > > On Mon, 24 Mar 1997, Jonathan Stark wrote:
> > 
> > default, or even being prompted to accept a cookie (which incidently,
> > in many cases is likely to be the EXACT same cookie that they're investigating
> > the policies on), is a little bit crazy.  You should NEVER be prompted
> > about whether or not you want to accept a cookie when investingating
> > the policy behind another cookies use.  Since you shouldn't be prompted,
> > there needs to be a default "accept" or a default "reject".  In this
> > particilar case, I think a default "accept" would be irresponsible.
> I think this may present a wierdness, but one that the UI folks can deal
> with. (I've been told that they like challenges.) I think rather than
> forbidding such cookies, we should say something like:
>   1.  Servers should consider the UI dilemma when sending cookies with
>       the cookie explanation.

How would the server know?  The exact same document might be served
as part of the normal site on a privacy page that gets the default set
of cookies sent out with it.  (or more likely, images referenced in the 
cookie explanation document might be standard ones that get served all the 
time, like the companies name/logo).  If there's a choice between putting
the intelligence on the server or on the client side, I vote client.

>   2.  Warn UA implementors that a cookie may be included with the 
>       explanatory document and therefore recursive handling of the
>       document may be necessary.

Recursive handling is probably not the correct way to go, though.
Somewhere somehow a flag should get set such that you can't recursively
request the CommentURL, get a cookie on the CommentURL, intuitively
say, No, I don't want to accept the cookie I just asked for information
about without seeing the policy, request the exact same CommentURL
page again, get the same cookie again ... forever...  (Never underestimate
the stupidity of a fool when making something foolproof.)  But, once
again, this is pretty much up to the browser folks.

> I think its cleaner to not place the restriction on the response since
> we don't have any mechanism to tell the server of the restriction.

Why would the server NEED to know?  If the server "goofs", the client
just silently ignores it.  (And, incidently, doesn't this slightly
conflict with what you said above about having the server take special
steps when serving the cookie explanations?  How would it know it's
serving the cookie explanations?  By URL alone?  That seems a little
bit shaky to me.)

> In this UAHINT draft, I propose a popup window which differs mostly in 
> that it might not have the normal toolbar and has a notion of going away
> after the user has seen it.  I think such a mechanism would apply here.

That sounds quite appropriate.

> > I agree completely that language issues should be handled automatically
> > in the normal way, but what does that have to do with restrictions on
> > the URL, or with cookies?  Is there a method besides the proposed variant
> > list method (which I understood to be a httpd thing) that requires
> > cookies to be accepted in order to negotiate?  I don't recall seeing anything
> > in 2109.
> I don't recall any specific connection.  I brought up the language
> negotiation as a plus for your proposal and an argument for not handling
> the URL as a special case.

Sorry... my fault.  I misinterpreted your point.

> > I fail to see a huge value in putting a cookie on what should in most cases
> > be a static document describing policies.  It seems sort of hipocritical
> > to issue a cookie on a page that is supposed to help people decide
> > whether or not they want to accept a cookie.  But maybe I'm just looking
> > at this wrong.
> I think you are placing an unnecessary restriction on the URL. And as soon
> as it becomes a special case you must deal with what if a link in the
> page happens to have a cookie ... better to try and stay clean and avoid
> special cases.

Well, I would like to stay clear of special cases too, and would totally agree
with you if I thought there weren't the possibity for a situation where my 
mom would be frustrated for the rest of her life going back and forth between 
cookie dialog boxes and half-loaded CommentURL pages (Stuff like that ALWAYS
ends in a very confused phone call to me.) :)  But maybe we're picking
nits.  The folks at Netscape, Microsoft, etc etc etc are sharp enough
to make sure that doesn't happen, right?  (Making products mom-proof
is certainly one of those challenges they're looking for!)

> I do agree that I see not much value in having a cookie associated with
> the policy document and I suspect with the right warning most servers
> won't do it. But by allowing the case, we cover the LINK from that
> document where it seems morelikely that a set cookie will be encountered.

It seemed that by just having the client ignore them by default,
the server wouldn't have to worry about any special cases.  After all,
these documents (and especially images) may be perfectly fair game for
cookies under normal situations.  Only when evaluating whether or not
to accept cookies does the recursive problem really get nasty.

> Also, if a cookie can't be set on the commentURL, can one be sent with the
> request. I make the same argument ... keep the protocol clean and not
> care.

Hmm.. that's an interesting point.  I would say yes, a cookie should
be able to be sent with the request.  At that point, you've already accepted
the cookie (for whatever reason), and should send it off. My big concern
is more in the craziness of being prompted to accept a cookie while trying
to figure out the purpose of that exact cookie from a previous request.

> > Perhaps, though I could see a user getting completely lost in windows
> > if there isn't something to uniquely identify this window, or a way
> > of requiring a decision on the cookie issue before continuing.  I personally
> > hate when a web page forces me to open a link in a new targeted window.
> I don't object to differentiation in the window ... and I don't see any
> difference between a special window and a new targeted window. 

I guess it's, once again, a UI issue that we probably shouldn't worry about.

You've brought up some excellent points!  Thanks!

Received on Tuesday, 25 March 1997 00:49:57 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:01 UTC