Agree. Storing the profile on the users equipment also solves some
scalability problems for services that rely on the users previous actions
and decisions, such as service that adapts the "interface" (i.e. documents)
depending on preferences and settings (needless to say [almost], this is
what I am working on nowadays).
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). We cannot rely on the "profile
editor" created by the service provider. To throw out a suggestion: The
profile can be structured using SGML to allow for use of a more generic
profile editor as well as generic tools to handle profiles. 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). This would allow
privacy protection such as limiting the ability for service providers to
build large databases of profiles. It would also eliminate requiring users
to login on the service to maintain a profile. A disadvantage would be some
more information passing through the wires, but then again, the profiles
would not necessarry be that large.
-- Terje <Norderhaug.CHI@Xerox.com>
<URL:http://www.ifi.uio.no/~terjen/>