September 20, 2002

Citigroup P3P Position Paper

Citigroup companies are in the process of implementing P3P as a potentially valuable tool for consumers browsing the Internet. However, we recognize that P3P is still an unfinished product. For example, it does not yet have a sufficient vocabulary or structure to cover many current and future needs for legally adequate privacy statements. There is no enforcement structure for those developing User Agents. This results in legal and media risk for companies implementing P3P that needs to be addressed and resolved if P3P is to fulfill a very important need.

We would like to address three concrete suggestions for moving this forward. There is an immediate need for the W3C to make recommendations and allowances for human readable policies that are more expressive but not inconsistent with the P3P policy. This human readable policy should be allowed to co-exist with the P3P policy and to control with respect to legal obligations. Over time, this situation should be addressed by expanding the P3P specification and language to allow for a richer expression of privacy considerations. Third, the W3C also needs to address how to enforce compliance across P3P User Agents so that a company can implement P3P policies that are interpreted consistently and correctly.

The critical near term need is an agreement or process that allows for Human Readable On-Line Privacy notices to control. The reason for this is that privacy notices can be the basis for legal and regulatory action against companies. Since P3P does not claim to be a legal context, and since P3P has not yet developed a language to make this legal context possible, the dominance of the Human Readable notice is the only way to provide legal certainty to corporations, government agencies, or others who implement P3P on their Internet sites.

The Human Readable notice can provide additional explanatory text to the user that would likely be inappropriate to include in the P3P statement. For example, an explanation as to why certain personal information that, although not necessary for transaction processing or marketing, is being collected for regulatory reasons (such as "know your customer"), and that under certain, not completely defined circumstances, could be released to the appropriate authorities. There may be legally required statements, such as information about possible monitoring and about cross border transfers. In the case of GLBA and HIPPA, there may be a distinction between the sharing of information under an accepted legal purpose or exception and sharing that is subject to an opt out or an opt in.

In fact, as recently noted, the interpretation of a P3P Privacy Statement is subject to the working of the User Agent, such as the IBM Privacy Bird or the IE6 implementation. The same P3P policy could be represented to users in ways that may be counter to each other as well as to the intent of the site. Until this possibility ceases to exist, the W3C may even notify companies implementing P3P of the legal and reputation risk they may face if they do not clearly tell the user that their Human Readable Privacy Statement is their only legally binding statement. To do less may jeopardize P3P if companies come under attack for legal actions due to language over which they have no control.

One method of doing this is to 1) add clarifying verbs in P3P and 2) define the conditions under which a human readable privacy policy may have appropriate legal and regulatory caveats. This definition may be by way of representative, but not exhaustive, examples of how to do this in a way that remains consistent with the P3P privacy statement. For example, "we don't share" from a company that complies with GLBA regulations should allow financial service companies to share as required or allowed by law under the GLBA exceptions.

This moves us to the second point, the need to continue to evolve P3P so that it is a more satisfactory communication tool, both in structure and in language. For example, with the advent of Aggregation, Web Services and Federated Authentication, privacy issues get still more complex.

Example 1: How do you express shared liability in a circle of trust as customer data is shared across organizations that do not have the same privacy policies? Which privacy policy dominates? What steps should a customer take if she wants to understand how her data is to be treated?

Example 2: What do you tell a customer who is about to request that her data be sent to an aggregation service? How is the original data source's privacy policy to be treated? Is it relevant any longer? Does the answer differ if there is no contractual agreement between the aggregator and the original data source?

Example 3: If the legal context for a particular notice, such as cross-border transfer of data, requires a notice in a particular form, should P3P duplicate this process or ignore it, assuming that the company will need to find a way to separately take both actions?

Example 4: If data is shared with a second source at the direction of the customer, what privacy responsibility remains for the original data source over the transferred data? Does P3P need to be able to reflect these circumstances? Should it reflect these in some cases, such as cookies, and not in others?

Example 5: There is more discussion of how to treat the complex subject of how data is treated if there are differences in handling data collected off-line and on-line. If these are governed by different privacy policies, what should be communicated via the P3P statement?

There is much healthy discussion about short privacy notices as an "off-line" best practice. To be able to provide consistent notices on-line and off-line, the P3P language needs to evolve as "short privacy notice" and other efforts shape a framework for printed notices. A communications objective of all privacy notices may be to have consistent structure (order in which topics are presented), language, definitions, required elements, and links.

P3P does not express the temporal nature of privacy policies; that is that privacy policies can change over time due to changes in corporate policy, government laws and regulations, contractual relationships with third parties, and so forth. However, P3P does require companies to keep track of what privacy policy governed when a customer data was collected. Currently P3P allows for an expiry date, but expiration of a policy cannot really be planned in all these cases (e.g. the passage of a new government regulation such as the Patriot act, HIPPA). A new policy can arise before the expiration of a current policy, so one needs to be able to denote what over dates a privacy policy actually was in force and what data was collected during this interval governed by the existing privacy policy. And furthermore, we need to be able to express how one intends to treat data collected during a period governed by one privacy policy, in the future, when a new privacy policy is in force; especially if it becomes impractical to keep track of exactly when data was collected. This would lead companies who are strongly aware of legal and compliance risks to craft a P3P statement that would take into account possibilities for the foreseeable future. Companies without this level of legal counsel may get trapped as laws change purely due to limiting technology and not customer risk or customer desire.

This brings us to the final question of what a site needs to do to be considered compliant with the P3P specification in light of the fact that User Agents have the ability to set their own rules? If a User Agent implements only a subset of the full, required P3P specification, is it compliant? What if the User Agent adds elements that are not defined in the P3P specification or even takes actions that are not allowed? Does a site need a compact policy, a verbose XML policy, and a human readable policy? Is the site compliant if it implements only the subset implemented by a particular, User Agent? How do we intend to enforce conformance with the P3P standard, so a service provider can implement only one version of P3P and be assured that this standard will operate properly under all browser implementations? For example, should a browser be required to not constrain the operation of a web service that has implemented all the required P3P features, but not the optional features required by the web browser?