W3C home > Mailing lists > Public > www-talk@w3.org > July to August 1995

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

From: Koen Holtman <koen@win.tue.nl>
Date: Fri, 21 Jul 1995 02:47:17 +0200 (MET DST)
Message-Id: <199507210047.CAA02591@wswiop05.win.tue.nl>
To: www-talk@w3.org
Cc: fielding@beach.w3.org, koen@win.tue.nl (Koen Holtman)
Roy Fielding:
>Daniel W. Connolly:
>>Each HTTP request should include a header field of the form:
>>
>>	Request-ID: $session $request++
>>e.g.
>>	Request-ID: 342%33a4d443 12
>
>A) Must be optional (it can indeed be used to identify individuals,
>   if the individuals are not sophisticated enough, or if the tracker
>   is persistant).  Besides, all headers are optional in HTTP.
>
>B) Should be shorter (optional marketing gunk has low priority)

I'd like to point out that having some form of session-id in HTTP
should be given a *high* priority, because there are much more
important things than marketing gunk connected to session-id.

A session-id allows the server to distinguish between individual
sessions, and this makes possible keeping session state information in
a server-side database.  The need to keep session state has been
discussed at length before on this list, and session-id seems to be
the minimal solution to this problem. (With minimal, I mean minimal in
terms of extra browser complexity needed.)

Session-id allows for a reliable and relatively straightforward
implementation of what I call a `statefull dialog' between user and
service, that is a dialog that extends beyond the submission of one
form.  By allowing statefull dialogs, session-id will greatly increase
the potential of the web as a two-way communications medium.

Compared to this, the improvement possible through better clicktrail
analysis by the marketing department is not very significant.

I want my browser to support session-id because this will allow me to
get new interesting services.  If I can't have the services without
giving up some of my privacy, I will in fact gladly give up some of my
privacy.

But with an adequately designed session-id mechanism, the amount of
privacy I need to give up can be kept very small.  As said before in
this thread, the session-id should at least be different for each
server talked to.

One other idea is for the browser to only send session-id info to a
server starting from first POST request (form submission) done on that
server by the user.  Thus, users only get an identity if they start
talking back to the server.  Privacy would not be decreased in other
cases.

A session-id is needed as soon as possible.  Not to allow better
statistics, it needn't improve the possibilities for statistics much
at all, but to allow new kinds of services to be added to the web in
the future.

Of course, the question of how much user privacy may be traded away to
increase the quality of web advertising and prevent the web-equivalent
of spamming is an important one.  But as shown above, the main
advantages of session-id can be had without fully answering this
question.

Koen.
Received on Thursday, 20 July 1995 20:47:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 27 October 2010 18:14:17 GMT