Re: RFC2109 addition...

On Mon, 24 Mar 1997, Jonathan Stark wrote:

> 
> Quoting Dave Morris:
> > On Mon, 24 Mar 1997, Jonathan Stark wrote:
> > 
> > > Here's a first crack at the text as I feel it should be included in the
> > > RFC:
> > > 
> > > --
> > > CommentURL=commenturl
> > > Optional.  The CommentURL allows an origin server to specify a document
> > > that explains the usage of this cookie, and could optionally also explain
> > > the policies governing the use of information collected through this cookie.
> > > A user-agent can offer the user the option of inspecting this page before
> > > accepting a cookie.  Any cookies issued while attempting to retrieve the
> > > document at commenturl should be refused.
> > 
> > I have been working thru a similar idea before presenting it ... BUT thus
> > far my thought is that there shouldn't be any restrictions on what the
> > URL points at, associated cookies, etc. except that we need to work thru
> > the rules to make sure a privacy hole isn't created... but I think if
> 
> 
> There's a catch22 situation here though.  If someone is looking to
> make a decision on whether or not they want to accept a cookie, they
> should have some "safe haven";  They should be able to get the disclosure
> information before having to make a decision.  Accepting a cookie by
> 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.
  2.  Warn UA implementors that a cookie may be included with the 
      explanatory document and therefore recursive handling of the
      document may be necessary.

I proposed the new window as the recommended approach as it makes the
'branch' visually obvious and provides a fairly clean separation between
the cookie associated with the original response and the cookie associated
with the cookie backup.  It also allows us avoid being concerned with the
what if the URL with descriptive material includes images or links to
additional pages.

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.

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.

> > the rules are that retrieving this URL is like following any other link
> > then I don't think there are any new exposures.  (That is the cookie
> > issued by this link would have to fit the URL being retrieved.)  THis
> > has the additional advantage in that language issues can be handled via
> 
> 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.

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

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.

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.

> 
> > normal UA / server negotiation. A suggested UI for an UA able to do so
> > would be to open a new browser window to follow the link.
> 
> 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. 

> Of course, I'm assuming the scenario when the user is prompted as
> to whether or not to accept a cookie, and they then go to look at
> the policies.  A cookie manager portion of a browser should probably
> allow a user to look at the policy for all cookies that have cookie
> comment or comment url's without necessarily being asked to accept

Yup ... they should be able to check any time.

> a cookie.  (man, I'm getting tired of the word cookie.)  This second
> way of looking at the cookie comments might be treated differently.


Dave Morris

Received on Monday, 24 March 1997 23:38:10 UTC