session-ids here now, with *all* the problems.

Just a reality check on the whole session-id issue --- with regard to
one server's approach to it.  If you go to Time-Warner's Pathfinder
site (which is, they claim, one of the busiest on the net, with
several million hits a week), you find yourself instantly redirected
to something of the form:

  http://www.pathfinder.com/@@VFNihgAAAAAAQDIL/pathfinder/Quick_Navigator.html

The '@@VFN...' part is (as one quickly discovers by connecting to the
root page multiple times) a session ID.  The software that does this,
by the way, is a beta of a commercial server product which may very
well be turning up elsewhere in the not-so-distant future.

It is interesting to evaluate this mechanism (which hews to the strict
letter of the status-quo HTTP spec) by the standards which have been
used to evaluate other session-id proposals here:

Privacy ---

   It's subject to all the abuses which anyone here has imagined.  In
   particular, whatever state the server is keeping, keyed by session
   id, remains inherently invisible to the user --- as opposed to
   something like the Netscape cookie proposal, where (at the very
   least) the path of least resistance is to keep state at the client
   side, where cooperative client software *could* (and more notably,
   could be encouraged to) make that state available for inspection.

Caching and network-friendliness ---

   One objection that has been made to session-id proposals is that
   they keep documents from being cached, because the session-id has
   to go to the root server.

   Well, guess what folks --- this is even *worse*.  Since the
   session-id is made part of the URL, caching is effectively blocked
   here --- but the caches don't know that!  These documents are
   served up with correct Last-modified: headers, and without any
   Expires: data, which means that caching proxies will try to cache
   them --- and get their databases filled with redundant copies of
   the same documents, which will inhibit their ability to cache,
   well, cache-able stuff.

Ease of implementation ---

   Well, here's one case in which this hack *seems* to score high,
   sorta kinda --- it does, after all, work now.  However, if kludges
   like this become more widespread, other software may be adapted to
   deal with them semi-intelligently (caches in particular may want to
   avoid the problems discussed above), with results which will not be
   terribly pretty, and will probably be more of a headache for
   everybody than a session-id mechanism which was thought through
   from the start.

For what it's worth, I tend to like the Netscape cookie proposal ---
it allows clients to inspect the state (which makes it somewhat more
benign than the alternatives, from a privacy perspective --- although
it would be nice if the client had a menu entry someplace which showed
you the cookies), and the machinery to handle it at the client side
must be present in at least a rudimentary form to cache credentials
for HTTP authentication (even Basic auth).

Also, it has been widely deployed already, and used with success by
many groups (at least two groups that I'm *personally* acquainted
with, in addition to Netscape's own very busy site) --- something
which, in my view, ought to carry considerable weight among standards
groups when comparing it to alternatives which have been designed by
committee, and with which there is no practical experience.

However, regardless of the details, you have two basic alternatives
--- to do something, or to do nothing.  If you do nothing, that won't
stop people who need session-ids from creating them --- it will just
push them into doing stuff like the Pathfinder hack, or requiring
authentication where it isn't strictly needed solely to be able to
track people (and creating better tracking databases in the process,
since almost all such systems ask the client to identify themselves
when registering for an ID). 

In short, failing to endorse a session-id proposal won't save the Net
from the problems of having session ID's --- rather, it will force
people to create forms of session-id which you can't regulate, as
such, because at the protocol level it's pretending to be something
different.

To put it another way, the ostrich approach to, say, the privacy
issues with session-id won't work at all.  If you're concerned, try
something else.

rst

Received on Wednesday, 26 July 1995 11:52:43 UTC