Appendices

Table of Contents
A.Base Data Schema
B.Cookies in Microsoft Internet Explorer 6.0
C.Basic Cookie Operations

Appendix A: Base Data Schema

The formal XML definition of the P3P base data schema is given in Appendix 3 of the P3P Specification. In the following sections, taken directly from the P3P Specification as of January 16, 2002, the base data elements and sets are explained one by one.

5.6.1 User Data

The user data set includes general information about the user.

Note, that this data set includes elements that are actually sets of data themselves. These sets are defined in the Data Structures subsection of this document. The short display name for an individual element contained within a data set is defined as the concatenation of the short display names that have been defined for the set and the element, separated by a separator appropriate for the language/script in question, e.g. a comma for English. For example, the short display name for user.home-info.postal.postalcode could be "User's Home Contact Information, Postal Address Information, Postal code". User agent implementations may prefer to develop their own short display names rather than using the concatenated names when displaying information for the user.

5.6.2 Third Party Data

The thirdparty data set allows users and businesses to provide values for a related third party. This can be useful whenever third party information needs to be exchanged, for example when ordering a present online that should be sent to another person, or when providing information about one's spouse or business partner. Such information could be stored in a user repository alongside the user data set. User agents may offer to store multiple such thirdparty data sets and allow users to select the appropriate values from a list when necessary.

The thirdparty data set is identical with the user data set. See section 5.6.1 User Data for details.

5.6.3 Business Data

The business data set features a subset of user data relevant for organizations. In P3P1.0, this data set is primarily used for declaring the policy entity, though it should also be applicable to business-to-business interactions.

5.6.4 Dynamic Data

In some cases, there is a need to specify data elements that do not have fixed values that a user might type in or store in a repository. In the P3P base data schema, all such elements are grouped under the dynamic data set. Sites may refer to the types of data they collect using the dynamic data set only, rather than enumerating all of the specific data elements.

These elements are often implicit in navigation or Web interactions. They should be used with categories to describe the type of information collected through these methods. A brief description of each element follows.

clickstream

The clickstream element is expected to apply to practically all Web sites. It represents the combination of information typically found in Web server access logs: the IP address or hostname of the user's computer, the URI of the resource requested, the time the request was made, the HTTP method used in the request, the size of the response, and the HTTP status code in the response. Web sites that collect standard server access logs as well as sites which do URI path analysis can use this data element to describe how that data will be used. Web sites that collect only some of the data elements listed for the clickstream element MAY choose to list those specific elements rather than the entire dynamic.clickstream element. This allows sites with more limited data-collection practices to accurately present those practices to their visitors.

http

The http element contains additional information contained in the HTTP protocol. See the definition of the httpinfo structure for descriptions of specific elements. Sites MAY use the dynamic.http field as a shorthand to cover all the elements in the httpinfo structure if they wish, or they MAY reference the specific elements in the httpinfo structure.

clientevents

The clientevents element represents data about how the user interacts with their Web browser while interacting with a resource. For example, an application may wish to collect information about whether the user moved their mouse over a certain image on a page, or whether the user ever brought up the help window in a Java applet. This kind of information is represented by the dynamic.clientevents data element. Much of this interaction record is represented by the events and data defined by the Document Object Model (DOM) Level 2 Events [DOM2-Events]. The clientevents data element also covers any other data regarding the user's interaction with their browser while the browser is displaying a resource. The exception is events which are covered by other elements in the base data schema. For example, requesting a page by clicking on a link is part of the user's interaction with their browser while viewing a page, but merely collecting the URL the user has clicked on does not require declaring this data element; clickstream covers that event. However, the DOM event DOMFocusIn (representing the user moving their mouse over an object on a page) is not covered by any other existing element, so if a site is collecting the occurrence of this event, then it needs to state that it collects the dynamic.clientevents element. Items covered by this data element are typically collected by client-side scripting languages, such as JavaScript, or by client-side applets, such as ActiveX or Java applets. Note that while the previous discussion has been in terms of a user viewing a resource, this data element also applies to Web applications which do not display resources visually - for example, audio-based Web browsers.

cookies

The cookies element should be used whenever HTTP cookies are set or retrieved by a site. Please note that cookies is a variable data element and requires the explicit declaration of usage categories in a policy.

miscdata

The miscdata element references information collected by the service that the service does not reference using a specific data element. Categories have to be used to better describe these data: sites MUST reference a separate miscdata element in their policies for each category of miscellaneous data they collect.

searchtext

The searchtext element references a specific type of solicitation used for searching and indexing sites. For example, if the only fields on a search engine page are search fields, the site only needs to disclose that data element.

interactionrecord

The interactionrecord element should be used if the server is keeping track of the interaction it has with the user (i.e. information other than clickstream data, for example account transactions, etc).

Appendix B: Discussion of Microsoft-specific Rules for Compact Policies

Microsoft has incorporated an implementation of P3P in its newest Web browser, Internet Explorer 6.0. At its most basic level, Internet Explorer 6.0 enables users to manage their privacy by giving them control over cookies based on the stated purpose of the cookie. This enables users to determine what Web sites they share information with and how those sites use that information.

