The first part of this article talked about online privacy from a general standpoint. In this part I'll concentrate on the particular tack taken by the P3P working group.
Computers Are Lousy Policy Makers
Attempts to make or carry out policy through technology usually come to grief. This was enunciated as far back as 1976 in Joseph Weizenbaum's classic book Computer Power and Human Reason, and it's part of the mission statement of Computer Professionals for Social Responsibility. Nevertheless, large commercial sites latched on to P3P as backing for their argument that technology could protect privacy and that governments need not act.
The P3P team, if you read its work carefully, rejects such sunny assumptions. A widely-publicized 1998 introduction to P3P says:
P3P is not a silver bullet; it is complemented by other technologies as well as regulatory and self-regulatory approaches to privacy.
and from the specification itself comes this exclusion:
...[P3P] does not provide a technical mechanism for making sure sites act according to their policies...P3P is complementary to laws and self-regulatory programs that can provide enforcement mechanisms.
However, the energy driving P3P from outside the W3C came from those companies that hoped to continue evading such "enforcement mechanisms." As Internet users wise up, the appeal of P3P for these companies will wane.
Formal Systems Are Too Rigid to Encompass Real Life
One reason the P3P specification is taking so long is that it's just trying to be too many things to too many people. This is the likely fate of any such "social protocol," as P3P was termed in a paper by Reagle and Cranor.
Everybody has had the experience of making a reservation or filing a complaint or dealing in some other fashion with a computer that couldn't stretch to cover the reality of the situation. Studies of the adoption of computing technology repeatedly turn up problems with organizations that try to formalize work processes (especially if computer designers believe the managers' descriptions of those processes). So how could the P3P working group believe it could handle the infinite flexibility of trust relationships between commercial organizations and their clients?
The P3P vocabulary defines all the values of all the fields the protocol should offer. Let's take a look for the purpose of illustration at one element, the RECIPIENT. This indicates who will be given access to user data. The most restrictive value P3P gives is "Ourselves and/or our agents." People who have followed the recent debate over a financial services law in the U.S. know that this value is already too broad. One of the main reasons financial institutions want to merge is so one division can get access to customer data in another division. Data can then travel from a mutual funds administrator to a bank to a life insurance company without ever leaving "Ourselves and/or our agents."
Some users are willing to share their data with outside organizations, but in ways that no formal protocol can determine. You may not mind if your liquor-purchasing habits are shared with a liquor company, because you might want to get a catalog from a small company you've never heard of. But you would indeed mind if the same data is shared with the lawyer for your opponent during a lawsuit when he's trying to prove you're reckless and negligent. (My example is inspired, of course, by a real-life court case.)
Similarly, in a system useful for real-life situations, it would be nice to specify a time limit (such as two months) or trigger event (such as "when I close my account with you") after which data has to be discarded. But the P3P working group can't find a way to formalize such a multi-valued requirement.
P3P is fine tuned for sending client data to an e-commerce site that can use it for further marketing: the specification even includes such fields as job title and mobile phone number. By contrast, it has no provision for the server to send data about the Web site's owner to the client. Before trusting a Web site with data, a client might well want to know whether it is run by a for-profit or nonprofit organization, and whether some company is funding a nonprofit site. You won't find any data like that through P3P. (Thanks to CPSR member Karen Coyle, author of a Privacy and P3P FAQfor this point.)
Automation Reduces End-User Control and Increases the Potential for Abuse
Originally, P3P was expected to come with a related protocol that transferred data after the two parties agreed on how it would be used. You would click on a browser box saying, "Send my address," and the browser would send the server your address, which you would have previously loaded into a convenient location to be found by the browser. It is assumed that the server already negotiated an agreement concerning whether the address was not to be shared with other organizations, or whatever other restrictions you called for. As we have seen already in this article, violating the agreement is easier than obeying it.
Privacy advocates saw plenty of dangers in the automation of data transfer. First, it's hard for users to tell just what they're agreeing to-a dialog box might say something vague like "Send the data required to complete the purchase," and the user might have no idea that data about his bank account (to pick an example) might be sent.
Furthermore, automation would require users to enter lots of personal data and store it in a location chosen by the developers of their browser. Security experts know that the greatest gift developers can hand to intruders is to provide a single location where sensitive data can be found on a large number of computers. Scant time would pass before newsgroups would be circulating scripts that penetrated moderately insecure systems and retrieved a Social Security number from Navigator or IE.
It was thus something of a relief when the P3P working group announced that it was removing data transfer from P3P. They were driven less by the concerns I just mentioned than by reports that commercial sites didn't want the new mechanism; most had developed CGI scripts or other means to collect data and wanted to stick to them.
But it's a situation of damned-if-you-do and damned-if-you-don't. Separating data transfer from the privacy agreement has further weakened the promise of P3P. It will be harder for the client to prove that he or she placed restrictions on the data; the server administrators can say, "You made the agreement about a different set of data." The P3P working group is trying to salvage the strength of the privacy agreement by encouraging all servers to define their forms with the same terms as the P3P vocabulary uses for data. The association, however, will be backed only by a promise.
Complexity Leads to Errors or Disuse
A paper by two members of the P3P team, Ackerman and Cranor, admits that the protocol offers so many variables along so many dimensions that few users are going to take the time to figure it out. We know that most computer users never even change the background on their display; those that do customize their environments usually require an immediate, visible response such as a color change. Entering a dozen values with interacting behaviors whose effects will never be visible is for most users a task comparable to attaining the seventh station of enlightenment.
The particular solution suggested in the paper consists of intelligent agents called "critics" that would run on the user's computer, monitor what he or she is doing, and issue warnings when it notices an activity that puts the user's privacy at risk. Another suggestion from the P3P team is that the protocol might be built into agents that crawl the Web for products of interest to users. Thus, if you ask a search engine to find bicycles matching certain criteria, you might also ask it to exclude sites with inadequate privacy policies.
Aside from such speculative research projects, the most promising use of P3P is what the Reagle and Cranor paper calls "a recommended setting in the form of a 'canned' configuration file." Well-known organizations might provide templates that users can choose from; thus, a very concerned user could install a restrictive template from EPIC while a shop-till-you-drop surfer might install one from the Direct Marketing Association. That still puts the burden on the individual to find and download the template. How will P3P satisfy laws in the European Union, where there are no privacy "preferences," but only a standard that applies to everybody? When people download their browsers, will Netscape and Microsoft ask them what country they live in and set the default policy to respect EU laws?
For many reasons, then, we cannot depend on technological solutions to social problems. In the case of privacy, laws work. They have been shown to work in the past, both in the U.S. and in other countries. Since large companies will have to update their policies, computer applications, and employee training for the European market, following the mid-March agreement between the U.S. and European Union, this is a good time to promote protections for U.S. residents too. Let's institutionalize a privacy policy that can deal with the challenges of the 21st century.
Andy Oram, [email protected], is an editor at O'Reilly & Associates and moderator of the Cyber Rights mailing list for Computer Professionals for Social Responsibility. This article represents his views only.
Previously in Platform Independent:
Art Unplugged
Would I Join This Club If It Would Have Me as a Member?
The AOL/Time Warner Merger Impact on Cable Access
