AuthorITies: Internet Zone

Welcome Guest. | Log In| Register | Membership Benefits

June 8, 1998

Net Privacy Gets A Boost

By Jason Levitt
he recent public posting of the first working draft of the Platform for Privacy Preferences (P3P) has me all teary-eyed and nostalgic about a simpler time -- a time when online privacy wasn't a big concern because there was hardly anyone on the Internet. Many of today's online evils either didn't exist or were minor annoyances.
Alas, that age of relative innocence seems long gone, but P3P, when it is widely deployed and includes the use of digital signatures and certificates, will likely make online life much easier for the average Internet user. It will let Web sites advertise exactly what kinds of private information they want to collect from visitors, and it will let visitors decide what private information (age, gender, birth date, employer, phone number, etc.) they want to divulge. Moreover, it will let both the Web site and user negotiate to determine what the private information can be used for.
A Simpler Time
In the early, pre-Web, days of the Internet, circa 1985-1992, privacy didn't seem to be much of an issue. Yes, there were some nasty police actions, and the subsequent formation of the Electronic Frontier Foundation, but the mass commercialization of the Internet had yet to happen.
The privacy of the everyday Internet user simply wasn't a hot button issue. The Internet, after all, was running mostly on Unix systems, technology that wasn't designed with security or privacy in mind. The result was that E-mail was exchanged, FTP sites were accessed, Usenet news was posted, and IRC (Internet Relay Chat) hummed along without much concern over who might be logging the results. This was a period before spam or online marketing was commonplace. The vast majority of online users were students or worked for universities, research institutions, or larger computer companies.
Of course, the World Wide Web changed all that.
Privacy And The Web
When people started using the Mosaic browser, few cared (they probably didn't know, actually) that some of their personal data could be sent to a Web site every time they accessed a Web page. It's still true that Web servers can request certain data from your browser using the HTTP 1.0 protocol. This happens invisibly, without the user knowing. Servers can request your E-mail address, the last Web page you accessed, the version of the browser software your are using, and, of course, the IP address of your originating machine. That's a lot of private data -- certainly a lot of useful data for marketing purposes.
It's heinous enough that marketeers would collect such data. But it's really how they use the collected data that has irked many users. Spam, mass unsolicited bulk E-mails that try to sell you something, is the most irritating. But some, more legitimate, sites that want you to fill out forms, perhaps just to get a software update, can be equally scary. The problem is that you don't know what else they'll do with the information you provide besides send you a software update.
Cookies, the small text strings of data that Web sites can store on your hard disk for future reference, have, perhaps, generated the most controversy of any browser advertisement mechanism. Though they can be easily disabled through the preferences options on both Communicator and IE 4.x, there are so many sites that make good use of them (Amazon.com, for example), they are generally more useful than harmful. I generally keep them enabled just so I can make use of certain sites that rely on them, usually online catalogs and bulletin board sites. Again, it's how the Web sites choose to use cookies that can be annoying.
Enter P3P
P3P, the Platform for Privacy Preferences, is exactly what it sounds like. It's an extensive syntax and set of data elements, specified in the RDF (Resource Description Framework) language, that lets you negotiate via your browser with a Web site on exactly what information about yourself you wish to reveal and how that information may be used. RDF, by the way, is a language written in XML (eXtensible Markup Language), the forthcoming lingua franca of data interchange on the Internet.
Thankfully, users will rarely, if ever, see any of the P3P syntax. In its likely incarnation in the Netscape and Microsoft browsers, you will have an elaborate preferences dialog box that will let you specify what personal information you wish to disclose. For example, you may wish to divulge only your age and gender to the Microsoft Site Builder Network site and allow that information to be used only within Site Builder. However, you may wish to disclose your full name, phone number, and shipping address to Amazon.com to order books, and then let them use that personal data for research and development.
By default, you might want to disclose no personal data to any site, in which case, when you enter a URL in your browser, a dialog box might pop up with a warning that the site you are about to enter wants you to disclose certain personal data. You can then negotiate (either using stored negotiation preferences or via dialog boxes) with the site to see if you can reach an agreement. The same dialog could possibly take place when filling out forms, though dealing with forms and non-Web protocols, such as FTP, is still being ironed out by the P3P working group.
Cookies, as we know them, will disappear in P3P, to be replaced by a Temporary or Pairwise Unique ID (TUID/PUID). Temporary IDs last only one user session (the length of time you are connected to a particular site) whereas Pairwise IDs can extend over multiple sessions. Unlike cookies, these IDs do not have any ancillary data with them. There is no place, for example, to store user IDs and passwords.
P3P negotiations amount to minilegal-agreements, although the true identity of participants will depend on the implementation of digital signatures and certificates within the standard. It will be interesting to see what happens when someone attempts to sue for misuse of personal data.
Fortunately, the P3P language is relatively simple and elegant, a natural by-product of its XML roots. There are three basic markup tags:
[proposal] -- defines the scope of the disclosures (for example, what Web pages are included in the agreement).
[statement] -- defines how the site intends to use the personal data it collects and where the site can use it (for example, outside or within the Web site's company).
[disclosure] -- defines how or if users may contact the Web site administrators and if their personal data can be modified in the future.
There are also several tags for encoding data. They are , , and .
An actual example of using P3P to negotiate access to private data is shown in the example at the bottom of this page.
The Future
A final draft of the P3P specification will likely be completed by the end of the year which means that we can't seriously hope for implementations to appear before then. Nevertheless, this is a good time to think about how your Web site might want to advertise its desires to prospective users.
P3P doesn't invalidate, by the way, the existing PICS (Platform for Internet Content Selection) standard, which is really just a content-labeling scheme. PICS is not currently implemented using RDF and XML, but a future version will be. When that happens, P3P can be easily used in conjunction with PICS to more clearly specify the nature of a site's content. You could then be informed that a site containing explicit sexual situations and graphic violence wants your name, gender, and birth date for some marketing scheme. In actual practice, the level of description could be quite a bit more detailed than that. I won't give an example, though. :-) P3P Negotiation Example Here's a sample user session that makes use of P3P. This sample is taken verbatim from Appendix 2 of the proposed W3C Working Draft of P3P, dated May 19th, 1998.
A user directs their Web browser to go to home page of CoolCatalog. She has never been there before; she requests a P3P proposal as part of the request by advertising that her browser understands P3P.

CoolCatalog sends a proposal, including privacy practices, disclosures, and the data elements to which they apply. In this instance, the service asks to be given the PUID as part of the returnID automatically in the future and requests the user's gender from the user repository.

(Note that the proposal is split across multiple lines for readability; over the network, a CRLF pair would be added only after the We will use this in the example lineflows below as well.) The user refuses this proposal. Imagine that the agreementID (hash) of the above proposal is "e3a5d71297d104f1"; the user's next HTTP request would look like the following: The site offers a new proposal, this time it requests the automatic returnID, and from the user's repository the first name and optional age, both for the purposes of customizing the site.

The user agrees only to the provision of the automatic returnID and first name for customization only, and sends the data. Assume that the agreementID of the above proposal is "94df1293a3e519bb". At this point, the service would return the CoolCatalog homepage.

The user returns to the site a day later, sending the returnID automatically.
However, the server again needs the user's first name, so it asks for it under the previous agreement.
The user returns their first name and PUID. The service would then respond with their homepage, as before:
AuthorITies Archive
Send Us Your Feedback

Top of the Page

Rich Levin:
Run Time
Rich fills you in on all of the latest products, issues, and trends in application development.

Stuart J. Johnston:
Redmond Watch
As our eyes and ears in Redmond, Stuart gives his perspective on the latest events at Microsoft.

Charles Pelton:
Eye On I.T.
Charles explores IT management issues and strategies that business and technology managers face.