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

In article <Pine.3.89.9507181142.N29440-0100000@eat.organic.com>,
Brian Behlendorf writes:
> Because Request-ID's would be guaranteed persistant *only* for the life of a
> session (where session is defined by the users themselves), they are next to
> useless as mechanisms for generating long-term user-specific profiling, but
> still useful for in-aggregate profiles.  This is a Good Thing - the user
> doesn't lose any privacy and the info provider can still get in-aggregate
> data.  

The server initiated Cookie header is superior to a Request-Id in several
ways and has much greater functionality.  The biggest advantage is that
most Web transactions need neither so why add a lot of unused stuff to
*every* header.  Dan Connoly's suggestion of using an authentication
request to signal that something like a Request-Id is needed seems like
a kludge.  It is also not as efficient as Cookies.  

Cookies also make it impossible to corelate log data from different servers.
The cookie from one server will never be sent to another.  This is a
serious problem with session-id.

Finally, and most important, unlike most proposals discussed here this
one will actually be implemented in a significant fraction of clients,
because it already has been!

Brian is absolutely right though that Cookies should be persistant *only*
for the life of a user session (Please don't tell me about kiosks, I already
know!).  I believe that this is the current Netscape behavior, documentation
to the contrary notwithstanding.

> Now there are definitely times when user profiles help the info
> provider provide better info - sites like NewsPage and HotWired are providing
> that now with user authentication.  

Yes, and I personally find this objectionable.  It is the reason that
I have never been beyond the front door of Hotwired.  I have been thinking
about why it grates on me so much.  It is not primarily the privacy issue,
thought that is part of it.  Primarily it is because the practice is such an
atavism.  It is a throwback to a 1970's mainframe computing paradigm.
It betrays a fundamenal lack of understanding of the Web culture.
Considering the source this is very ironic.

It is also completely impractical.  Does Wired really expect readers
to maintain a unique password for every publication to which they
subscribe?  And worse, to supply it *every* a publication is read??
This is certainly something which will not scale -- on the user's end.
Fortunately, it does not seem to be catching on.  In many ways it is
analogous to copy protected software.  A benefit derives to the
supplier at considerable inconvenience to the user.  Hopefully, it
will suffer the same fate.  An interesting, but probably unattainable
statistic would be how many people would like to look at Hotwired, but
won't because of their registration procedure.

John Franks

Received on Wednesday, 19 July 1995 10:08:44 UTC