Compact Policies

The following is a proposal for future work on P3P submitted following the November 2002 Workshop on the Future of P3P

1. Compact Policies Performance Issues

1.1 Purpose

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.

1.2 Scope

Possible areas of exploration could include:

1. Empirical study of effect on UA performance with real time discovery of Full Policy through PRF of cookie policies
2. Possibility of "cached" Set-Cookie's Statements pending subsequent resolution on related Full Policies.
3. Pre-fetching and storing Cookie Policies within allowed expiry for given hosts

1.3 Resources

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.

1.4 Time Frame

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.

2. Semantic Issues

2.1 Purpose

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.

2.2 Scope

Possible areas of exploration could include:

1. If accuracy and consistency across NLP<->XML<->CP is core to P3P but unachievable by the CP do we scrap the accuracy requirement or the CP? Is there a better balance to be found? Or a better language construct than accurate.
2. Examine what exactly we are trying to achieve with the CPs? Do we allow it to be a performance optimisation only as an imperfect placeholder until a Full policy can be discovered?
3. Consider adding a token which denotes the "up to and including" nature of the statements made by a CP or should this be better explained within the spec with more delineated requirements for UAs.
4. Consider adding more tokens to allow some degree more nuance.
5. *It should be noted that a number of these issues overlap Question 1. Vocabulary Issues

2.3 Resources

The size of this issue requires the resources of a full working group.

2.4 Time Frame

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.

3. Grouping Mechanism

3.1 Purpose

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.

3.2 Scope

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:

1. Recreation of the <STATEMENT> element through new tokens "STA" and "/STA" allowing for valid and consistent groupings within.
2. Use of parenthesis, brackets or other grouping delimiter to achieve the same without directly implying all the properties of the <STATEMENT> element.

3.3. Resources

As this will involve UA producers and the 1.1 working group

3.4. Time Frame

No indication

Last update $Date: 2003/05/23 13:58:13 $ by $Author: rigo $