1 / 14

Shortcomings of P3P for Privacy Authorization: Lessons Learned and Conclusions

This article explores the limitations of P3P for privacy authorization and presents practical experiences using P3P. It discusses the completeness of the privacy picture, choices for enforcing privacy, and the need for an enforceable privacy policy language.

wilbourn
Download Presentation

Shortcomings of P3P for Privacy Authorization: Lessons Learned and Conclusions

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Shortcomings of P3P for Privacy Authorization Lessons Learned when using P3P for Privacy Authorization Paul Ashley, IBM Software Group Günter Karjoth, IBM Research

  2. Outline • The Privacy Pie The Complete Picture The Pieces of the Pie • Choices for Enforcing Privacy • Practical Experiences with using P3P • Conclusions

  3. 1.0 The Complete Picture „The Privacy Pie“ P3P Collect Consent Notice Enforce Privacy Policy Audit Compliance

  4. Mark the box if we can send your home address to our trusted partners. 1.1. Notice Publishing a Privacy Notice: • Privacy promise • Offered user choices Requirements: • Unified global format • Well-defined semantics and user-agent guidelines • Describes user‘s view of enterprises (= disclosure-oriented) P3P: • Well-suited for Notices Data User

  5. Data Subject I agree with this policy and I marked the box. 1.2. Collecting Consent Collecting Consent from Data-Subjects: • Consent to a particular privacy policy • Choices for the provided options Requirements: • Well-defined back-channel • User‘s View P3P: • Not applicable • No well-defined format available • Usually integrated into applications

  6. 1.3. Privacy Enforcement Application Enforcing Privacy Restrictions within the Enterprise: • Consented privacy promises • Enterprise-internal Privacy Policy Requirements: • Fine-grained; enterprise-view • Compatible with privacy promises • Adoptable to varying enterprises P3P: • Not fine-grained • Identical to promises Your request is not allowed by the policy! Personal Data

  7. Because you opted in to the marketing policy 1 on April 1, 2002. Data Subject Data User 1.4a. Audit Why did you send me spam? • in Traditional Access control, logging the access is enough • in Privacy Management, all actions on PII must be justified in terms of authorizations

  8. Inventory 1.4b. Reporting Providing Privacy Reports: • What personal data is stored? • What is the applicable policy for each piece of data? • How was a certain piece of data accessed in the past? Requirements: • Extensive logging • Policy and consent management P3P: • Only for promises Usage Log Policy Report

  9. 2. Choices for Enforcing Privacy • Do nothing and pray • Coding privacy policy into applications • cost of coding and maintenance becomes prohibitive • time to change to a new policy is far too large.  • each of the applications has to be modified for each policy change • difficult reporting and auditing • Centralized Enforcement Infrastructure • centralized consent and policy management • centralized auditing and reporting • distributed enforcement

  10. 3.Practical Experiences with Using P3P for an Authorization Language • Use of predefined types • Only action is use • No obligations • No disallow rule • Limited conditions

  11. 3.1 Use of pre-defined types P3P pre-defines a set of types: • Data Categories (17): physical, online, uniqueid, purchase, financial, navigation, demographic, content, health, preference, … • Purpose (12): current, pseudo-analysis, individual-decision, contact, telemarketing, admin, develop, tailoring, … • Recipient (6): ours, same, delivery, unrelated • Retention (5): no-retention, stated-purpose, business-practices, indefinitely, .. u useful for interoperability but not for authorization Useful purposes in health care: • medical_diagnosis, blood_research, statistical_analysis, billing u enterprises want to define their own types !

  12. 3.2 No obligations P3P does not allow the use of an obligation in a policy ! For example, our health care customers wanted to write policy statements of the form: • ALLOW general_practioners to READ medical_records if {some conditions} with obligation {if patient is of VIP category flag alert} • ALLOW sales to WRITE customer_data if {conditions} with obligation {if customer < 18 then get parent approval or delete data within 7 days} • We were unable to implement these policies with our customers.

  13. 3.3 No disallow rule • Policies become much more complicated than necessary !Engineering: e_assistants, e_managers, e_contractors, e_architects, e_administrative • A customer required a set of rules: • ALLOW engineering to READ customer_engineering_data • DISALLOW e_contractors to READ customer_engineering_data • Not having a DISALLOW rule means that this would have to be rewritten as • ALLOW e_assistants to READ customer_engineering_data • ALLOW e_managers to READ customer_engineering_data • ALLOW e_architects to READ customer_engineering_data • ALLOW e_architects to READ customer_engineering_data

  14. 4. Conclusions • P3P is well-suited for formalizing privacy promises that are communicated to end-users • P3P is too coarse-grained • many of the policy statements from our customers required conditions to be evaluated. • P3P lacks some features for enterprise-internal privacy enforcement. => enforceable Privacy Policy Language is Needed

More Related