W3C home > Mailing lists > Public > www-p3p-public-comments@w3.org > May 2000

Re: Additional three comments on the last call draft of the P3P specification.

From: Lorrie Cranor <lorrie@research.att.com>
Date: Tue, 2 May 2000 23:32:16 -0400
Message-ID: <011d01bfb4b0$38fcd240$3a06cf87@research.att.com>
To: <shimizu@nmda.or.jp>, <www-p3p-public-comments@w3.org>
Thank you for your thoughtful comments about P3P.

>1. P3P 1.0 Specification should introduce conception of hierarchical 
>structure of policies and entities

This is outside the scope of P3P1.0, which focusses on expressing
the data practices of a website only. The fact that banner ads may
have a different privacy policy associated with them than the page
in which they are embedded can be expressed in P3P1.0 simply
by associating different P3P policies with a page and its embedded
ads.

>Thus, the personal data sent to the Web server in this User-Agent 
>header are the following.
>? The fact that this is an access via the i-mode. (It corresponds to 
>"DoCoMo" in the  header.)
>? The type of mobile phone (It corresponds to " N502i")
>? The size of cache (It corresponds to "c10". This means the cache size 
>of mobile phone is 10K bytes. In addition, "1.0" in the header means 
>the version of HTTP.)
>   These 3 data are all able to be included in the "Computer Information" 
>of Data Categories defined by P3P 1.0 Specification, but these data are 
>specific to the i-mode access to the Internet. We ask the P3P WG 
>members to touch on such data in P3P 1.0 Specification.

> This ID number can be included in the "Unique Identifier" and the 
> "Computer Information" of Data Categories defined by P3P 1.0 
> Specification. We would like to ask the P3P WG members to 
> refer to such an ID number in P3P 1.0 Specification.

Rather than adding these dataelements to the P3P base data schema,
we suggest developing a new data schema for the i-mode data
elements. P3P has been designed to allow new data schemas to
be created easily.

> The location data collected by Web servers in the above services 
> are specific to users who use the Web via mobile phones, and then 
> those location data can be included only in the "Other" category of 
> Data Categories defined by P3P 1.0 Specification. Yet location data 
> services via mobile phones seem to expand hereafter, and location 
> data  accumulated by Websites could cause serious privacy 
> concerns. We, therefore, propose the installation of a new 
> "Location data" category. At least, we think such location data 
> should be refered in Categories section.

We will add a "location" category to the specification.

> NTT Communicationware and other companies provide services that 
> enable mobile phone users to browse via the i-mode their private
> information that they input on PC browser and store in Web servers. 
> In these services, the following information are stored in the companies' 
> Web servers.
>? The address book of user (such as names and phone number of 
> acquaintances)
>? The schedule of user 
>? The list of tasks the user have to do
>  These personal data may be collected by Web servers even in 
> case of use of some terminals other than the i-mode phone. The 
> emergence and expansion of Application Service Providers (ASPs) 
> will make users store more and more information about them in 
> Website databases. These above personal data can be included 
> only in the "Other" category of Data Categories defined by P3P 1.0 
> Specification, but we ask the P3P WG members to refer to such 
> data in P3P 1.0 Specification.

This type of data could be represented with the "content" category.

> 1.Assurance of Policy Identity When a Website Change its URL 
> Proposal: An indicator is required that indicates invariability of a
> policy when a Website changes its URL and its privacy policy URL but
> does not change its content and policy.
> Reason: Such an indicator shows users that a Website's policy is not
> changed though the Website has changed its URL. This indicator also
> warns users that a Website changed its policy at the time of URL change.

The consensus of the working group is that Website URL changes are
rare, and that it is not unreasonable to expect user agents to
fetch new policies when a Website URL changes. 

> 2.Classification of Collected Data within Websites
> Proposal: When a Website changes its policy into more invasive policy,
> this Website should inform its new policy to users and obtain new
> consents from users about data usage that is beyond the original data
> usage on which the Website has already come to an agreement with their
> users. In addition, in the same case the Website should classify
> collected data as to purposes and recipients to which the users
> consented, so as to obtain new consents about excess data usage. We
> think the above instructions should be included in P3P Guiding
> Principles.

The working group will discuss the possibility of adding something
like this to the Guiding Principles. We will probably not address
this until after we finish addressing the technical changes to the
specification.

> 3.Third Party Policy Labeling
> Proposal: P3P 1.0 Specification should mention as an example of P3P
> implementation that P3P policies of Websites can be created and labeled
> by third parties unrelated to the Websites. 
> Reason: Introduction of P3P policy by a large number of Websites is
> crucial to diffusion of P3P standard. But there seems to be only a
> handful of Websites that will create their P3P policy by themselves.
> Third party labeling of P3P policy will encourage P3P adoption in
> browser (client) side, and promote diffusion of P3P standard.

Third-party labeling with P3P policies is beyond the scope of P3P1.0.
In general, it is difficult for third-parties to make judgements about
the detailed data practices of a company. It is  more likely that a 
third-party would make simple judgements, which could be expressed
as PICS labels or RDF metadata.

Regards,

Lorrie Cranor
P3P Specification Working Group Chair
Received on Tuesday, 2 May 2000 23:32:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.1 : Tuesday, 21 September 2004 12:14:16 GMT