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

Brian Behlendorf (brian@organic.com)
Tue, 18 Jul 1995 12:01:03 -0700 (PDT)

On Tue, 18 Jul 1995, James Pitkow wrote:
> > Each HTTP request should include a header field of the form:
> >
> > Request-ID: $session $request++
> > e.g.
> > that is, at the beginning of each session, the HTTP client chooses a
> > random number, and each request in that session is identified by a
> > number that increases monotincally with time. A "session" is not
> > formally defined (other than "a set of requests with the same $session
> > id"), though I suggest that browsers begin a session when they are
> > invoked, and allow some user interface to say "start a new session"
> > (i.e. "choose a new random session ID").
>
> Again, this really gets into the notion of user profiling and profile
> maintainence. I'm extremely wary of systems that enable log files to
> be collated and intelligent algorithms applied.

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. 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. If the clients could upload that profile,
or specific parts of the profile, only when needed, then the servers don't
have to maintain huge databases of profiles tied to a user name and password.
This is where the business card proposal comes in, perhaps to be folded with
the URA proposal from Bunyip.

I hope this answers James's concerns about privacy. It's a huge concern
of mine, and yet I have clients screaming for ways to provide valid
profile-based services. Surely a balance can be struck somehow through
properly designed protocols.

Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/