Re: Session tracking

James Pitkow (pitkow@cc.gatech.edu)
Fri, 21 Apr 1995 13:41:09 +0500

Lou's notion of servers issuing cookies can be made to work for session
tracking, but may not work across user sessions. Problems will occur on
shared machines that do not require logins, i.e. most PC/Macs. So, your
server issues me a cookie, I use it, leave; later, another user using
the same client and machine visits your site. While you may be able to
demarcated sessions, you do not have the same user, who now may have
inherited a shopping basket, or some other statefull user based
representation entertained by the server. Additionally, since cookies need
to be unique, some server side mutex will be necessary, which could turn into
a bottle neck for active servers. Some solutions might include:

* As Brian proposed, have the cookies cleared upon browser restarts,
though this conflicts with Lou's goal of having "the client save state
information within the client."

* Another would be for start ups of multiuser PC/Mac browsers to ask
for some non-informative identification string. I personally
do not endorse this method, though it does move in the direction
that David Chom posits of multiple, user-defined alias - one can
be who one wants to be without anyone knowing it's me.

* Another solution is to restructure one's approach to the problem,
seeing as multiple goals are trying to be accomplished via one
mechanism.

Specifically, if seems that we want to accomplish the following three things:

1) identify sessions from server logs (esp. from firewalled domains)
2) enable unique, but changeable user identifications
3) freely pass data as first class objects between client/servers

The first issue is quite doable without any modifications to existing
protocols (I wrote code a year and half ago, before the referrer field,
that accomplishes this with a high degree of certainty that the paths
inferred are the paths actually traveled. See "WebViz: A Tool for WWW
Access Log Visualization" from the First WWW Conference Proceedings).

The second issue is digital signatures. Use of Netscape's ip/uid/+*
based signature, which btw is not very well conceived :(, or some other
scheme can produce the desired results. No doubt, better, more robust
schemes exist and will be adopted in the future. No modification
to HTTP headers are required since From: is already specified. Note
that use of signatures solves the first issue.

The third issue is first class data passing. Java is a very strong initial
starting point. Multi-part encapsulated MIME for clients and servers could
also be made to fit this problem. I personally would prefer a separate
protocol as to facilitate modularization and interoperability. The data
object could be used to contain shopping basket updates and checkouts,
as well as correctly process multi-server shopping malls.

Jim.