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

Terje Norderhaug:
>Agree. Storing the profile on the users equipment also solves some
>scalability problems for services that rely on the users previous actions
>and decisions, [...]

Sigh. Didn't we go through the scalability of session-ids before?

>If we want to give the user full control of the profile, it should be in a
>standard format so it can be edited by a tool running on the users hardware
>(or a standard editor available on the web).

This gives full control over the profile that is stored at the user
end.  The profile that determined "undesirable profiler(s)" can build
through pooling of logfiles is a completely different beast.  It will
not read

 1) I don't want inline images larger than 10k
 2) I want the complex user interface setting for blex.net ,

it will be something like

 1) my name + snail mail address  (from some offer for a snail mailed
     information package about cars I once filled in)
 2) is interested in (browsing commercial web sites about)
      - books, cars, gardening, ....

Typically, this profile would be stored in the databases of multiple
marketing departments, not in my local profile file.  By editing my
local profile, I won't be able to prevent getting snail mailed special
offers for books about gardening.

The only way to prevent this is to make pooling of logfiles by
determined profilers as difficult as possible.

> As a service is
>visited, the browser retrieve a current profile and stores this on the
>users equipment. This profile is later submitted by the browser to the
>service at next time use (potentially long time later).

Congratulations.  You just rephrased the NetScape Cookie spec.

> This would allow
>privacy protection such as limiting the ability for service providers to
>build large databases of profiles.

Nope.  It does not limit the ability of service providers to store any
information you send them in the marketing database.  If you send it,
they can archive it, regardless of whether you promise to send it
again next time.

[...]

>-- Terje <Norderhaug.CHI@Xerox.com>

Koen.

Received on Monday, 24 July 1995 19:32:02 UTC