Re: 3 Proposals: session ID, business-card auth, customer auth

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