Dulles, Virginia

Author: Brian J. Zwit (mailto: bzwit@aol.com)

Director, Integrity Assurance

America Online, Inc.

America Online, Inc. (AOL) is the world’s largest Internet Service Provider (ISP) with over 35 million customers. In a typical day, AOL delivers 400 million e-mails; serves 250 million stock quotes, handles 1.2 billion Instant Messages™, and responds to 12 billion http requests. AOL also provides member-only content within the AOL service and public content on the Internet at its web site, AOL.com. In addition, AOL also has relationships with other web sites to share content. Some of these sites are own by AOL and some are entirely independent sites.

AOL has been evaluating the P3P specifications applicability and use on its network. AOL supports the work of the P3P Working Group and believes that the P3P Recommendation is a good start in meeting the needs of a range of stakeholders. Just like most specifications, however, experience teaches us many lessons about how to implement a specification and where a specification needs improvement.

Ultimately, the most important issue for P3P is its acceptance by developers, web sites, regulators, business, and the public. This is essential for the specification to have any chance of widespread implementation and usefulness. Industry, regulators, and the public need the specification to be (1) flexible but detailed enough to permit a site to accurately represent it’s privacy practices; (2) easy for a site to implement; (3) understandable to the general public; and (4) consistently implemented in users agents, e.g., browsers. The areas for future work outlined below are intended to improve the P3P specification to foster all of these goals.

1. Involvement of a Broad Range of Stakeholders

User agent developers, web site owners, regulators, the public, and others must first accept the P3P specification as the basis for expressing the privacy practices of web sites. While the P3P Working Group solicited comments from numerous stakeholders in drafting the first version of the specification and gave them all due consideration, a large number of stakeholders continue to have significant issues and important input to provide the P3P Working Group. This is clear from discussions about P3P among users of the specification, including private and public sector entities and the public, and from the experience of many sites that have been evaluating and implementing the specification.

The drafting of a standard for expressing privacy practices is a very complicated task in comparison to more technical standards. A much larger group of stakeholders, many without any technical expertise or desire to even discuss the technical aspects of the specification, have interests in the P3P specification and should be included in determining what the next steps are for P3P. This group should include a significant number of public policy experts, including industry, regulators, and public interest groups, and the public.

Because of the need for a manageable group of writers, including more stakeholders in this process can be accomplished in other ways than expanding the P3P Working Group, although that is also required. At a minimum a survey of entities working to implement the P3P specification in users agents and on web sites should be conducted to identify common problems and issues that can be addressed in future work. While not every issue can be addressed in the specification, a survey will help identify those issues that are common and not currently covered by the specification or covered in an unsatisfactory way. Also, public meetings with input from a large group of stakeholders should be convened to gather input into the process. These public meetings can be handled like public meetings held by government agencies, allowing written and verbal comments.

2. Flexibility and Precision of the P3P Specification

To be useful, the P3P specification must allow a web site to express its privacy practices with both flexibility and precision. The twin goals of flexibility and precision seem to be at odds. However, this is simply not true. The more flexibility built into a specification, the more precise a broad range of privacy practices can be described using the vocabulary the specification. Privacy practices are simply not standard across the Internet and flexibility is required to allow for different privacy practices to be expressed with precision.

Flexibility is required to allow sites to express their privacy practices with all their nuances. Precision is required to allow site visitors to make informed decisions about their data. In addition, the regulators need precision to enforce consumer protection laws and regulations. Given the current definitions of elements and restrictions in the specification, sites cannot accurately represent many of their privacy practices in the vocabulary of P3P. The P3P elements, in many cases, simply are not descriptive of many privacy practices.

The provision for an “other” element, while helpful, does not solve the problem. While a site can use the “other” element to describe a purpose or category of data not covered by one of the standard elements, the use of the other element must be keep to a minimum. Otherwise, a P3P policy could consist of nothing but other elements defeating the purpose of standardizing the language used to describe privacy policies, i.e., making privacy policies comparable across different sites, and enabling automatic analysis and decision-making by a user agent difficult if not impossible.

