Policy Syntax

As much as we'd love to describe the full syntax for P3P policies, it's way too large and detailed for this article. If you must learn it, the specification is the place to go. Learning the syntax, and understanding the following discussion, requires some knowledge of XML—but only the basics. Remember, knowing the syntax is better, so that you can properly audit the code. For the most part, however, developers will be writing these files with tools designed specifically for the purpose.

As noted above, the first P3P file accessed by the browser is called a reference file. Figure 2 shows a simple example that addresses the relevant points.

In a reference file, a META tag that defines the XML schema surrounds the entire contents. The document at www.w3.org/2000/12/P3Pv1 defines the XML namespace for reference files. Inside the META tag is a <POLICY-REFERENCES> section with one or more <POLICY-REF> sections. Each <POLICY-REF> defines the areas in the site to which a particular policy applies. For example, one of my sites contains both public sections and a private section just for Webmasters and developers. The private section has more lenient policies, because we're in charge and trust our own code and cookies. But for the public sections, we need to be stricter about the rules.

As shown in Figure 2, the first policy, described in the policy file policies.xml, applies to every part of the site except the /scripts directory. Notice that the <INCLUDE> section refers to /*, which means everything in the site. The <EXCLUDE> section refers to /scripts/*, which means everything in the scripts subdirectory. Each <POLICY-REF> section can contain any number of <INCLUDE> and <EXCLUDE> sections.

The actual policy files are considerably more complex. A real policy file might take up all the space we have for this article, so we'll use a simple policy file to show some syntax elements (see Figure 3).

At the beginning of the example, inside the POLICY tag is the same XML namespace statement as in the policy reference file. There is also a discuri= clause, which points to the English-language version of the policy in HTML. P3P tools usually generate this. IE6 lets users view this page from the View | Privacy Report... dialog.

Below that is the <ENTITY> that publishes the privacy policy. Next is a <DISPUTES-GROUP> section, which describes the site's dispute resolution procedures (if it has any). Such a section would have references to privacy seal organizations, such as TrustE (www.truste.org), to which the entity subscribes.

Next is the <ACCESS> section, which describes the data collected from the individual granted access by the site. In this example, we allow access to all such data, but there could be a detailed list.

The <STATEMENT> sections that follow are the meat of the document. In the <PURPOSE> section, a series of tags describe why the site is collecting the data. In our example, we collect data for use in individual analysis (to determine the habits or characteristics of individuals), research and development, site and systems administration (such as verification of site activity), and completion and support of current activity (carrying out the task at hand, such as completing a form, forwarding e-mail, and so on). And we also use the <other-purpose> section to indicate that we collect data for emergency contact.

These purposes also have optional opt-in/opt-out values, which indicate the following:

  • Opt-in: The data is not used unless the user allows it to be.
  • Opt-out: The data is used unless the user chooses for it not to be.
  • Always: The data is always used; the user has no choice.

    You can represent these purposes as compact policies. In our example, the compact policies would be

    IVAi - <individual-analysis/ opt-in>
    DEVi - <develop/ opt-in>
    ADMo - <admin/ opt-out>
    CURo - <current/ opt-out>
    OPTa - <other-purpose always> emergency contact</other-purpose>

    In this case, immediately something is lost in the translation, because compact policies don't allow any elaboration on the <other-purpose>. From compact policies alone, we don't know that the information is used for emergency contact.

    The next section of the full XML policy states that the entities receiving the collected data are our agents and ourselves (<ours/>) and other entities sharing our policies (<same/>). The compact policies for these would be OUR and SAM. Next, we indicate that we retain the data indefinitely (compact policy IND).

    Finally, the actual data we collect is described. In our example, we are retaining users' name information and e-mail addresses.

    We don't, however, discuss numerous options in this example; be sure to check the specification for details. But as we said above, these policies were designed to be written by software tools. The W3C maintains a list of current tools at www.w3.org/P3P/implementations, and we briefly tested two of them. The IBM P3P Policy Editor (www.alphaworks.ibm.com/tech/p3peditor) is a Java application that generates full and compact policies as well as an English explanation of the policies in HTML ( see Figure 4 ). The tool is rather complicated and sparsely documented, and IBM doesn't seem to monitor the discussion board through which support is provided.

    Microsoft's Privacy Statement Generator (www.microsoft.com/privacy/wizard) is a Web application for generating policies. It's not bad, but you need a Microsoft Passport, such as a Hotmail account, for validation. The program operates as a wizard and generates HTML, full XML, and compact policies. When we tested it, it didn't let us specify whether the user can opt in or opt out of a data collection practice. But because it's a Web application, it could easily change by the time you read this.

    A wizard is easier to deal with, especially if you're new to P3P policies. A wizard is mindful of what you've entered and asks the appropriate questions next. And because a wizard logs you on through Passport, you can come back later and edit other policies. The IBM tool also has wizards, but the Microsoft wizards are much easier to deal with and ask much clearer questions. Overall, we prefer the Microsoft tool for initial policy generation. Then, if you have detailed policy work to do, you'll have better luck reading those policies into the IBM tool or another third-party tool for work on them. Check back with the P3P implementations page, as this is a nascent tool market.

    You might conclude that P3P privacy policies are complicated enough that they will not be implemented widely and completely any time soon. Unfortunately, the issues with cookies mean that Web developers can't ignore them. IE6 is here, and unless you expect users to turn off privacy protection, you've got some work ahead of you.