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

Hi Kai,
Yes, I agree that there is a subtle but important distinction between
personalizing information (information that has been obtained/derived
that helps in providing a more personal service) and personal
information (a person's specific attributes). I do recommend that we
help developers understand that it is perfectly fine to use
personalizing information as described in the text that existed in
section 4.1 of the 20080521 version: "Personalized services are enabled
by Content Provider awareness of personalizing information, e.g. user
identity, preferences, and delivery context characteristics."
As indicated in the text of section "Personally identifiable
information (e.g. user identity or information usable as a key to user
identity) should only be accepted or sent securely. Less sensitive
information that cannot be associated with an individual (e.g. a zip
code by itself is not personally identifiable) can be exchanged in the
clear provided the correlating information is secure.". This indicates
that there is a different level of sensitivity to information that is
personally identifiable e.g. name or MSISDN, or any other public
identity/attribute which can be used to identify a specific individual,
as compared to a pseudo-ID (e.g. Yahoo ID).
The specific concern you have though seems to be with behavior tracking,
and use of that information in subsequent service. I agree with you that
usage history can be used as personalizing information, and if passively
collected (i.e. without specific user consent), then should not be used
in association with personal information, since that could be a privacy
Best regards,
Bryan Sullivan | AT&T

From: Scheppe, Kai-Dietrich [] 
Sent: Friday, July 25, 2008 3:07 AM
To: Sullivan, Bryan;
Subject: RE: ACTION-785: Check the personalization section for specific
parts that seem to imply combination of personal information with usage

Hi Bryan,
We have to be careful, because terminology in this discussion is key.
"Personalization Information" as you use it, could mean several things
in my world.
In general there is no problem with it.
I am concerned about "personal information".
Let me give an example:  
There is a user group classified as "super user".  These are computer
savvy, regular users, that are early adopters, interested in gadgets and
technology (I am making this up)
Now Kai comes to the portal and a cookie is stored on his devices that
says "Hi, I am a super super".
Next time Kai comes to the portal and he is greeted.
"Hi Kai , welcome back.  You might find our offers of intergalactical
warp coils for your newest mod on your computer interesting.  Here is a
This would be acceptable so far.
The site knows who you are, which type of user you are and recommends
products based on your user grouping.
Different scenario, same setup:
Except this time, upon returning the site says:
"Hi Kai, welcome back.  Yesterday you checked out our mods on computers.
We have some intergalactic warp coils for you.  Here is a link."
Not ok and, quite frankly, illlegal in most places I am aware of.
Here detailed tracking information that goes beyond "just" recognizing
patterns has been connected to personal informational.
Specifically user X was at location Y at time Z.
"Personalization information" is part of all of it.
If, as I said as well, the user gives permission, then much more can be
saved and associated (see passive vs. active personalization)
Quite frankly I am not that concerned with this pesonally, but we are
proposing something that is, at least in my understanding, illegal in
many places.
That is what I am trying to point out.
-- Kai


[] On Behalf Of Sullivan, Bryan
	Sent: Friday, July 25, 2008 12:02 AM
	Subject: 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

[] 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 patterns
	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

	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 Friday, 25 July 2008 21:14:42 UTC