An example of a requirement in the specification that requires more flexibility and, at the same time, more precision is the use of the ”required” attribute, i.e., opt-in, opt-out, and always, where a piece of data stored within the cookie must be shared with other sites to enable basic functionality. This is very common with authentication services and sites that share content. The storage and use of the data is not opt-in as it is required for basic functionality and the use of the service does not appear to be an affirmative opt-in as required by the specification. It is also not opt-out as there is no mechanism to opt-out after signing up for the service because the data and sharing of the data is required to provide the functionality of the service. Finally, it is not “always” as the definition of always appears to include an assumption that the service could, but has chosen otherwise, to not require the data and sharing of the data.

Many sites have implement P3P or a portion of the specification. The experiences of these sites so far would be very instructive on the precise elements and restrictions that need to be evaluated and, potentially, changed to improve the specification. Those same experiences would also be helpful in uncovering other areas of the specification that have significant and unintended consequences.

3. Compact Policies for Cookies

Compact policies are problematic for a variety of reasons and their use and the elements surrounding them should be evaluated in light of current experiences. While essentially proposed as a performance enhancement feature, compact policies because of the ease with which they can be evaluated have become a “default” implementation of P3P. Furthermore, many sites have adopted very broad compact policies that include the “kitchen sink,” providing no useful information to a visitor about the site’s privacy practices.

First, it is difficult to determine from the specification what privacy practices need to be revealed in a compact policy. The specification requires a compact policy to reflect the data stored in the cookie as well as “to data linked to the cookies.” How strong does the link need to be to require a site to describe a privacy practice? For instance, a cookie that stores a unique identifier for an individual, such as an online identity, will by necessity be linked in the case of an ISP to the name, address, credit card data, and usage data, e.g., time logged onto the service and IP address assigned that session, of the person owning that online identity.

Second, as noted above for P3P policies, drafting a compact policy for a cookie is difficult because the specification is not adequate to describe the privacy practices associated with the cookie to any precision.

Third, compact policies are proving extremely difficult to implement and maintain and the resources required to implement and maintain compact polices is hard to justify when the value of compact policies is questionable. A majority of cookies are not used to collect data but to enable functionality. The vast majority of data is collected using other methods and a compact policy provides a user no information about data collected by those other mechanisms.

Fourth, the use of compact policies takes resources away from what the real focus of P3P should be—giving the user a complete picture of the privacy practices of a web site.

4. Implementation of P3P in User Agents

The P3P specification assumes that developers will write user agents that implement P3P in a way that provides the information available on the site in the P3P policy as well as any compact policies but does not interfere with the functionality of the site. If both can not be guaranteed, users will chose functionality over information, defeating the whole purpose of the specification. In addition, if the information presented to users is not in plain language with no “tech” talk (as with error messages today), users will ignore the information and either click through the information or turn off the feature. Moreover, the key to widespread acceptance is a standard implementation in user agents so sites only need to code their sites for one basic implementation.

The challenges of implementing P3P in a user agent are numerous and present difficult decisions of policy. The P3P Working Group put aside issues of implementation in users agents because of the amount of work required just to draft the specification and because implementation of W3C specifications have typically been left to developers. This specification is different—it is not just a technical standard but is also just as much a policy standard.

As part of a next version, the P3P Working Group should review the decision about not setting any standards for implementation and look at providing some guidelines for doing so. If the P3P Working Group decides that this is not a task that they wish to undertake, then they should make a recommendation that a separate group be formed to do so.

5. Network Operations

The P3P specification could have a tremendous negative impact on network operations and the servers on those networks.

First, a HTTP 1.1 connection can never be guaranteed in requesting the P3P policies and, as a consequence, every time a user requests a page, the browser will request two P3P objects, the policy reference file and the P3P policy, directly from the origin server. The impact on the network operations will be a significant increase in latency and use of resources. The impact will be magnified where the requested page contains content from other domains.

Second, network resources, servers and bandwidth, will be taxed by the multitude of requests and the mechanisms for requesting P3P policies outlined in the specification. Many sites have multiple servers at different domains providing advertisements or partners that share content or facilitate commerce transactions. For each http request to a different domain, the browser must request a minimum of two other files, the P3P reference file and, after analyzing the reference file, the P3P policy. This multiplying effect on a busy network will consume a significant amount of network and computer resources and add significant latency to the browsing process.