- From: Melissa Dunn <mwdunn@microsoft.com>
- Date: Thu, 8 Mar 2001 13:14:35 -0800
- To: "'www-p3p-public-comments@w3.org'" <www-p3p-public-comments@w3.org>
During the P3P face-to-face, there was a discussion of removing CUS and replacing its intent through the use of either * TAIi where the user's information is not stored and therefore expires at the end of the current session (e.g. getting the local TV listings on demand) * IVDi where the user's information is stored and can be linked to PII and reused across sessions (e.g. sending email suggesting that I might want to pre-order the next Harry Potter book because I have purchased other Harry Potter books from the site) * PSDi where the user's information is stored and not linked to PII and reused across sessions (e.g. getting local news on your home page, which requires postal code retention) The difficulties here are that there are several classes of Web activities that can not be properly described by these categories: personalization, address books and form filling. Scenario 1: Personalization (e.g. Welcome [username] on the home page) is meant to make the site appear "friendly". The site would have to declare IVDa under the current definitions. Yet, in the context of personalization, PII may not be linked or even linkable to non-PII. Scenario 2: Address Books are becoming more common on e-tailer sites where they try to create a simple user experience for filling out the SHIP TO sections of their order forms. The sites typically ask for a nickname and then the real shipping information. The user can then simply pick the nickname from a drop down list and the site fills in the rest of the form. The user knows that they are storing the information on the site and the primary purpose for which the information is being used. The user does not explicitly opt-in/opt-out. The opt-in is implicit since the user gave the information. The PII information is not about the user, but is about user contacts. The information may or may not be linkable to other users (e.g. I give my best friend's address. My best friend uses the same site. They link us on my best friend's name/address - my shipping and her billing match. The site now knows how to cross-sell) Scenario 3: Form Filling is also becoming a common activity: gator, roboforms, etc. are all dedicated to assisting the user by storing information and then using that information to fill forms. As more and more people move to the use of "not so smart" client devices, the more likely that personal information is to be stored by a service that fills the form using a key mechanism, such as a persona ID, etc. The primary purpose of collecting the information is for form filling, much as Current, though the information is persisted over time. There may or may not be any way for form filling sites to link PII to non-PII. In order to account for these activities, I propose that the P3P purpose vocabulary be expanded to include: Personalization: secondary usage of persisted PII the intent of which is to create a more personal experience (e.g. Welcome [username]) Personal Assistance: primary usage of persisted PII that must not be linked to non-PII or cross-linked to other PII, the intent of which is to assist the user in a form-filling task, such as address books, one-click billing, etc. The following compact policies would then describe the scenarios listed above: Scenario 1: P3P:CP="PER OUR PHY" Scenario 2: P3P:CP="PRA IVDa OUR PHY" Scenario 3: P3P:CP="PRA OUR PHY" Because Scenario 2 allows for the site to cross link data, and they choose to do so, then the site must also declare IVDa as it is making decisions that impact this user and possible other users based upon the PII provided. General Comments: * Personalization is an innocuous activity and will rarely be anything other than "always", as I can't conceive of a site asking whether they can use the consumer's name for personalizing the site. The real concern should be whether the user was asked to opt-in/opt-out for the PII in the first place. * Personal Assistance is a primary use category that most often involves implicit opt-in: meaning that the user gave the site the information for the stated purpose directly, though no opt-in was explicitly given. This is much like the Current, except that the PII is retained and re-used to assist the user in completing the current activity (ship to, bill to, filling out registration forms, etc.) As such, should it need the "required" attribute. The main difference between this and Current is retention and re-use. Melissa
Received on Thursday, 8 March 2001 16:15:12 UTC