1 / 37

An XPath-based Preference Language for P3P IBM Almaden Research Center

An XPath-based Preference Language for P3P IBM Almaden Research Center. Rakesh Agrawal Jerry Kiernan Ramakrishnan Srikant Yirong Xu. Growing Concern about Privacy. “Privacy #1 issue in the 21Century” -Wall Street Journal, January 24, 2000.

gardenia
Download Presentation

An XPath-based Preference Language for P3P IBM Almaden Research Center

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. An XPath-based Preference Language for P3PIBM Almaden Research Center Rakesh Agrawal Jerry Kiernan Ramakrishnan Srikant Yirong Xu

  2. Growing Concern about Privacy “Privacy #1 issue in the 21Century” -Wall Street Journal, January 24, 2000 The issues of trust, privacy and security are generally believed to be the greatest barriers to widespread use of the Internet for commercial purposes.

  3. What is P3P • Current privacy policies are written by the lawyers, for the lawyers • P3P solves this problem. • Encodes policies in machine readable format (XML). • Goal: programatically match privacy policies with user preferences. • W3C recommendation (April 2002) • Need preference language to make this work! • APPEL: W3C Draft • Unfortunately …

  4. Outline • Motivation • Problems with APPEL • Can these problems be fixed? • An XPath-based preference language • Conclusion

  5. Context: P3P Policies <POLICY> ... ... <STATEMENT> <PURPOSE><current/><telemarketing/></PURPOSE> <RECIPIENT><ours/><delivery/></RECIPIENT> <RETENTION><indefinitely/></RETENTION> <DATA-GROUP> <DATA ref="#user.name"/> <DATAref="#user.home-info.telecom.telephone"/> </DATA-GROUP> </STATEMENT> <POLICY>

  6. Jack’s Simple Preference • Only purposes “current” and “pseudo-analysis” are acceptable. • Will use this example to illustrate the problems with APPEL.

  7. Jack’s First Attempt <appel:RULESET> <appel:RULE behavior="request"> <POLICY> <STATEMENT> <PURPOSE appel:connective="or-exact"> <current/> <pseudo-analysis/> </PURPOSE> </STATEMENT> </POLICY> </appel:RULE> <appel:RULE behavior="block"/> <appel:OTHERWISE/> </appel:RULE> </appel:RULESET> APPEL preferences are organized as a list of rules The APPEL engine evaluates rule in order until one fires

  8. Jack’s First Attempt <appel:RULESET> <appel:RULE behavior="request"> <POLICY> <STATEMENT> <PURPOSE appel:connective="or-exact"> <current/> <pseudo-analysis/> </PURPOSE> </STATEMENT> </POLICY> </appel:RULE> <appel:RULE behavior="block"/> <appel:OTHERWISE/> </appel:RULE> </appel:RULESET> Rule head: Specifies the outcome of the rule (request or block) Rule body: Specifies the structure and content of matching policies

  9. Jack’s First Attempt Logical connectives: Govern matching of subelements <appel:RULESET> <appel:RULE behavior="request"> <POLICY> <STATEMENT> <PURPOSE appel:connective="or-exact"> <current/> <pseudo-analysis/> </PURPOSE> </STATEMENT> </POLICY> </appel:RULE> <appel:RULE behavior="block"/> <appel:OTHERWISE/> </appel:RULE> </appel:RULESET> Strictly access sites which collect personal information for purposes “current” and “pseudo-analysis”

  10. Problem: Policies with Multiple Statements Problem: A policy can have multiple statements, some of which may violate the user’s preference This statement will match, and the policy will be accepted. <POLICY> ... ... <STATEMENT> <PURPOSE><current/></PURPOSE> … … </STATEMENT> <STATEMENT> <PURPOSE><telemarketing/></PURPOSE> … … </STATEMENT> … … <POLICY> This statement (tele-marketing) is exactly what Jack tried to avoid by putting “or-exact” in purpose!

  11. Jack’s Second Attempt Use “and-exact” to ensure that each statement in the policy satisfies the condition <appel:RULESET> <appel:RULE behavior="request"> <POLICY> <STATEMENT appel:connective=“and-exact”> … … </STATEMENT> </POLICY> </appel:RULE> … … </appel:RULESET> Problem: The connective applies to the subelements of a STATEMENT, not to all statements in a policy

  12. Jack’s Second Attempt Use “and-exact” to ensure that each statement in the policy satisfies the condition <appel:RULESET> <appel:RULE behavior="request"> <POLICY appel:connective="and-exact"> <STATEMENT> … … </STATEMENT> </POLICY> </appel:RULE> … … </appel:RULESET>

  13. Problem: POLICY has Multiple Subelements <POLICY> <ENTITY> … </ENTITY> <ACCESS> … </ACCESS> <DISPUTES> … </DISPUTES> <REMEDIES> … </REMEDIES> <STATEMENT> … … </STATEMENT> <STATEMENT> … … </STATEMENT> … … <POLICY> Problem: POLICY has other subelements aside from STATEMENT

  14. Key Point: Cannot Specify What is Acceptable <POLICY> … … <STATEMENTS> <STATEMENT> … … </STATEMENT> <STATEMENT> … … </STATEMENT> </STATEMENTS> … … <POLICY> There is no STATEMENTS tag in P3P (which could be used to specify a logical connective)

  15. Jack spends quality time with the manuals … • … figures out he can convert his preference into specifying what is unacceptable.

  16. Jack’s Third Attempt Convert positive preferences into negative preferences <appel:RULE behavior="block"> <POLICY> <STATEMENT> <PURPOSE appel:connective="or"> <admin/><develop/><tailoring/> <pseudo-decision/><individual-analysis/> <individual-decision/><contact/> <historical/><telemarketing/> <other-purpose/> </PURPOSE> </STATEMENT> </POLICY> </appel:RULE> Note: Must enumerate all unacceptable purposes Problem: Does not block web sites that use extensions

  17. How about a slightly more complex preference? • Purposes “current” and “pseudo-analysis” are acceptable • Purpose “individual-analysis” is also acceptable provided the recipient is “ours”

  18. Negating Logical Expressions… • First, have to negate the expression (since we can’t specify what is acceptable). • Forall (current OR … OR ( … AND … ) => accept • Becomes: • Exists !(current AND … and ( … OR … ) => block

  19. Parse Tree of Expression Or Purpose = “current” And Purpose = “pseudo-analysis” Purpose = “individual-analysis” Recipient = “ours”

  20. Negated Parse Tree of Expression And Purpose != “current” Or Purpose != “pseudo-analysis” Purpose != “individual-analysis” Recipient != “ours”

  21. Parse Trees that can be Expressed in APPEL Logical expressions involving PURPOSE and RECIPIENT that can be expressed as a single APPEL rule Statement connective Cannot express the desired condition as a single rule Purpose connective Recipient connective The condition can be expressed as multiple rules, but the translation is no longer a simple negation current ours Individual-analysis Pseudo-analysis

  22. Translation into APPEL Negations must be translated into enumerations

  23. Recap: Problems With APPEL • APPEL rules cannot be used to specify what is acceptable, only what is unacceptable • Logical expressions involving simple combinations of purpose, recipient and data are hard to express • APPEL logical connectives are tied to the structure of a policy • Writing APPEL preferences is error prone, even for experts • Errors in the APPEL working draft

  24. Outline • Overview of P3P and APPEL • Problems with APPEL • Can these problems be fixed? • An XPath-based preference language • Conclusion

  25. New Operators • Enumeration of unacceptable choices • Can APPEL be fixed by adding new operators? • Any-except logical connective • True if any element in the policy is not listed as a subelement in the rule

  26. Any-except Operator: Helps for Example 1, but not Example 2 <appel:RULE behavior="block"> <POLICY> <STATEMENT> <PURPOSE appel:connective="any-except"> <current/><pseudo-analysis/> </PURPOSE> </STATEMENT> </POLICY> </appel:RULE> Lists acceptable choices Preferences involving logical operators over combinations of purpose, recipient, and data are still a problem

  27. Modify P3P to Fix APPEL? Add a STATEMENTS tag to P3P policies to specify acceptable policies <appel:RULE behavior="request"> <POLICY> <STATEMENTS appel:connective="or-exact"> <STATEMENT> … … </STATEMENT> <STATEMENT> … … </STATEMENT> </STATEMENTS> </POLICY> </appel:RULE> P3P is a W3C Recommendation and therefore hard to change Conditions over combinations of PURPOSE, RECIPIENT and DATA remain hard to express

  28. Summary: Can the problems be fixed? • Problems with APPEL are fundamental. • Problems arise from the design choice to structure APPEL like P3P • Fixing APPEL would essentially mean designing a new language.

  29. Outline • Overview of P3P and APPEL • Problems with APPEL • Can these problems be fixed? • An XPath-based preference language • Conclusion

  30. Language Design Goals • At least as expressive as APPEL • APPEL designers investigated requirements for a preference language • Use, if possible, an existing language • P3P is specified in an XML format • XPath is a query language for XML • XPath is a W3C Recommendation which is already used in a variety of available systems • Benefits from the rigorous work done on the design of XPath syntax and semantics

  31. XPref • Retain APPEL rule heads • Replace APPEL rule bodies with XPath • Using a strict subset of XPath 1.0 necessary for expressing preferences • Adding the XPath 2.0 “every” quantified expression to simplify expressing positive preferences

  32. Negative Preferences in XPref Block access to sites where the purpose is “individual-analysis” and the recipient is not “ours” <RULESET> <RULE behavior="block“ condition="/POLICY/STATEMENT [ PURPOSE/*[ name(.) = "individual-analysis"] and RECIPIENT/* [ name(.) != "ours"] ]" /> <RULE behavior="request" condition="true"/> </RULESET>

  33. Positive Preferences in XPref Access sites whose purposes for collecting information are strictly “current” or “pseudo-analysis” <RULESET> <RULE behavior="request“ condition="/POLICY [ every $pname in STATEMENT/PURPOSE/* satisfies (name($pname) = "current" or name($pname) = "pseudo-analysis") ]" /> <RULE behavior="block" condition="true"/> </RULESET>

  34. Expressive Power • Algorithm for converting APPEL to XPref

  35. Conclusion • P3P is currently the only standard for expressing privacy policies on the web • To be successful, P3P needs a viable preference language • XPref solves the problems of APPEL • XPref is based upon XPath which is an existing and successful standard • An algorithm which translates XPref into APPEL is given in the paper • Next step: make XPref a W3C recommendation

  36. Policy-Preference Matching request policy 1 policy and user preference send policy 3 2 Browser APPEL Engine Web Server request web page if policy conforms to preference result of matching 4 5

  37. P3P Adoption

More Related