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

James Pitkow ([email protected])
Tue, 18 Jul 1995 12:38:00 -0400 (EDT)


> 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. Note that companies
which currently do this, like I/PRO, could potentially become the
Equifax and TRWs of the future. Dan, where are you with the Constitution
that was kicked around ages ago? Should we protect against this? Can we?
How may of the sites that require email addresses for admission outline
their policy for usage of this information. In the US, companies can
do whatever they want with this information, even if they do not tell you
they are doing it. Other countries have more consumer-protective laws.
This is just the tip of the iceberg on the potential privacy violations.

> One might argue (in fact, one has argued: Hi Henrik!) that this is an
> extension of the From: field, and these data belong there. I don't
> believe so: if the From: field is present, it should contain a valid
> email address of the requesting user (clearly the server cannot depend
> on the authenticity of the From: field, but that doesn't mean we
> should corrupt it further in the protocol spec).

I was never clear of why we would want to have an e-mail address sent
in the first place. Dan, maybe you could review for everyone's sake why
this is and what scenarios demand its presence.

> mechanism might allow unwanted correlations to be observed. So perhaps
> there should be a preference to turn this feature off.

So then what is accomplished? If I knew I could control whether or not
people could track me, what is my incentive to keep it on?

> ******* II. The business-card authentication scheme
>
> I propose a new http authentication scheme; let's call it
> "business-card". Its purpose is to facilitate access control policies
> similar to "I'll show you my information if you'll leave your business
> card in the bowl."

The collation of demographic information as a requisite for information
access is not acceptable to me. When I go into the library I can do so
without being monitored or tracked. If I check out a book, though, then
I leave a trail. In this new information theater, do we really have
to give up even more privacy?

> I haven't had time to discuss the privacy issues in detail, nor talk
> about the required but hidden IVth proposal, which is that proxies and
> caches relay certain log info to information providers.

Yup, some really smart person knows how to do this and is doing it.
This solves a lot of the privacy issues as it does not introduce any new
fields of information.

Jim.