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

Re: RFC2109 addition...

From: Jonathan Stark <stark@commerce.net>
Date: Mon, 24 Mar 1997 20:50:33 -0800 (PST)
Message-Id: <199703250450.UAA28839@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/2868

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.

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

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

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

Thanks for the input, Dave.

Received on Monday, 24 March 1997 20:48:28 UTC

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