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

The whole concept of cookies is marginal...since a good user-tracking
database can implement all of these things in a secure and robust
manner.

The problem?  "good user-tracking databases" are hard to come by and
"bad HTTP standards" are easy.

Seriously, everyone knows that cookies can be dangerous when implemented
on operating systems/browsers with out decent user authentication.

I would rather propose:

It is recommended that Cookies not be used if your data is sensitive
and/or password controlled.  Use a user tracking system ... and you will
thank yourself in the end.  (SICK)



>----------
>From: 	marc@ckm.ucsf.edu[SMTP:marc@ckm.ucsf.edu]
>Sent: 	Wednesday, July 31, 1996 9:17 PM
>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
>Subject: 	Re: draft-ietf-http-state-mgmt-03.txt
>
>
>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 Thursday, 1 August 1996 14:45:10 UTC