22 November 1998
Lorrie Faith Cranor
Position paper to be presented at QL'98 W3C Query Languages Workshop, Dec. 3-4, 1998. This paper liberally borrows material from the 9 October 1998 APPEL working draft as well as a recent W3C note describing P3P. It reflects the opinions of the author as well as the other members of the P3P Preferences Working Group.
The goal of the Platform for Privacy Preferences (P3P) project is to enable users to exercise preferences over web sites' privacy practices. P3P applications will allow users to be informed about web site practices, delegate decisions to their computer agent when they wish, and tailor relationships with specific sites. The P3P1.0 working draft [P3P10] specifies the protocol for exchanging P3P information between web sites and user agents, and a vocabulary for sites to use to describe their privacy practices. However it places very few requirements on user agent implementations and makes no recommendations about languages for encoding user privacy preferences. The P3P Preferences Working Group has developed a separate working draft that specifies A P3P Preference Exchange Language (APPEL) [APPEL] that can be used to encode and exchange user privacy preferences in the form of rules. APPEL was designed as a special-purpose language for this application; however, more general XML or RDF query languages might also be suitable for this purpose.
This paper is intended to inform the larger query language community about P3P's query language requirements. It presents APPEL as one solution that satisfies P3P's needs. We hope that it will provoke discussion as to whether these needs can be satisfied by a more general query language.
P3P is designed to help users reach agreements with services (web sites and applications that declare privacy practices and make data requests). As the first step towards reaching an agreement, a service sends a machine-readable proposal in which the organization responsible for the service declares its identity and privacy practices. A proposal applies to a specific realm, identified by a URI or set of URIs. The privacy proposal enumerates the data elements that the service proposes to collect and explains how each will be used, with whom data may be shared, and whether data will be used in an identifiable manner. Proposals can be parse automatically by user agents -- such as web browsers, browser plug-ins, or proxy servers -- and compared with privacy preferences set by the user. If a proposal matches the user's preferences, the user agent may accept it automatically by returning a fingerprint of the proposal, called the propID. If the proposal and preferences are inconsistent, the agent may prompt the user, reject the proposal, send the service an alternative proposal, or ask the service to send another proposal.
A basic P3P interaction might proceed as follows:
The proposal may include requests for specific data elements from the user. If these elements are already stored in the user's data repository, and if the request is consistent with the user's ruleset, the agent may send these elements to the service. If these elements are not in the repository, the agent may prompt the user to type in this information.
The following is an example of a P3P proposal:
| P3P Proposal Example |
|---|
English language version:CoolCatalog, makes the following statement for the web pages at http://www.CoolCatalog.com/catalogue/. We collect clickstream data in our HTTP logs. We also collect your first name, age, and gender to customize our catalog pages for the type of clothing you are likely to be interested in and for our own research and product development. We do not use this information in a personally-identifiable way. We do not redistribute any of this information outside of our organization. We do not provide access capabilities to information we may have from you, but we do have retention and opt-out policies that you can read about at our privacy page http://CoolCatalog.com/PrivacyPractice.html. The third party PrivacySeal.org provides assurance that we abide by this agreement. Abridged P3P syntax version:<PROP realm="http://CoolCatalog.com/catalogue/" entity="CoolCatalog" propID="94df1293a3e519bb"> <USES> <STATEMENT purpose="1" recipient="0" id="0"> <REF name="Web.Abstract.ClientClickStream"/> </STATEMENT></USES> <USES> <STATEMENT purpose="2,3" recipient="0" id="0" consequence="a site with clothes you'd appreciate."> <WITH><PREFIX name="User."> <REF name="Name.First"/> <REF name="Bdate.Year" OPTIONAL="1"/> <REF name="Gender"/> </PREFIX></WITH> </STATEMENT></USES> <DISCLOSURE discURI="http://CoolCatalog.com/PrivPractice.html" access="3" other="0,1"/> <ASSURANCE org="http://PrivacySeal.org" text="third party" image="http://PrivacySeal.org/Logo.gif"/> </PROP> |
For the purpose of understanding this paper it is not necessary to understand the entire P3P proposal syntax. The important things to observe are:
For a detailed overview of P3P see [P3PNote] or refer to the latest draft of the P3P1.0 specification [P3P10].
The APPEL working draft [APPEL] specifies a language for describing collections of preferences regarding P3P proposals. Using this language, users can express their preferences in a set of rules (called a ruleset), which can then be used by user agents to make automated or semi-automated decisions regarding the exchange of data with P3P enabled web sites. Much of the underlying logic is based on PICSRules [PICSRules].
APPEL was developed with several goals in mind that are not met by the P3P1.0 specification alone:
Primarily, we envision this language will be used to allow users to import preference rulesets created by other parties and to transport their own rulesets files between multiple user agents. Implementors might also choose to use this language (or some easily-derived variation) to encode user preferences for use by the rule evaluators that serve as the decision-making components of their user agents.
While we do not expect users to be exposed to the expression of the rules themselves, tools that allow them to test their rules may be useful. For instance, a user could make a query, "under what conditions do I give out identifiable information?"
The 9 October 1998 APPEL working draft [APPEL] is based on the following requirements:
In defining the scope of the APPEL language, the working group generated a large list of possible requirements. The group then narrowed the scope to eliminate those requirements that were deemed less important or easier to implement if handled elsewhere. Thus, the working group limited the scope of APPEL as follows:
In order to facilitate prototype implementations of APPEL the working group decided to split up the current draft into a Level 1 specification designed to express only basic privacy preferences and a more detailed Level 2 specification that implements the rest of the requirements outlined above. Specifically, APPEL Level 1 limits the requirements to:
Note that the only known APPEL implementation to date -- IBM P3P Parser (based on a previous working draft) -- includes most features of both APPEL levels.
This section gives a general overview of the APPEL language. For a full specification, please refer to the latest APPEL working draft [APPEL].
APPEL is an ordered rules language, similar in design to PICSRules. Like PICSRules [PICSRules], APPEL rules are designed to be processed one at a time until a rule fires. Once a rule fires, no further rule processing is required. While PICSRules restrict pattern matching to the values of simple attribute-value pairs, APPEL allows pattern matching over structured data in the form of XML (or RDF) expressions. In fact the APPEL syntax looks very similar to the P3P proposal syntax. Any part of a P3P proposal that must be present for a rule to fire must appear in the body of that rule.
An APPEL rule evaluator is activated by a P3P application. The activating application provides the evaluator with various pieces of "evidence" and a rule set for processing them. Evidence includes the URI of the service and a single P3P proposal from the service if present. Rules are evaluated with respect to the evidence provided. A rule evaluates to true if an expression is satisfied. Basically, a rule is satisfied if any of the available evidence satisfies it.
The scope of the rule is determined by the opening and closing elements of an APPEL RULE element. The evaluator returns the behavior (as specified in its behavior attribute -- accept, prompt, reject, or another behavior specified in an extension) of the rule that fired on the basis of the evidence discussed above. In addition, the rule evaluator may optionally return other information such as an explanation string (suitable for user display).
A rule includes a behavior, an optional persona (if the user agent supports multiple user repositories, this string identifies the data repository that should be used), an optional explanation and a set of expressions. A rule with an empty set of expressions always evaluates to false. A rule containing only the degenerate expression always evaluates to true. Multiple expressions within a rule are implicitly ANDed together; thus, all must hold true for the rule to evaluate to true. Individual expressions are each composed of simple-expressions and data-reference-expressions. Simple-expressions and data-reference-expressions within an expression are implicitly ANDed together as well.
Simple-expressions are used to match generic elements and their attribute values within a proposal, for example '<STATEMENT purpose="3">'. They support only the = operator and may take string or numeric values. A data-reference expression on the other hand is a special kind of expression that is tailored to matching data references within a P3P proposal. Since the data reference elements of a P3P proposal determine which data fields are requested (and, upon acceptance of the proposal are ultimately supplied to the service), some special semantics were put into APPEL in order to prevent unintentional release of personal data.
APPEL supports the concept of quantifiers that govern the strictness of the required match between data reference expressions in the rule and the corresponding elements in the proposal. For example, rules that result in an accept behavior always use the semantics of the ONLY quantifier when matching data-reference-expressions: match if only the data reference elements that are listed in the rule are requested in the proposal. In contrast, rules that result in a non-"accept" behavior (e.g. reject and prompt) will default to using the semantics of the ANY quantifier: match if any of the data reference elements that are given in the rule are requested in the proposal.
APPEL supports a single wildcard metacharacter. Simple-expressions and data-reference-expressions can use this wildcard to match ranges of values such as <REF name="User.*"> (any element from the "User" data set). Wildcards can also be used to indicate that a particular attribute must be present, but that it may take any value.
The following is an example of a simple APPEL ruleset. Although the example is a well formed APPEL ruleset, it is used only to demonstrate a small set of example rules and is not necessarily a realistic example. This example ruleset represents the following natural language preferences:
The following listing illustrates one way to encode these preferences into an APPEL ruleset using two APPEL rules. An accept-rule (i.e., a rule with the string "accept" in its behavior attribute) first checks to see if only non-identifiable clickstream data and/or a PUID is collected, and accepts if disclosure information is available (lines 4-14). Otherwise, a "reject"-rule encapsulating the degenerate expression "OTHERWISE" will fire, rejecting proposals that contain requests for data transfer (lines 18-20).
| Simple Ruleset in APPEL Level 1 |
|---|
| 000: <APPEL:APPEL xmlns="http://www.w3.org/APPEL"
Order="RDF:Seq"> 001: <APPEL:RULESET crtdby="APPEL WG" crtdon="Wed, 12-Aug-1998 09:12:32 GMT"> 002: <RDF:SEQ> <!-- This might be simplified by later versions of RDF --> 003: <RDF:LI> 004: <APPEL:RULE behavior="accept" 005: description="Service only collects clickstream data"> 006: <P3P:USES> 007: <P3P:STATEMENT action="r" id="0"> 008: <P3P:REF name="ID.PUID"/> 009: <P3P:REF name="ClickStream.Client_"/> 010: </P3P:STATEMENT> 011: </P3P:USES> 012: <P3P:DISCLOSURE discURI="*"/> 013: </P3P:PROP> 014: </APPEL:RULE> 015: </RDF:LI> 016: <RDF:LI> 017: <APPEL:RULE behavior="reject" 018: description="I don't want to be identified!"> 019: <APPEL:OTHERWISE/> 020: </APPEL:RULE> 021: </RDF:LI> 022: </RDF:SEQ> 023: </APPEL:RULESET> 024: </APPEL:APPEL> |
Note that the line numbers are not part of the APPEL syntax. Lines 6-11 in the ruleset example contain a statement in the same syntax as it would appear in a P3P proposal. Line 12 contains a P3P disclosure element with a wild card value for the given attribute, indicating that the attribute must be present.
The P3P Preferences working group has specified a language that meets our stated goals and requirements. There has been some debate as to the degree of difficulty involved in implementing APPEL. However we generally believe that APPEL Level 1 should not pose any major obstacles for implementors, and IBM's early APPEL implementation suggests that even APPEL Level 2 should be fairly straightforward to implement. On the other hand, since APPEL is a special-purpose language it requires the implementation of a parser and trust engine that otherwise would not be included in future browsers. If a suitable XML or RDF query language were available and widely implemented, our objectives might be met without the need for additional implementation work. Furthermore, a general-purpose language would likely provide more flexibility in the kinds of rules that could be created and provide better support for integrating P3P rules with other types of rules that users may wish to establish.
While several of the proposed general-purpose languages look promising as APPEL alternatives, it is important to note that P3P is quite different from many of the other applications the designers of these languages seem to be envisioning. A P3P query language requires some of the features of an advanced authorization language in addition to some of the features of a query language. In our application we are more concerned about the existence of data that matches a certain pattern than in retrieving, aggregating, or otherwise operating on that data. Although this makes our task simpler in some ways, it may require some awkward syntax to achieve using a general-purpose language. This might possibly be addressed by the use of macros designed specifically for P3P-related tasks.
Because P3P is intended to help users protect their privacy and retain control over their personal information, the working group tried to design APPEL with syntactic and semantic safeguards against unintentional release of personal data. For example, APPEL rules that accept proposals (and may agree to the release of data) must use the ONLY quantifier, which requires them to fire only if the data referenced in a proposal is restricted to the list of data elements or categories enumerated in the rule. Rules that reject proposals, on the other hand, default to using the ANY quantifier, which requires them to fire if any of the data referenced in the proposal is on the list of data elements or categories enumerated in the rule (although rules may created that override this default). While a general purpose language supported by a good user interface or editing tool might provide similar kinds of safeguards, building these features into the language offers a higher level of security than is likely to be achieved using a general purpose language.
While one of the primary goals of APPEL is to allow people to install pre-defined rulesets, it is also important that people be able to customize their rulesets to better meet their needs. Designing a user interface that allows users to customize an existing APPEL ruleset remains an open problem. Certainly a simple rule editor could allow people to edit individual rules or add or subtract rules from their ruleset. However, it would be desirable to have a user interface that could present users with an overall picture of the conditions under which proposals will be accepted or rejected, allowing them to make conceptual changes that might translate into multiple specific changes to their ruleset.
Thanks to the other members of the P3P Preferences Working Group: Marc Langheinrich, Massimo Marchiori, Joseph Reagle, Drummond Reed, and Mary Ellen Zurko. The ideas expressed in this paper are the results of many discussions of this working group.