RE: ACTION-785: Check the personalization section for specific parts that seem to imply combination of personal information with usage patterns

To clarify the intent of the section as originally provided (my input),
the assumption is there (I thought clearly, but we can make it more
explicit, again) that the personalizing information is provided directly
by the user or a trusted entity that the user has authorized to disclose
personal information to gain some value-added service feature. 
Not only is there nothing "wrong" with this (except in certain locales,
if any, where only anonymous service is allowed by law), there is
nothing "wrong" with associating the personalizing information with
usage patterns etc. Such usage patterns are often useful in providing
more personalized service, and if understood/agreed by the user
(informed consent), there is nothing "wrong" in their use. Note that
personalizing information does not have to include any public/traceable
identity (e.g. MSISDN or name): it can be a pseudo-identity which can
itself be short-lived. There are many ways to turn up the privacy meter
and retain personalization capability.
I think part of the problem here is that the current draft has
eliminated much of the supporting rationale text for personalization
being a special issue in the mobile context, and as a result I believe
people are in danger of misinterpreting the intent. This often happens
when specifications establish the context of the assertions they make,
then in the process of completing the spec the context info is
simplified/eliminated (because it perhaps seems too wordy to some who
like more terse text), but the readers (and those working on the text
themselves) lose the thread of rationale and end up questioning the
whole darn business. I see that process at work here.
There is value in retaining both active and passive personalization
information as Kai has put them, but for MWABP I think we only need
discuss active personalization. Active personalization is more likely to
have a direct impact on the user (information entry) or the content
provider (determining the personalizing info, e.g. identity and related
preferences, may require extra work at the server side). The earlier
version text (20080521) made this clear through the reference to use of
SSO technology/methods, but for some reason in the current version that
is gone... more "simplification" I suppose.
So overall I caution against too much fear of stating realities (it *is*
a reality that with proper user consent, personal information is in fact
used, to provide better service), and over-simplification of the text.
Best regards,
Bryan Sullivan | AT&T

From: [] On
Behalf Of Scheppe, Kai-Dietrich
Sent: Thursday, July 24, 2008 8:33 AM
Subject: ACTION-785: Check the personalization section for specific
parts that seem to imply combination of personal information with usage

Well, since adjourned early, I had some time :-)
BP2 revisted for this action
This now applies to section 3.1 (formerly 4.1, as listed in ACTION-784)

regarding... What it means

If a service relies on user entered personalization information (e.g.
application preferences, personal details) that information should be
retained in order to avoid the need to re-enter it the next time a user
visits the site.


Here we should simply delete ", personal details" or change it into
"personal preferences".

Personal data could be construed to mean name, address, phone number
etc. which is not allowed to be associated with usage patterns and other
information like it.



regarding... How to do it

The simplest way to do this is to associate personalization information
with a given user identity and obtain their login credentials directly
on first access.


Here we need to separate between what is often called "passive
personalization" and "active personalization".

Passive personalization tracks usage patterns and tends to assing a
profile to a user that fits to his behavior, but is not combined with
personal information

Active personalization requires the agreement of the user to store and
use certain personal information (not sure on what can be used then, but
at least a login).
For the above this means that we have to allude to the needed permission
by the user.


-- Kai

Received on Thursday, 24 July 2008 22:03:05 UTC