Summary

  • W3C issued P3P 1.0 as a Recommendation on 16 April 2002. Its XML policies expressed a site's stated data practices for software to retrieve and compare with a visitor's preferences.
  • A policy-reference file mapped URLs and cookies to the applicable policy. The browser had to find that file, resolve the matching reference and fetch the policy before it could make the comparison.

The privacy policy is somewhere on the site. A visitor can hunt for a link, open it and try to remember whether the checkout form, the account page and a cookie belong to the same set of promises. A browser asked to do that work cannot shrug and read the footer. It needs a route to the policy governing the particular request. In 2002, W3C gave that route a format and, in one example, named the troublesome cookie obnoxious-cookie. The standards meeting had apparently run out of polite names.

The P3P 1.0 Recommendation of 16 April 2002 described privacy practices in XML: what data a site said it collected, the purposes of use, categories and recipients. Its sample visitor, Claudia, goes to CatalogExample. Her browser obtains the site's P3P policy and compares the stated practice with the preferences she gave it. That small scene explains the ambition. The page carries the service; a separate machine-readable statement tells the browser how the service says it handles data.

Finding the statement was its own job. A P3P user agent had to locate a policy-reference file, fetch and parse it, then fetch and parse the policy it named. A site could place the reference at the well-known path /w3c/p3p.xml, point to it from an HTML link, or indicate it with an HTTP P3P header. The reference file was the map; the policy was the destination. A browser that found a policy without finding its scope would still have the wrong answer for the wrong page.

The map's POLICY-REF entries identified policies and the parts of a site's URI space they covered. They could also include or exclude cookies. Order mattered: when more than one entry matched a URI, the first applicable entry in the file controlled the choice. That made the reference file more than a tidy table of contents. Its ordering could decide which declaration a visitor's browser read for the same address.

The specification's cookie example is gloriously blunt. One policy covers cookies generally while excluding obnoxious-cookie; another reference includes that named cookie. The example shows why policy scope could not be inferred from the page alone. A browser might be loading one page while a cookie from that site followed a different path through the policy map. The name is comic; the routing problem is exact.

A map also has a clock. P3P's EXPIRY told user agents how long a reference file or policy could be used; without an explicit value, the lifetime defaulted to 24 hours. The Recommendation required a site changing its policy to keep records of earlier policies and the dates they applied to previously collected data. W3C announced P3P 1.0 that same 16 April. The design put privacy prose on a route a browser could follow, down to the page, the cookie and the age of the directions.