- From: Sullivan, Bryan <BS3131@att.com>
- Date: Mon, 28 Jul 2008 09:52:02 -0700
- To: <public-bpwg@w3.org>
- Message-ID: <8080D5B5C113E940BA8A461A91BFFFCD09B3F329@BD01MSXMB015.US.Cingular.Net>
Hi Kai, I agree your proposed text strikes a good balance, recognizing the validity of personalizing information collection/use when there is informed consent. Best regards, Bryan Sullivan | AT&T ________________________________ From: Scheppe, Kai-Dietrich [mailto:k.scheppe@telekom.de] Sent: Monday, July 28, 2008 9:29 AM To: Sullivan, Bryan; public-bpwg@w3.org Subject: RE: ACTION-785: Check the personalization section for specific parts that seem to imply combination of personal information with usage patterns Hi Bryan, 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." That sentence is correct as far as I am concerned, but want to point out that it is somewhat oblique and therefore may not be understood as a warning that this is a sensitive topic. As indicated in the text of section 3.2.1.1 "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 paragraph does reflect the most common concern here and is, as such, correct, but it only deals with security of transmission and not the fact that some of this data may not be associated. 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 concern. More specifically, it is the type of data that is collected, the circumstance under which it was collected and how it is then used. I merely want to make sure that people using personal data in mobile web applications are aware of privacy concerns and potential legal ramifications of combining certain data. For this some simple clarification would suffice. Here is a proposal: "Data which is collected without the express permission by the user may not be used in certain ways that associate usage patterns and activities with a specific user or user account. Data for which such permission has been given may be dealt with more freely. The precise applicability of laws in this area are specific to the context in which the application would run. Developers are encouraged to seek advice on the particular privacy concerns relating to their specific application." -- Kai Best regards, Bryan Sullivan | AT&T ________________________________ From: Scheppe, Kai-Dietrich [mailto:k.scheppe@telekom.de] Sent: Friday, July 25, 2008 3:07 AM To: Sullivan, Bryan; public-bpwg@w3.org Subject: RE: ACTION-785: Check the personalization section for specific parts that seem to imply combination of personal information with usage patterns 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 link." 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 ________________________________ From: public-bpwg-request@w3.org [mailto:public-bpwg-request@w3.org] On Behalf Of Sullivan, Bryan Sent: Friday, July 25, 2008 12:02 AM To: public-bpwg@w3.org 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 ________________________________ From: public-bpwg-request@w3.org [mailto:public-bpwg-request@w3.org] On Behalf Of Scheppe, Kai-Dietrich Sent: Thursday, July 24, 2008 8:33 AM To: public-bpwg@w3.org 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 ACTION-784) regarding... 3.1.1.1 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... 3.1.2.2 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 Monday, 28 July 2008 16:52:59 UTC