- From: Jonathan Stark <stark@commerce.net>
- Date: Mon, 24 Mar 1997 20:50:33 -0800 (PST)
- To: "David W. Morris" <dwm@xpasc.com>
- Cc: stark@commerce.net, http-wg@cuckoo.hpl.hp.com
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. Jonathan
Received on Monday, 24 March 1997 20:48:28 UTC