- From: Koen Holtman <koen@win.tue.nl>
- Date: Fri, 21 Jul 1995 11:51:20 +0200 (MET DST)
- To: mwm@contessa.phone.net (Mike Meyer)
- Cc: www-talk@w3.org
Mike Meyer: >Could somebody tell me what's wrong with the NetScape Cookie proposal? >Other than the date string that's going to break in less than five >years, that is? (Well, that and the unix-like needs-a-cuteectomy >names?) NetScape Cookies offer an implementation mechanism for the `statefull dialogs' I talked about earlier, and this is a very good thing. What is wrong with them is that better implementation mechanisms for `statefull dialogs' are possible. Disadvantages of cookies: 1) Privacy: NetScape Cookies, especially the kind that is persistent between sessions (using the expires=DATE part of the proposal), greatly increase the possibilities for marketing departments to track my actions, especially if multiple commercial sites decide to share their logging info. Of course, my browser could have a feature asking me whether I want to allow a site to set any cookies. But how many browser writers would implement such a privacy dialog, and how many users would enable it? The point is that other mechanisms would allow `statefull dialogs' with much less loss of privacy (for the lazy user). 2) Time to availability: Compared to adding a session-id, adding cookie support to a browser takes considerable effort on behalf of the browser author. If we want workable `statefull dialog' support by all popular browsers as soon as possible, it makes more sense to standardize the session-id solution. One of the benefits of the cookie solution over the session-id solution is that cookies lessen the need for server-side databases containing session state. This would make the life of service authors easier. As a service author, I have found that implementing such server-side databases is one of the least of my problems. I'd rather have the session-id solution N months from now than have the cookie solution, which is a tiny bit easier to use, after N+M months. If session-id is available after N months, a library for making server-side session databases will be available one month later anyway. > <mike Koen.
Received on Friday, 21 July 1995 05:51:43 UTC