Administration
  Home arrow Administration arrow Page 3 - Understanding P3P
Dev Shed Forums 
Administration  
Apache  
BrainDump  
DHTML  
Flash  
Java  
JavaScript  
Multimedia  
MySQL  
Oracle  
Perl  
PHP  
Practices  
Python  
Reviews  
Security  
Style-Sheets  
Web Services  
XML  
Zend  
Zope  
Forums Sitemap 
IBM® developerWorks 
Dedicated Servers 
E-Commerce Hosting 
Linux Web Hosting 
Managed Hosting 
Small Business Hosting 
Download TestComplete 
VPS Hosting 
Weekly Newsletter

 
Developer Updates  
Free Website Content 
IBM Developerworks
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us Get Paid 
Request Media Kit
Contact Us 
Site Map 
Privacy Policy 
Support 
 USERNAME
 
 PASSWORD
 
 
  >>> SIGN UP!  
  Lost Password? 
ADMINISTRATION

Understanding P3P
By: Vikram Vaswani, (c) Melonfire
  • Search For More Articles!
  • Disclaimer
  • Author Terms
  • Rating: 4 stars4 stars4 stars4 stars4 stars / 1
    2002-01-03

    Table of Contents:
  • Understanding P3P
  • Private Thoughts
  • Data Overload
  • Off Target
  • Endgame

  • Rate this Article: Poor Best 
      ADD THIS ARTICLE TO:
      Del.ici.ous Digg
      Blink Simpy
      Google Spurl
      Y! MyWeb Furl
    Email Me Similar Content When Posted
    Add Developer Shed Article Feed To Your Site
    Email Article To Friend
    Print Version Of Article
    PDF Version Of Article
     
     
     
    ADVERTISEMENT

    Route your faxes to your email inbox. Private, secure fax numbers available from CallWave. Choose your fax number.

    Understanding P3P - Data Overload
    (Page 3 of 5 )

    Here's an example of a simple policy:
    <policies>
    <policy name="feedback"
    discuri="http://www.melonfire.com/w3c/feedback_policy.html">
    <!-- who's collecting the information? -->
    <entity>
    <data-group>
    <data ref="#corp.name">Melonfire</data>
    <data ref="#corp.email">melonfire@mail.com</data>
    </data-group>
    </entity>
    <!-- statement explaining the type of information collected, and why? -->
    <statement>
    <purpose><develop required="always" /></purpose>
    <consequence>Melonfire uses your feedback to improve its content
    quality. </consequence>
    <recipient><ours/></recipient>
    <retention><no-rentention /></retention>
    <data-group>
    <data ref="#visitor.name" optional="yes" />
    <data ref="#visitor.email" optional="no"/>
    </data-group>
    </statement>
    <!-- how much of it is shared with others? -->
    <access><none /></access>
    <!-- how are disputes resolved? -->
    <disputes-group>
    <disputes resolution-type="service"
    service="http://www.melonfire.com/cs/" short-description="Melonfire
    Customer Support">
    <remedies><correct/></remedies>
    </disputes>
    </disputes-group>
    </policy>
    </policies>
    This may look complicated, but it's actually pretty simple. The document is broken up into distinct sections, each one serving a particular purpose. Every policy begins and ends with <policy> tags; a single document may contain more than one policy, each one identified by a unique "name" attribute and a URL identifying the English-language version of the policy statement.

    Within a policy, the <entity> section identifies the entity requesting the information (Melonfire), together with contact details. Next, the <statement> section explains why the information is being collected (in this case, for further development or improvement of the site), together with a list of the data elements collected (name and email address), how long they're stored for (not too long), and who uses it (the site owners only). The <access> element, which is mandatory, explains who has access to the data collected, while the <disputes-group> element provides information on the site's dispute resolution policy.

    In case you're wondering where the element names and values come from, most of them are defined and explained in the P3P specification. I won't get into the details of all the options here - you should look at the P3P specification if you're interested - though I will tell you that the choices presented are quite exhaustive, enabling a Web service provider to describe a site's privacy policy in all relevant detail.

    More Administration Articles
    More By Vikram Vaswani, (c) Melonfire


     

       

    ADMINISTRATION ARTICLES

    - Configuring Load-Balanced Clusters
    - Load-Balanced Clusters
    - UNIX Time Format Demystified
    - Making Changes in the CVS
    - Building Your First CVS Repository
    - CVS Quickstart Guide
    - Authorizing Users in Samba
    - Handling User Accounts in Samba
    - Authentication in Samba
    - Accounts, Authentication, and Authorization
    - Advanced Concepts on Dealing with Files and ...
    - Dealing with Files and Filesystems
    - More Hacks for the User Environment in BSD
    - Personalizing the User Environment in BSD
    - Customizing the User Environment in BSD

     
    Accelerating Trading Partner Performance
     
    Competing on Analytics
     
    Cost Effective Scaling with Virtualization and Coyote Point Systems
     
    Five Checkpoints to Implementing IP Telephony
     
    Hosted Email Security: Staying Ahead of New Threats
     




    © 2003-2008 by Developer Shed. All rights reserved. DS Cluster 1 hosted by Hostway