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

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

From: Erik Aronesty <earonesty@montgomery.com>
Date: Thu, 1 Aug 1996 14:40:32 -0700
Message-Id: <c=US%a=_%p=Montgomery%l=EXCHANGE_SERVE-960801214032Z-329@sf-exch-2.montgomery.com>
To: "'http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com'" <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1189
The whole concept of cookies is marginal...since a good user-tracking
database can implement all of these things in a secure and robust

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;
>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
>to create or modify a local persistent resource at the behest of a
>server, then the user must have complete control over that process.  If
>user is expected to spend bandwidth transmitting what a remote server
>important, then knowledge of the state of that process should not
>gymnastics on the part of the (perhaps non-technical) party that is
>for the bandwidth and perhaps the content.  
>The changing states of the state mechanism WILL be known to the server
>available to only the most vigilant users (following the path of least 
>resistence, the way Navigator doesn't conform to this specificied
>right now) unless ideal privacy guidelines are specified, with SHOULD
>perhaps in a separate document, if necessary.
Received on Thursday, 1 August 1996 14:45:10 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:17 UTC