Internet Explorer 6.0 does this by comparing the cookie´s machine-readable compact policy, with the user´s privacy settings. If the settings do not match or the cookie does not have a compact policy the cookie is either blocked or restricted.

As with each user agent that is developed to work with P3P, Internet Explorer has its own set of rules for how to interact with P3P on the user´s behalf. Internet Explorer 6.0´s privacy controls are presented to users on a sliding scale of six settings in the Internet Options menu. The highest setting, Block All Cookies, denies all Web site requests for information using cookies regardless of privacy policy. The lowest setting, Accept All Cookies, allows Web sites to gather any information requested from the user using cookies. Microsoft also provides four intermediate settings, High, Medium High, Medium, and Low, which block or reduce the functionality and information uses of cookies based on a cookie´s P3P privacy policy.

Microsoft has set the Medium privacy level as the default when Internet Explorer is distributed. At this default setting, Microsoft has drawn a line to distinguish between satisfactory and unsatisfactory cookies. An unsatisfactory cookie contains or allows access to personally identifiable information that is used for unstated purposes or provided to recipients without user consent. (the Unsatisfactory Cookie Rule) This means that Internet Explorer 6.0 checks whether a compact policy´s purposes (e.g. IVD and OTP) and recipients (e.g. OTR) include opt-out or opt-in options for users (e.g. IVDo, OTPi, and OTRo).

The following chart summarizes the impact of IE 6 on cookies under the default user setting of Medium privacy.

In those cases that a cookie does not match the user´s privacy settings, the user will be notified by the privacy icon, which is an eyeball and a European do not enter sign icon in the browser´s bottom left icon tray. By clicking on this icon, users will be able to see what cookies were blocked, whether their sites have P3P privacy statements and, if so, what these statements are.

The Privacy Report
When the privacy icon appears, users will be able to click on it to view a Privacy Report, which displays all of the graphics, charts and other date being sent by the Web site that the user is visiting and any third parties sending content from that Web site onto user´s computer. Depending on the user´s settings, the Privacy Report will display all Web sites setting information on the user´s computer or just the cookies or information that is being restricted because of the absence of a P3P compact policy or because the policy does not meet the user´s privacy settings. The user can than click on any cookie or other information being displayed in the report. If the site has a P3P policy, the user will be able to view a human-readable P3P privacy summary that uses a common language and set of references for users to understand the privacy policies of the sites they visit. These summaries represent the human-readable summary of the machine-readable XML P3P policies. If the Web site does not have a P3P policy, the user will be directed to visit the site directly to read the Web site´s human readable privacy policy.

For a more detailed description of the Microsoft implementation of P3P, see Microsoft´s Internet Explorer developers´ Web site at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpriv/html/ie6privacyfeature.asp

Appendix C. Basic Cookie Operations

What happens when P3P compliant site http://www.example.com sets a unique domain level cookie?

The Facts:

1. www.example.com is P3P compliant and operated under the entity Example, Inc.
2. www.example.com sets/logs a persistent cookie, GUID=abc123 scoped to the *.example.com domain.
3. www.example.com will only use the cookie to analyze pseudonymous user visits on the www.example.com site.
4. www.example.com logs <PREFERENCE> data that a user may find sensitive in combination with <PHYSICAL> <ONLINE> or <GOVERNMENT>
5. www.example.com DOES NOT link <PHYSICAL> <ONLINE> or <GOVERNMENT> categories
6. www.example.com is not aware of:
   • if all servers on the domain are p3p compliant
   • the extent to which all servers on the domain are controlled by the example.com organization (the entity declared by www´s policy)
   • other unique cookies that may be logged in conjunction with the GUID cookie or what those cookies link to
   • if that cookie is ever logged with authentication tying the cookie to offline data

7. ad.example.com is P3P compliant and operated under the entity Example, Inc.
8. ad.example.com sets/logs a persistent cookie, LUID=cde456 scoped to the host level but in logging cookies inadvertently logs ALL cookies scoped to server including GUID set by www
9. ad.example.com links the LUID cookie to a relational database storing information about the advertisers a cookie has seen, the sites a cookie has visited, the ads the cookie has clicked on, etc
10. intra.example.com is not P3P compliant but is completely run and operated by entity Example, Inc.
11. intra.example.com sets/logs a persistent cookie, lang=eng, scoped to the host but inadvertently logs all cookies scoped to the server including GUID set by www
12. intra.example.com requires user authentication. The authentication is logged in a 1:1 relationship with the GUID cookie. The authentication also maps directly to a human resources database storing all information a company has on the authenticated user and therefore the formerly anonymous cookie.
13. Mail.example.com is operated on behalf of Example, Inc. by ThirdPartyCo. ThirdPartyCo has some rights to log files on servers that it runs.
14. Mail.example.com has no access to what is linked to the GUID cookie on sites under the control of entity Example, Inc.
15. Mail.example.com is not concerned with what it logs in conjunction with the cookie. It may log refer, authentication, or name/values in GET method forms