The following is a proposal for future work on P3P submitted following the November 2002 Workshop on the Future of P3P
The abbreviated syntax of Compact Policies, CPs, and the delivery system via the HTTP P3P header stems from the belief that Full (XML) Policies cannot be presented at cookie set time. This belief is held because Set-Cookie headers are received and acted upon in the initial response to an HTTP delivered asset. It is upheld that discovery of a Full Policy prior to acceptance of a cookie would be difficult/resource intensive for a User Agent, UA.
This lack of Full XML Policy, and the extensibility therein however creates numerous issues particularly with regard to accuracy.
Possible areas of exploration could include:
As this is entirely a User Agent issue, resources for this project would likely need to come from UA developers with input from all members of a future working group.
These issues are difficult to resolve and are highly dependent on user experience - which it self highly dependent on issues such as average user bandwidth, internet latency and connectivity. The need to resolve this issue may be hastened by the legal interpretations of the inherent inability for CPs to be sufficiently nuanced.
P3P assumes "Accuracy" between all policies related to given data collection, including: Natural Language Policy (which is itself a requirement of P3P), a Full XML policy and a Compact Policy (if used). To accommodate a data collector's need to describe their practices, P3P has a base data schema and the ability to extend that schema to accommodate particular collector practices where those practices cannot be accurately described within the existing schema. The difficulty with Compact Policies, CPs, is that they allow for only a subset of the functionality of the Full Policy with no ability to extend or accurately group practices. The result of which is an in ability for a data collector to be truly accurate with the limited syntax. This then implies that to be accurate in a CP the data collector MUST overstate.
Currently the CP allows a collector to make statements from among the following predefined groups: <PURPOSE>s-12, <RECIPIENT>s-6, data <CATEGORIES>-16, <ACCESS>-6, <RETENTION>-5, <DISPUTES>-1, <REMEDIES>-3. This effectively limits a CP implementer to the requirement of accurately representing his/her NLP by choosing from ~49 predefined tokens (the UA rendering of which the collector will have no control - but from which they will be liable).
This lack of nuance forces a data collector who e.g. associates a cookie with a proclivity to examine cold remedies with a category that also includes "mental health" and "sexual orientation". It is extremely possible that such statements may be illegal within the effected jurisdiction or specifically against the NLP expressed practices of the data collector.
Possible areas of exploration could include:
The size of this issue requires the resources of a full working group.
To me this problem is fundamentally the question of trading off between the accuracy requirement in the spec (which are likely to be upheld by enforcement agencies) and the performance increases of the Compact Policy.
Full P3P XML Policies allow for individual <STATEMENT>s within a <POLICY> to effectively group <PURPOSE>s, <RECIPIENT>s and data <CATEGORIES>. The Compact Policy does not have a <STATEMENT> element and it is therefore impossible to produce these logical groupings. The result of this is an overall aggregation of all declarations that may provide an imperfect description of the data practices related to the cookie.
For instance, a full policy can say that data <CATEGORIES>:: <FINANCIAL>, <GOVERNMENT>, <ONLINE> where used for <PURPOSE>s: <CONTACT>, <INDIVIDUAL-ANALYSIS>, <INDIVIDUAL-DECISION> internally by <RECIPIENT>::<OUR>, but also in a separate <STATEMENT> that <CATEGORIES>::<DEMOGRAPHIC>, <COMPUTER>, <UNIQUE> to be used for <PURPOSE>:: <PSEUDO-ANALYSIS> by <RECIPIENT>::<UNRELATED>. This has a vastly different meaning than the current CP rendition (FIN, GOV, ONL, COM, DEM, CON, PSA, IVA, IVD, OUR, UNR), which would imply PII information being given to an unrelated 3rd party.
There is a need to create a <STATEMENT> like grouping mechanism within the CP. This would require some change to Compact Policy. I see several ways that this could be achieved:
As this will involve UA producers and the 1.1 working group
Last update $Date: 2003/05/23 13:58:13 $ by $Author: rigo $