W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1996

Re: draft-ietf-http-state-mgmt-03.txt

From: <marc@ckm.ucsf.edu>
Date: Wed, 31 Jul 1996 18:17:51 -0700
Message-Id: <199608010117.SAA11720@pele.ckm.ucsf.edu>
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 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:05 EDT