IV. Creating, Testing and Deploying P3P Files
- Creating, Testing and Deploying P3P Files
- Information to Have at Hand When Before Starting to Generate P3P policies
- Create P3P files with a P3P Policy Generator Tool
- Review the P3P Files Created by the Generator
- Discussion of Cookies and P3P
- Create a Deployment Plan
- Testing P3P Files on Your System
- Getting Help
- Tracking and Maintaining P3P Policies
- Conclusion and Guide to Appendix
IV. Creating, Testing and Deploying P3P Files
In this final section, we present a more technical discussion of how to create, test and deploy P3P policies, but we start with a review of the information that you should have at hand before generating the P3P files. Both technical and non-technical P3P team members should still be involved. You may find that the technical team members are better suited to take the lead with creating the P3P files themselves and in referencing the P3P Specification document when necessary. Other team members can still provide important input through the review process.
a.Information to Have at Hand When Before Starting to Generate P3P policies
To efficiently generate P3P policies using one of the available tools, you should pull together the information discussed in Section 3 and you should have already decided how many P3P policies you´ll need, which directories, cookies and areas of your Web site they each apply to, and the data practices (e.g. retention, access, purposes, data elements) that apply to each. (See Page 36 of Section 3)
Before starting to generate P3P files, you should be able to answer each of the questions in the P3P Preparation Checklist below. Most categories should be familiar from your data gathering process and the P3P introduction in Section 3.
P3P PREPARATION CHECKLIST
1. Entity: What is the name, address and other contact information for your organization? This is referred to as the
- e.g.Entity: CatalogShopExample
4000 Lincoln Ave.
Birmingham, MI 48009
+1 (248) 392-6753
Multi-national organizations may want to include multiple entities depending on the home-country or language of the visitor. See P3P Spec Section 2.4.2, entitled
Multiple Languages, to see how to indicate that localized versions of your P3P policy are available.
- e.g. http://www.CatalogShopExample.com/privacy.html
3.Access: What is your organization´s policy about letting web site visitors access identifiable information about them (e.g. to correct address information)?
- e.g. Customers can access their identified online and physical contact information through an 800 number call center in order to correct discrepancies and update records with new address information. No access is given to other data that may have been collected about users.
For more information on this question, See P3P Spec Section 3.2.
The ACCESS Element.
4.Disputes: What seal programs or other privacy related enforcement programs do you participate in? These are listed in the
Disputes section of the policy.
- e.g.Our web site belongs to Trust-E´s privacy program.
For more information about this question,
See Section 3, page 39
See P3P Spec Section 3.2.6
The DISPUTES Element
For more information on REMEDIES which is part of the DISPUTES-GROUP element,
See Section 3 at 39 See P3P Spec 3.2.7
The REMEDIES element
6.How Many P3P Policies do you need to create for the Site and the cookies you use?
a) How many
full P3P Policies?
- e.g. We´ve decided to create three full policies: one for the home page and company information section of the web site; one for the shopping cart area and one for the special contests area.
b) How Many
compact P3P Policies (e.g. for cookies)
- e.g. We´ll have two compact policies - one for the shopping cart cookie and one for our site´s global cookie. We don´t have any third party advertisers or third party content fed to the site.
- Note: It is exceptionally difficult for a site to have multiple compact policies where unique cookies are used on a domain level (this is nearly everyone). The reason is that if cookie
guid has policy
little info and cookie
shoppingcart has policy
lots of info and both are logged simultaneously now guid=shoppingcart=
lots of info.
For more information about how many P3P Policies you should create,
See Section 3 at 32
See P3P Deployment Guide Section 2.2
How Many Policies for the Site? at
7.For each P3P Policy that you will need to create,
How will you refer to them? (e.g. give them useful labels to help with administration)?
- e.g. (1) Basic policy; (2) Shopping policy; and (3) Contest policy.
What areas/pages/forms will does each P3P Policy apply to?
- e.g. The Basic policy applies to all URIs beginning with:
The Shopping policy applies to all URIs beginning with:
The Contest policy applies to all URIs beginning with:
For more information on P3P Policies and URI references,
See Section 3 at 32
See P3P Spec 2.3.3
Applying P3P to a URI
See Deployment Guide Section 2.1
What Does a Policy Cover?
8.For each P3P Policy, consider the collections of information that will happen under that policy and answer the following:
A.What are the types of data collected? Fit them into
data groups that are treated similarly.
- e.g. Within our Shopping policy we collect three types of data:
Access Log Information, and
Shopping Profile Data.
Refer to the Base Data Schema defined by the P3P Specification and discussed in Section 3 page 37 to identify which data elements are collected. See also Appendix A.
These data groups can be used to designate different
Statements within the P3P Policy. Some of the P3P generator tools have created suggested groupings that you may find useful.
For more information on Statements,
See Section 3 at page 36
See P3P Spec 3.3
B.For each data group,
i) what are the
Purposes for which your organization collects and uses the information within that data group?
- e.g. For the Transaction Data group we use the information for:
Completing the current transaction (shipping product)
Research and development about shopping trends;
Individualized personalization of the web site on repeat visits;
Contacting the individual for follow-on service and product offers;
Retention for accounting and legal purposes;
a) For each Purpose, are there
opt-out options available to your Web site visitors?
- e.g. Users can opt-out of have their transaction data used for personalization or for follow-on product offers;
For more information on Purposes,
See Section 3 at page 37
See P3P Spec 3.3.4
The PURPOSE Element
ii) who are the
Recipients of information you collect in the data group?
- e.g. We only share our Transaction Data with third parties that are involved in shipping and handling of our shopping orders unless user opts-in to a special partner program.
a) For each Recipient (e.g. unrelated third parties), are there
opt-out options available to your Web site visitors so the visitor can inform you not to share their information with that recipeint?
opt-in to special partner marketing programs with third party companies.
For more information on Recipients,
See Section 3 at page 38
See P3P Spec at 3.3.5
The RECIPIENT element
iii) what is the Retention policy for the data you collect within the data group?
- e.g. We store
transaction data for three years.
For more information on Retention,
See Section 3 at page 39
See P3P Spec at 3.3.6
The RETENTION element
b. Create P3P files with a P3P Policy Generator Tool
Vendors are beginning to develop and release helpful tools to automate the process of generating P3P files. It makes sense to try to at least begin creating P3P files with a file generated by such a tool. The policy generators can help with XML policy creation, but they may not perfectly capture your intentions. Therefore, use them as a starting point but do not completely rely on the output as a representation of your company´s P3P policies without a detailed review.
Availability of P3P Policy Generator Tools
As P3P is a relatively new specification, new or updated versions of P3P policy generators are coming onto the market relatively frequently. For an updated list of P3P policy generator tools, please visit www.p3ptoolbox.org or email email@example.com.
c. Review the P3P Files Created by the Generator
Once you´ve successfully generated a set of P3P files using a P3P generator tool, take some time to familiarize yourself with the files that were generated and confirm that they capture your data practices correctly. As you review the files, you´ll notice that all the files are text files but some are written in XML, some are written in HTML, and the compact policies are just short strings of text.
The generated policies can be validated with the W3C´s P3P Policy Validator, which can be found at http://www.w3.org/p3p/validator. This is an extremely helpful tool that can provide information on any errors in your P3P implementation.
Below is a discussion of each file or type of file that may be part of your P3P implementation including some key elements that you should review within that file.
Location: Up to site administrator.
P3P Policy Reference File (p3p.xml)
Use: The P3P Policy Reference File (PRF) is the first file that a user agent, such as a P3P-enabled Web browser or P3P plug-in, will look for when visiting your Web site. It provides a map of where the Web site´s P3P policy (or policies) are located (using the URI for the P3P Policy File) and which P3P Policy is associated with each directory, web page, other web resource, or cookie. It also provides information about how long the PRF is valid.
File Type: Text file using XML syntax.
Location: The file should be placed in the /w3c directory on the server (called the
Well-known location) and named p3p.xml. In addition, a site admin may have the server send an HTTP response header giving the location of the reference file (
HTTP header approach) in any response from the site, or configure the site´s HTML content to contain links to the reference file (
HTML link tag approach) in each page on the site. Although using the well-known location is the preferred method. Some sites may need to consider a mix of methods because they do not control the whole web server and cannot deploy files to the well-known location. For example, someone who controls a personal page on a multi-user server cannot deploy P3P using the well-known location for their personal page, because they do not have permission to place files in that directory. Each of the three approaches is discussed in detail in Section 3 of the P3P Deployment Guide at http://www.w3.org/TR/p3pdeployment.
Key points to review: There are several points in addition to basic syntax to check within the P3P Policy Reference file.
- First you want to ensure that the INCLUDE and EXCLUDE statements within the PRF correctly associate the various P3P Policies that you have created with the relative directories of your Web site. For example, there may be a broad INCLUDE statement using an asterix (
*), a wildcard representing any characters, to denote all directories or files at that level. There may also be several sections carved out using EXCLUDE statements. EXCLUDE statements have priority over INCLUDE statements, so you have to review all the statements together to get the correct picture of which directories and web pages are associated with a particular P3P Policy.
- The first PRF element which covers a resource will also be used to find the policy.
- The display of the privacy report in Microsoft´s Internet Explorer depends on a valid PRF.
- Are the cookies addressed in the PRF? Even if you use a Compact Policy when you set cookies, you should have the cookie listed in the PRF using a COOKIE INCLUDE statement. That line should point to a full P3P Policy for that cookie. Failure to do this may cause errors when a user tries to access more information about the cookie using a P3P user agent. (See discussion on Cookies below.)
P3P Policy File (default name is policy1.xml)
Use: The XML P3P Policy File is the machine readable file that holds one or more
File Type: Text file in XML format.
Location: Up to site administrator.
Number: At least one but perhaps more depending on number of distinct full P3P Policies that the organization elects to implement and how the site administrator wants to manage them. When a user agent requests a particular Web page, this is the file that is read to compare the applicable P3P Policy to the user´s privacy preferences. A site may keep all P3P Policies separate in different files or combine them into one P3P Policy File by using unique URIs that designate sections of the P3P Policy File. For example,
/P3P/Policies.xml#second would direct a user agent to different sections within the same P3P Policy File.
You can go one step further and combine the P3P Policy File and the Policy Reference file using the POLICIES element discussed in the P3P Spec section 3.2.1.
HINT: When editing a P3P XML file, make sure the file is saved as a text file or an XML file not as a word processing file.
P3P Policy (One or more P3P Policies are located in each P3P Policy File)
URIs). In addition, a cookie which uses a
compact policy should also have a corresponding P3P Policy.
Each P3P Policy may be made up of one or more
privacy statements (the STATEMENT element in P3P syntax). Each privacy statement within a P3P policy describes the data, elements, purposes, recipients, and opt-in policies applicable to a set data elements collected in that area of a Web site. For example, a Web site´s P3P Policy for its shopping area may include three statements: one each for (a) access log information, (b) transaction data like the customer´s shipping information; and (c) customization data such as a standard set of store items that the customer can order with one click.
Key Points to Review: First, make sure that the P3P Policy includes an appropriate set of
STATEMENTS and that each statement includes the correct set of data elements, purposes, opt-out/in options, and recipients. (For example, if there are opt-in or opt-out choices available to users, make sure that the policy includes the OPTURI element to point to a description of how to opt-in or out.)
Providing better Notice to Web Users: Each statement within a P3P policy can have a
CONSEQUENCE field that provides a human-readable explanation and can be presented to users by the user agent (e.g. in a Privacy Report within Internet Explorer or a Privacy Summary using the AT&T Privacy Bird).
ADVANCED TIP: More complex implementations may consider using the METHOD element in policy reference files to associate different P3P policies to a URI depending upon the method (e.g. GET, POST, etc) used to request that resource.
Here is a sample compact policy:
NON DSP ADM DEV PSD IVDo OTPi OUR IND STP PHY PRE NAV UNI
Use: Compact policies are a set of three letter tags that serve as a short-hand representation of P3P Policy for a cookie or set of cookies. Compact policies are an optional element of P3P but certain P3P user agents rely on them more than others. There are a variety of factors to consider when using compact policies. Using compact policies for cookies may enhance the performance of a Web site using P3P, depending on how the P3P user agents access the Web site.
Compact policies should be translated from the full P3P policy for a cookie. Compact policies have less granularity than do full P3P policies. If the full P3P Policy contains multiple statements, then all of the data categories, uses, and recipients across all of the statements are merged when the compact policy is built. This loss of granularity can make a site's data use practices appear more privacy-invasive than they actually are. When writing the site's P3P policy, you should carefully examine the contents of the resulting compact policy, and make sure that you are comfortable with the way it represents your site's practices before using the compact policy.
Great care should be taken in generating compact policies. Most editors help you generate policies for the site only. Domain level cookies or site level cookies that tie to domain level cookies aggregate policies across not just the setting site but all hosts on the domain whether P3P compliant or not will not have policies generated by editors.
Lifetime: Compact policy will apply to the cookie for the lifetime of the cookie (which may be a long time) so be sure to consider how long a cookie should really live.
Advanced Question: What if I need to change the P3P policy for a cookie? Because a compact policy must be honored for the lifetime of the cookie, changing the P3P policy applicable to a persistent cookie can be difficult from a compliance standpoint. It may be necessary to stop setting cookies using the first cookie name, stop processing information gathered from the first cookie, and then begin setting a new cookie with the new P3P policy to perform the cookie´s function.
It should also be noted that the nature of a cookie to send WITH the request for an asset - so that the cookie is being sent before the server could ever notify the user agent that a change was made. This puts the onus on the server not to use the cookie.
File Type: Actually not a file but rather a short string of text that is communicated in the HTTP response header when the user requests a particular URI.
Naming cookies: When using compact policies, sites will generally want to use a pattern in the name and/or value of the cookie that can be easily specified in the Policy Reference File. When the cookie is replayed, this should help the site determine under which compact policy the cookie was served, or at least whether the compact policy is compatible with the site's current practices.
Number: Sites will use compact policies only if the site sets cookies. One compact policy covers all of the cookies in the response that it comes with.
Key Points to Review: Does the set of short-hand P3P elements accurately describe the types of data that are either (a) collected by the cookie OR (b) associated with the cookie? Just because the cookie itself may only collect non-identifiable information about a visitor, if it uses a unique id that is linked to the visitor´s personal information at some point, such as when the visitor purchases a product on the site, then the cookie is also considered to be collecting personal information.
ADVANCE TIP: Declaring Uses Linked to Cookies
You also need to declare uses linked to the cookie and not just the cookie itself. If a cookie is a unique id and that unique id is linkable to e.g. a CRM system then all the data and uses within CRM are now an extension of that cookie. Why? Because id=abc123 viewing a page is now exactly the same thing as John Smith Income=20k, etc. viewing a page.
Sites need to take extreme care in setting a cookie as they are often re-purposeable. A site could easily assign a
GUID on the Web site to track unique visitors, but if the cookie is replayed to any site where a user logs in (say the company intranet site or a help page) then the cookie now ties a great deal of information to what the user does at Web site. This can happen accidentally or it can happen intentionally but the P3P result should be the same.
Additionally, most companies simply cannot control how cookies are used. Imagine a domain level cookie being set at www.domain.com, while shopping.domain.com is hosted by a 3rd party. The cookie set by the Web site is now linkable potentially to a 3rd party data base.
The bottom line most implementers need to remember: you need to be very careful and really think through what is directly linkable to your unique cookies.
Tool for Checking Syntax: There is a tool available to help test the syntax of compact policies. The
P3P Compact Policy Translator by David Grant http://www.davidjonathangrant.info/p3p/ will let you enter the text for a compact policy and then tell you various things about it including how it would be translated and whether it should be accepted as a
satisfactory policy by Internet Explorer. The tool is in currently in beta so results may vary.
Let´s analyze this sample compact policy:
NON DSP ADM DEV PSD IVDo OTPi OUR IND STP PHY PRE NAV UNI
Compact policies follow an order of categories. Some categories are optional. The above compact policy is interpreted as follows:
NON = None
DSP = There is some DISPUTES-GROUP section in the full P3P policy that explains it.
Purposes of Data Collection?
ADM = Used for web site and system administration
DEV = Used for research and development
PSD = Used for pseudononymous decision making
IVDo = Used for Individual decision making and users can "opt-out" of such use.
OTPi = Used for other purposes if users "opt-in" to such purposes.
Recipients of the data?
OUR = The Web site organization itself receives the data.
(since no other recipients are listed, the site is asserting that the data collected by or tied to the cookie is not shared outside the organization)
IND = indefinitely
STP = Retained for stated purpose.
Categories of Data Collected?
PHY = Physical contact information
PRE = Preference information.
NAV = Navigation information (e.g. which pages are visited)
UNI = A unique ID is associated with the cookie
For the full list of compact policy elements, see Section 4 of the P3P Specification.
And here is a sample of the HTTP header request including a compact policy:
A client is requesting a page on the ShoesShop.example.com site, and the site is returning a compacy P3P policy and the location of the site's policy reference file in a single P3P header.
1. Client makes a GET request:
GET /products/prod42-09.html HTTP/1.1
Accept: */* Accept-Language: en, ru
User-Agent: WonderBrowser/5.2 (RT-11)
2. Server returns content and the P3P header.
|HTTP/1.1 200 OK|
CP="NON DSP COR CURa ADMa DEVa CUSa TAIa OUR SAMa IND"
(See the appendix of the Deployment Guide information on how to add HTTP response-headers for some popular Web servers.)
d. Discussion of Cookies and P3P
Ways that P3P addresses cookies:
<COOKIE-INCLUDE name="*" value="*" domain="*" path="*"/>
See P3P Spec Section 126.96.36.199 for a discussion of the COOKIE-INCLUDE statement.
For example if the shopping area of a site sets a cookie which stores a key to look up a user in a company's customer information database and that database holds the user's name, mailing address, and e-mail address. The cookie would be disclosed as follows in the P3P policy(ies) applicable to the shopping area of the site:
3. You should also have a compact policy associated with the cookie itself. This is done by sending the compact policy string of text along with the HTTP header when setting the cookie. The format of this text will vary depending on which web server software package you are using on your site. See Deployment Guide Section 3.1 "Using HTTP Headers" and Deployment Guide Appendix A for a discussion of various implementations.
4. Finally, you should conduct an analysis to determine whether any third parties, as defined by Microsoft Internet Explorer 6.0, serve cookies to your site. This could include advertising or web analysis companies as well as entities within your company's organization that operate under different domains (e.g. www.catalogshop.com and www.catalogshopsales.com are viewed as two different parties because they do not share the same domain. Therefore, if www.catalogshop.com served a cookie to www.catalogshopsales.com it would be treated as a third party cookie. If, however, the domains were www.catalogshop.com and sales.catalogshop.com, they would be treated as first parties because the root domain "catalogshop" was the same.) If you do have third party cookies on your Web site, you'll want to make sure that they have created appropriate compact policies for their cookies. This is important because their failure to do so may trigger privacy alerts to users visiting your site. To do this they will add their own P3P compact policy in the HTTP header that is used to set their cookie. For more information about the Microsoft Internet Explorer 6.0 implementation of P3P, see Appendix B.
ADVANCED TIP: It's important to keep in mind that, as a host, if you set a domain-level cookie, you need to be aware that it could be linked to Personally Identifiable Information by any of (possibly thousands) of sub-hosts.
ADVANCED TIP: If you have third party content that has P3P policies that are not located in the well-known location, you can include the HINT element in your primary Policy Reference File to let the user agent know where to look for the Policy Reference File for that 3rd party content. See P3P Spec Section 188.8.131.52 "The HINT Element" for more information.
Important piece of advice: Don't deploy all at once. P3P can be implemented in stages, enabling you to confirm that each stage is working properly before deploying P3P policies on additional areas of your Web site. So, once you have identified the various categories of P3P policies that you need and maybe even the exact number, create a deployment and test plan.
Here is a sample approach to the deployment:
- Safe Zone. Create and define the Safe Zone area, including the location of the P3P Policy Reference File, where you perform only minimal data collection, and any data that is collected is used only in ways that would not reasonably identify an individual. See the P3P Specification for more information about the Safe Zone practices.
- Home Page. Create a Baseline P3P policy and related P3P files for the home page area.
- Test and implement
- Test live using various browser tools
- Refine as needed
- Learn about all internal servers that set and log cookies (logging is a key way that data becomes linkable to a cookie) See if any of these servers use authentication or host GET forms.
- Learn about all cookies set by hosts on your domain that are hosted by 3rd parties that will be replayed locally.
- Learn about all 3rd parties logging of your cookies
- Cookies. Create compact P3P policies for cookies on the site
- Test, implement, and refine.
- Hot Spots. Create priority list of information hot spots on the site to tackle in order.
- Test, implement, and refine.
- Other Areas. Fill the gaps
Every P3P implementation will require some amount of testing. It is strongly recommended that your company evaluate its P3P policy files in a test environment first to understand how they work and to reduce errors before deploying on their production Web site before final deployment. When deciding your approach to testing P3P, consider the complexity of your Web site, the volume of visitors, your Deployment Plan above and your available technical resources. Below are various suggested steps that you can combine into your own test plan with some advantages of each.
1.Test P3P on your production Web site using the "TEST" element;
- Enables you to run the P3P Validator utility that is available at the W3C site to confirm that your Policy Reference File, P3P policies and compact policies are accessible and do not have syntax errors.
- Enables you to test how the user agents such as Internet Explorer and AT&T's privacy tool react to your P3P policies, although use of the TEST element may affect how the P3P policies are treated;
- Enables you to confirm that P3P deployment does not hinder other functionality on your Web site;
Or, if you have an Intranet that is not open to the Web: Test P3P on your Intranet;
- Enables you to test how the user agents such as Internet Explorer and AT&T's privacy tool react to your P3P policies;
- Keeps the test pages hidden from the public and search engines while you do your testing;
- Enables you to run some of the testing features provided by the P3P Validator utility that is available at the W3C site. If your Web site is not open to the public, you can still use the "File" options under Policy File Validation to check the syntax of individual P3P Policy files by uploading them to the utility.
2. Test P3P on your production Web site after removing the "TEST" element.
- Enables you to run the P3P Validator utility that is available at the W3C site to confirm that your Policy Reference File, P3P policies and compact are accessible and do not have syntax errors;
- Enables you to test how the user agents such as Internet Explorer and AT&T's privacy tool react to your P3P policies in a production environment.
When testing using the user agents, be sure to:
- Change the user-controlled privacy setting and see what happens.
- Access the P3P Explanation Files using the user agent (e.g. "Privacy Report" in Internet Explorer) to see if it displays correctly.
- Access various web pages on the Web site and trigger the setting of each cookie.
Some Common Errors and Things to Check
- Is the Policy Reference File located where it should be? (This will either be in the well-known location (/w3c), if using that deployment method, or the location given by the P3P header, or the location given in the HTML <link> tag which points to the policy reference file).
- Do the INCLUDE and EXCLUDE statements in the Policy Reference File (p3p.xml) correctly reference the locations of the P3P Policy Files?
- Does the Policy Reference File have COOKIE INCLUDE and COOKIE EXCLUDE statements to point to the P3P policy(ies) for the cookies.
- Is the compact policy a straight translation from the cookie's full P3P policy? (The syntax checkers should confirm this.)
- Have you forgotten to remove the TEST element from the P3P Policy files and compact policies ("TST" in compact policies)? The presence of TEST in a policy indicates that the policy is just an example, and as such, it will not be considered as a valid P3P policy by user agents. As a result, tests using the user agents such as Internet Explorer may not perform correctly when the TEST element is present.
If your tests turn up errors or unexpected behaviour, don't despair. Help is available. The most common causes of errors with a P3P implementation are syntax errors and file placement errors. The P3P Validator Tool will help catch some of these problems and a close review of the INCLUDE and EXCLUDE statements in the Policy Reference File may catch others. Here are some other resources that you may find useful:
- The best place to start is P3P Toolbox, at http://www.p3ptoolbox.org. This Web site contains information and resources on a wide array of P3P topics, including a FAQ section on P3P implementation and email help at firstname.lastname@example.org. If you need detailed assistance, P3P Toolbox can either answer your question or help you find the appropriate person to assist you.
- The P3P area of the W3C has some other developer resources including the history of email discussion lists managed by the W3C at If you are stuck with a problem and do not see the answer in the email discussion history, you may consider joining the list and submitting your question to the listserve. Members include various experts on P3P who may be able to help.
- Microsoft has a comprehensive section on part of its Microsoft Developers' Network Web site dedicate to privacy and P3P in its Internet Explorer browser at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpriv/html/ie6privacyfeature.asp.
- For more information on the AT&T WorldNet Privacy Tool visit http://privacy.att.net.
Once you've deployed P3P policies that cover your organization's entire Web site, you deserve hearty "congratulations" but the job of the P3P team is not done. It is important to keep some resources available for ongoing maintenance and tracking of the data practices of the organization and the P3P policies on the web site. Below are some ongoing issues that you should be aware of.
Ongoing Testing.After initial testing and deployment of your P3P policies, it is a good idea to create an ongoing test plan. Whether manually or automatically, you should make sure as time goes by that the P3P policy files remain accessible and valid.
P3P Policies Change
There will be instances where changes need to be made to P3P files, such as when:
- Adding new pages, cookies or other features to your Web site. Web sites are evolve and grow. As new pages and features are added to your Web site, they should either be assigned to an existing P3P Policy by updating the INCLUDE/EXCLUDE statements in the Policy Reference File or, if the existing P3P Policies do not accurately reflect the data practices associated with the new page or feature, then a new P3P policy should be created.
- Changing data practices in your organization. For example, if your organization announces a new method for users to opt-out of information sharing, you may want to update your P3P policies to reflect that the new option is available. In addition, periodically the P3P team should review the ways that the organization is using user data collected on the Web site to ensure that the organization is continuing to abide by the data practices disclosed. If, for example, the your marketing department is planning a new type of direct marketing campaign, it may be necessary to update the privacy policies in order to collect information that can be used for that purpose.
The EXPIRY Element
The EXPIRY element of a policy or policy reference file indicates a period of time during which a user agent can safely assume that the policy or policy reference file has not changed. Thus, if a user agent fetches a policy with an expiry of 1day (the default), the user agent need not refetch the policy if the user returns to the site later that day. Things can get a little tricky when a site decides to change its policy. For sites that use the default 1 day expiry period, there will usually be a 1-day overlap period where some user agents will think that the old policy is in effect and others will think the new policy is in effect. Sites should be cautious about how they use data collected during that overlap period to make sure it is consistent with either policy. If having an overlap period is not acceptable, a site can change the expiry time on their old policy to the absolute time when the new policy goes into effect. At that time the site can begin serving the new policy.
Track Your P3P Policy History
For legal and management reasons, it is important to keep track of which privacy polices were in effect at any point in time. Therefore, you should have a system for tracking when P3P policies are changed, what was changed and who made the change. This can be done in many different ways. Make sure that your P3P team takes the time to select a method and implement it.
By implementing P3P, your organization is playing a part in the evolution of Web-based communication. P3P is part of a tidal change improving the dialogue between Web sites and consumers. This new tide is empowering consumers to take more responsibility for their online experience and their data privacy. As illustrated in consumer privacy studies such as the Harris (May 2001) and Pew (August 2000), consumers want to take responsibility for how their personal information flows through the information economy. In the Pew study, for example, while consumers preferred government solutions over industry self-regulation, they preferred consumer-based solutions over government intervention by a ratio of 4 to 1 (75% to 19%). P3P is not a complete solution to concerns about data privacy, but is an important and potentially powerful tool.
We hope that this Guide has proved helpful to you and your P3P implementation team. The P3PToolbox Web site is the main source for updates to this Guide and a good source for additional information about the P3P implementation process.
The Appendix includes the following P3P-related reference materials:
A - Base Data Schema
B - Discussion of Microsoft Specific Rules for Compact Policies
C - Explanation of Linkage for Unique Domain-level Cookies
Section 3 | Table of Contents | Appendix