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

In message <199507181638.MAA21500@hapeville.cc.gatech.edu>, James Pitkow writes
:

Jeez... I'm just gonna keep my proposals to myself until I have
time to complete them! The Request-ID has lots of uses besides
"big brother" snooping: it can be used as a nonce in security
mechanism, for one thing...

>> Each HTTP request should include a header field of the form:
>> 
>> 	Request-ID: $session $request++
>
>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.

If it ends up in higher quality of service, why are you so worried?

> Note that companies
>which currently do this, like I/PRO, could potentially become the
>Equifax and TRWs of the future.

Let's not start with the Fear, Uncertanty, and Doubt here: please
present your technical argument.

>  Dan, where are you with the Constitution
>that was kicked around ages ago?  Should we protect against this? Can we?

We shouldn't "protect" against mechanisms that are generally cost
effective. There is a legitimate need for information providers to
model the usage of their information, and to cost-justify it by access
statistics. If you want to see better stuff on the web, we need to
enable it.

Specifically, how is the Request-ID, as proposed, a threat to
privacy? I think it can be safely turned on by default, as long
as it's documented. In contrast, the user agent should _not_ do
From: or business card auth without going through a dialog with
the user explaining the consequences.


>How may of the sites that require email addresses for admission  outline
>their policy for usage of this information.

Several good ones an zillions of nasty ones. What's your point?

>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.

One example where the From: field is clearly justified and useful
is web robots. When some robot goes nutso on my sight due to an
implementation bug, I as an information provider clearly have the
right to know who's operating it and tell them to cut it out.

>> 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?

Your incentive is that the information you browse will get better --
more tuned to your reading patterns.


>> ******* II. The business-card authentication scheme
>> 
>
>The collation of demographic information as a requisite for information
>access is not acceptable to me.

So don't use it. Or are you saying that it's not acceptable for anyone
to collect these data about anybody else, never mind you? Clearly,
it's acceptible to the zillions of users on America Online that enter
their "user profiles" in the AOL directory.

>  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?

No, you don't have to. But if you do, my guess is you'll get better
info.

Look at it this way: if restrict advertisers to a choice between
spamming and not using the internet at all, we'll get spammed.
If we give them the option to do targeted, focused advertising,
everybody wins, no?

>> 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.

Have they written it up so we can all do it the same way?

Dan

Received on Tuesday, 18 July 1995 13:16:07 UTC