A sample P3P file (Cont.) - Page 3

If you're not familiar with XML, just think of it as an anally-retentive version of HTML with an infinite number of tags. It's unlikely that the original developers ever imagined it would be described that way, and it's not even 100% accurate, but it's a useful description for the real world. The two important things to remember about XML are that it always requires closing tags and it absolutely will not tolerate errors.

The file starts with the usual introductions - the XML version and P3P version that apply. This is quite similar to the Doctype declaration included just before the start of an HTML file. Then comes the URL and name of the equivalent human-readable privacy policy.

Now we get the first block of data, highlighted in the example in blue. This is the description and details of the company or individual making the privacy statement, otherwise known as the Entity. In this case the details include a full postal address as well as email.

Our next block of data is the small Access section, highlighted in red. This informs users how much of the information they are allowed to access from the records the company holds about them. Entries here vary from "all" to "none". In theory it's one of the most important elements of file, but of course if it's set to "none" it's no great help to users.

Third in our breakdown is the Disputes-group, highlighted in green. Here the company (entity) explains what users can do if they have a dispute over the privacy policy of the site. There are two main elements to this - the "service" section and "independent" section. The service section gives information for settling disputes directly between the user and the site without third parties becoming involved. The independent section gives details of third parties that can become involved in the dispute if the user wishes.

In the service section a company email address is usually specified, that can be used to contact the company in the event of a dispute. Often it's a repeat of the email address given earlier in the Entity section. Some sites merely refer to a relevant HTML page.

The independent section gives contact details for the independent privacy organisation that may be contacted in the event of a dispute. Often it also includes a URL and a long description of the independent organisation's aims. Two relevant organisations are BBBOnLine and TRUSTe. You might like to note that privacy campaigners have sometimes disputed the independence of corporate-funded privacy organisations.

Now we come to the final and most difficult section of the file, dealing with the site's collection and use of data, including from cookies. In our example, this is presented in two sections, a purple section and final blue section, but you'll find many variations in how real sites deal with this element of the file. Sometimes there's just one section covering almost everything. Sometimes there's an additional section covering the information collected from registered users, and many times cookies are given their own section rather than being combined with anything else.

It can be difficult to work out what each section is for, and either the P3P specification itself or the sites using it seem to get in a bit of a muddle when it comes to differentiating between information collected from all users and information collected from registered users.

Let's investigate our example in more detail.

The first (purple) section deals with information collected from all users, and the second (blue) section deals with users who go on to make a transaction with the site. Each section begins with the <STATEMENT> tag and ends with </STATEMENT>.

The first section starts off with the <CONSEQUENCE> which isn't really a consequence, it's actually the reason why the information is collected. Then we have a <PURPOSE> which is a more quantitative assessment of the reasons for collecting the information and its uses. The entries here are selections from multiple choice options, so are more strictly defined than the Consequence, which can easily lapse into meaningless marketing talk.

In the <RECIPIENT> area we get to learn who receives the information, and under <RETENTION> we find out how long it's kept for. Under <DATA-GROUP> is the list of collected data. <CATEGORIES> tells us the broad categories of information collected.

The second (blue) section follows a similar pattern, but here we have two sets of data in the <DATA-GROUP>. The first includes clickstream data, in other words the sequence of pages the visitor clicks through, and cookies. It doesn't exactly say what information is collected, but it does say what it's used for, under <CATEGORIES>. Then a final set of data is mentioned close to the end, covering information collected from HTTP headers, and any search-strings the users enters into the internal search mechanism.

That's enough of an introduction to the content, now let's look at where the file goes.

Policy Reference File

The main file analysed on the previous page can be slotted anywhere on a site, and in practice these files are found in many places under different filenames. Continuity and predictability are provided by the Policy Reference File, which is a small XML file that points the way to the big one. This is always called p3p.xml and placed in a folder named w3c, directly after root. So for www.zzzz.com the file address would be www.zzzz.com/w3c/p3p.xml

Here's an example of a p3p.xml file:

<?xml version="1.0" ?>
- <META xmlns="http://www.w3.org/2000/12/P3Pv1">
- <POLICY-REFERENCES>
- <POLICY-REF about="http://www.tinhat.com/privacy/policy.xml">
<INCLUDE>/*</INCLUDE>
</POLICY-REF>
</POLICY-REFERENCES>
</META>

The important line is the one specifying the location of the big XML file.

Under the full W3C specification, there are some alternatives to this system, which is called a "well-known location," but in practice it's the method most often used.

If your site delivers cookies, there's one more stage to go - the creation of a Compact Policy.

A sample P3P file - Page 2
P3P - Platform for Privacy Preferences
Compact Policy - Page 4