W3C home > Mailing lists > Public > www-talk@w3.org > March to April 1995

Re: Session tracking

From: Brian Behlendorf <brian@organic.com>
Date: Sat, 29 Apr 1995 19:39:09 -0700 (PDT)
To: Kee Hinckley <nazgul@utopia.com>
Cc: Multiple recipients of list <www-talk@www10.w3.org>
Message-Id: <Pine.3.89.9504291906.j10331-0100000@eat.organic.com>
On Sat, 29 Apr 1995, Kee Hinckley wrote:
> >"Lou Montulli" <montulli@netscape.com> writes:
> >> Here is a proposal for a session based id that is capible
> >> of storing id's accross user sessions.  Hopefully this can
> 
> I think it is important to step back and determine what exactly the needs
> of the content provider are.  The original session-id proposal was put
> forth primarily as a means of tracking a single user over a single session.
> The Netscape proposal, on the other hand, clearly has more ambitious
> goals. Shopping baskets (a metaphor I really despise) may be one of them,
> but there are many other things that the proposal does.

Right, but remember the adage "when you're a hammer, everything looks 
like a nail".  Certainly many applications could be enabled by a 
session-ID that the server could control and manipulate reliably - but 
that doesn't mean that it's the right way to do it.  

> We've used the embed-an-id-in-the-url hack on several sites before. We did
> it on http://www.firstnight.org/firstnight/ so that we could keep track of
> a user intinerary and let people come back to the site later on with all of
> their preferences still set. That's roughtly akin to the shopping basket
> model. On the other hand, we're doing it on http://www.wcrb.com/wcrb/ and
> http://www.mighty.com/mighty/ so that we can provide a user-registration
> mechanism that doesn't require remembering a user-name/password
> combination. 

I've spent many hours look at this from all angles and all possible 
protocol abuses, and can't find a system that satisfies the requirement 
of unique, cross-session identification with any modicum of security that 
doesn't require one to remember a name and password.  Putting the name 
and password in the URL or having people save to their hotlist a URL with 
a session-ID are still hacks.  

> It's a hack and I don't like it, 

Okay you recover yourself here :)

> and I play a number of games
> to try and make sure that the same ID isn't getting used from multiple
> users (it's not a big concern from a security standpoint - if it was we'd
> require passwords, but it's a concern nonetheless). I also have to handle
> lost IDs of course - it makes life interesting.
> 
> I do believe the session-id needs to be server generated - that way we can
> use an ID that makes sense to our user-tracking system. 

Hmm - this thesis needs to be explored more deeply.  You suggest a 
user-tracking system that is external to the actual web traffic - could 
you provide some examples?

> The Netscape
> proposal for an optional expiration date is also very nice, since it allows
> trial periods and the like, something that is very common on the Web.  

A server that wanted to have a "trial test period" could also implement a 
fast lookup on hostname+client-generated-session-ID, and see if the time 
stamp associated with that lookup exists and if it is still within the 
time frame allowed.  This goes against the argument against maintaining 
large server-side state as I'll note below, but it means the server 
doesn't have to generate expire times on session ID's (besides, this is a 
lot more secure - someone could very easily write a web browser which 
ignored the "expire" argument and then have indefinite access to a 
section with restricted access)

> Path
> specific ids are also a requirement, many providers host multiple web sites
> that will have different id name spaces. 

True that machines may host multiple sites, but why (if the server isn't 
generating session ID's) would those sites not want the same session-ID?  
au contrare, they might like to compare session ID's to see how much they 
help each other's traffic :)

> It also needs to be possible to
> defeat cacheing - and in that respect I see the cookie proposal as very
> much akin to the standard name/password mechanism.

Er, I hope that's a typo.  Any proposal made from here on out needs to be 
able to support caching to some extent - publishing on the web is going 
to become very difficult for anyone but large providers without it.  
In fact, I'd support language in the spec that said "it is strongly 
recommended that servers not generate content that depends on a 
particular session-ID value" - what would be ideal is if proxy caches 
did forward GET If-modified-since requests, *with* the session-ID's, so 
servers who want it can still get good data without having to dish out 
the whole file for every request.  HTTP-NG sounds like it'll have a way 
to forward on Session-ID's, too, even if the proxy never talked to the 
original server when the request was made for a cached object.

> What I really want to avoid is the HotWired/NewsPage problem of "what was
> my username and password on *this* site". That's just not acceptable,
> particularly for sites which you may not use regularly. 

As the person who *built* that for hotwired, I couldn't agree more!  What 
I really wanted was a mechaism by which browsers told me what they've 
already seen, and I could generate a page based on comparing that info 
with a list of "whats-new objects" I had, short blurbs of info with 
timestamps and URL's attached.  In fact I posted a proposal a few months 
ago for a State: header which accomplished pretty much what people now 
want to use Session-ID for (although State is a much better term for 
it when used by applications like what's new and shopping carts).  
However, after talking with a few people and watching the conversation 
about shopping carts, I realized what I really wanted was a general way 
to distribute those "what's-new objects" in a way that the client could 
assemble them locally.  The result was the realization that the what's 
new" functionality was something highly generalizable for all URL's out 
there, so an extension of the browser hotlist function to every now and 
then (as set by the user) check up on the last-modified times of various 
URL's and present the list of changed objects as a mail-reader-like 
application would be the most scalable way to go.  It meant HotWired 
would lose the control over formatting they had, admittedly; but once 
Java's around HW could distribute its own version of that "What's New" 
application with their logo in the background of the main window or 
something :)

The point is - there is a much better solution to "what's new" than what 
HotWired is doing coming down the pipe, and instead of incremental 
solutions like basing it on a second-class data object like "Session-ID", 
a bigger leap would really provide bigger results.

> You could partially
> solve this by having the browser cache name/password pairs over multiple
> runs, 

Ugh - *so* many problems there.  Security (other people using your 
browser), logistics (what happens if you use someone else's browser?) and 
it does nothing to elimanate the account creation and server-side-state
problem.  I think when my bosses talked about wanting to make the process 
"invisible" they didn't quite realize this....

> Shopping carts embedded in ids is a cute hack, but it's a red herring. The
> real goal in my mind is to find a way to identify a user without requiring
> them to carry a separate ID for every store they walk into.

Agreed... which is why I don't think they should carry a session-ID for 
every store they visit either.  :)

	Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com  brian@hyperreal.com  http://www.[hyperreal,organic].com/
Received on Saturday, 29 April 1995 22:39:24 UTC

This archive was generated by hypermail 2.4.0 : Monday, 20 January 2020 16:08:16 UTC