From: Adam Rifkin (adam@KnowNow.com)
Date: Sun Oct 22 2000 - 00:18:46 PDT
I like the recommended uses of cookies in best current practice in RFC 2964:
Use of HTTP State Management is appropriate whenever it is desirable
to maintain state between a user and a service across multiple HTTP
transactions, provided that:
(1) the user is aware that session state is being maintained and
consents to it,
(2) the user has the ability to delete the state associated with
such a session at any time,
(3) the information obtained through the ability to track the
user's usage of the service is not disclosed to other parties
without the user's explicit consent, and
(4) session information itself cannot contain sensitive information
and cannot be used to obtain sensitive information that is not
otherwise available to an eavesdropper.
This last point is important because cookies are usually sent in the
clear and hence are readily available to eavesdroppers.
An example of such a recommended use would be a "shopping cart",
where the existence of the shopping cart is explicitly made known to
the user, the user can explicitly "empty" his or her shopping cart
(either by requesting that it be emptied or by purchasing those
items) and thus cause the shared state to be discarded, and the
service asserts that it will not disclose the user's shopping or
browsing habits to third parties without the user's consent.
Note that the HTTP State Management protocol effectively allows a
service provider to refuse to provide a service, or provide a reduced
level of service, if the user or a user's client fails to honor a
request to maintain session state. Absent legal prohibition to the
contrary, the server MAY refuse to provide the service, or provide a
reduced level of service, under these conditions. As a purely practical
consideration, services designed to utilize HTTP State Management may be
unable to function properly if the client does not provide it. Such
servers SHOULD gracefully handle such conditions and explain to the user
why the full level of service is not available.
> [Heavily reformatted.]
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> This message was forwarded through the Red Rock Eater News Service (RRE).
> You are welcome to send the message along to others but please do not use
> the "redirect" option. For information about RRE, including instructions
> for (un)subscribing, see http://dlis.gseis.ucla.edu/people/pagre/rre.html
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Date: Sun, 22 Oct 2000 12:35:27 +1100
> From: Roger Clarke <Roger.Clarke@xamax.com.au>
> Subject: IETF issues RFC on cookies
> I've revised the last part of my Cookies page (which has by now
> accumulated 50-60,000 hits), in order to reflect the vital new RFCs
> that have just been released. See:
> http://www.anu.edu.au/people/Roger.Clarke/II/Cookies.html#Dev
> Cookies were an innovation of Netscape's sometime in 1995. They were
> apparently supported by Netscape Navigator 1.0 (but nobody realised),
> but began to be used when Netscape 2.0 was released, even though they
> weren't formally documented. In short, an intrusive enhancement to
> the web was slipped in surreptitiously.
> Most of us who were active in Internet and web policy matters
> only became aware of the existence of cookies in mid-February 1996.
> Public concerns rose rapidly, for the very good reasons outlined in
> this document. Shortly afterwards, in February 1997, a more general
> mechanism to support state-maintenance was proposed as
> ftp://ftp.isi.edu/in-notes/rfc2109.txt
> RFC 2109 'HTTP State Management Mechanism'
> (by Dave Kristol of Bell Labs and Lou Montulli, then of Netscape).
> Dave had to fight a long, slow battle to get the need for a
> responsible cookie-architecture onto IETF's agenda. Despite my
> raising it directly with Tim Berners-Lee, W3C avoided the matter
> entirely, reflecting the increasing constraints on its freedom
> of action arising from it desire to avoid upsetting its corporate
> sponsors.
> At last, Dave's efforts paid dividends. The revised document was
> published in early October 2000, as
> ftp://ftp.isi.edu/in-notes/rfc2965.txt
> RFC2965 'HTTP State Management Mechanism'
> (25 pp., by Dave Kristol, Bell Labs and Lou Montulli, now
> of Epinions.com).
> ******** *******
> * It's now up to all of us to put pressure on IETF and W3C to adopt *
> * the formal proposal; and on all web-server and web-browser *
> * providers to implement cookies in the responsible manner proposed. *
> ******** *******
> In addition, the concerns about the existing cookie mechanism were
> addressed in
> ftp://ftp.isi.edu/in-notes/rfc2964.txt
> RFC2964 'Use of HTTP State Management'
> (7 pp., by K. Moore, University of Tennessee and N. Freed, Innosoft).
> I've not yet assessed those RFCs against the consumer requirements
> laid out in this document; but it was developed with many of the
> problems in mind. I hope to get an assessment up in this location
> some time soon.
> Roger Clarke http://www.anu.edu.au/people/Roger.Clarke/
> Xamax Consultancy Pty Ltd, 78 Sidaway St, Chapman ACT 2611 AUSTRALIA
> Tel: +61 2 6288 1472, and 6288 6916
> mailto:Roger.Clarke@xamax.com.au http://www.xamax.com.au/
> Visiting Fellow Department of Computer Science
> The Australian National University Canberra ACT 0200 AUSTRALIA
> Information Sciences Building Room 211 Tel: +61 2 6249 3666
---- Adam@KnowNow.ComRohit said that our god is an angry god, and I thought that was such a great quote that I decided to name a file after it. -- Kragen Sitaker
This archive was generated by hypermail 2b29 : Sun Oct 22 2000 - 00:23:17 PDT