- From: <marc@ckm.ucsf.edu>
- Date: Wed, 31 Jul 1996 18:17:51 -0700
- To: snowhare@netimages.com, sommerfeld%apollo.hp.com@hplb.hpl.hp.com
- Cc: dmk@bell-labs.com, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, montulli@netscape.com
sommerfeld@apollo.hp.com wrote > Any HTTP client implementing this protocol MUST provide at least three > options for the user: > 1) disable cookies entirely. > 2) ask the user before setting a cookie. > 3) set cookies without asking the user. > > The default "out of the box" behavior of the client MUST NOT be #3. snowhare@netimages.com responded |Even between seperate cooperating sites, without |letting them know I am doing so, if I so desire. Cookies raise no new |privacy concerns in that regard. It is, and has been, a red herring for a |long time. The issue here is not one of tracking, but resource control. If a user is to create or modify a local persistent resource at the behest of a remote server, then the user must have complete control over that process. If the user is expected to spend bandwidth transmitting what a remote server considers important, then knowledge of the state of that process should not require gymnastics on the part of the (perhaps non-technical) party that is paying for the bandwidth and perhaps the content. The changing states of the state mechanism WILL be known to the server and available to only the most vigilant users (following the path of least resistence, the way Navigator doesn't conform to this specificied proposal right now) unless ideal privacy guidelines are specified, with SHOULD or perhaps in a separate document, if necessary. -marc
Received on Wednesday, 31 July 1996 18:27:55 UTC