1. Joint work with Emilien Antoine, Gerome Miklau, Julia Stoyanovich and Vera Zaychik Moffitt ICDE 2012Mai 30, 2012 Introducing Access Control in Webdamlog Serge Abiteboul INRIA Saclay & ENS Cachan

2. Abiteboul – DBPL - 2013 2 The Web as a distributed knowledge base Webdamlog: a rule-based language for the Web Access control in Webdamlog The Webdamlog system Conclusion

3. Abiteboul – DBPL - 2013 3 A typical Web user’s data What kinds of data?  data: photos, music, movies, reports, email  metadata: photo taken by Alice in Paris on...  ontologies: Alice’s ontology and mapping with other ontologies  localization: Alice’s pictures are on Picasa, back-ups are at INRIA  security: Facebook credentials (Alice, 123456)  annotations: Alice likes Elvis’ website  beliefs: Alice believes Elvis is alive  external knowledge: Bob keeps copies of Alice’s pictures  time, provenance,... all kinds Social data

4. Abiteboul – DBPL - 2013 4 A typical Web user’s data What kinds of data? Where is the data?  laptop, desktop, smartphone, tablet, car computer  mail, address book, agenda  Facebook, LinkedIn, Picasa, YouTube, Tweeter  svn, Google docs  also access to data / information of family, friends, companies associations all kinds everywhere

5. Abiteboul – DBPL - 2013 5 A typical Web user’s data What kinds of data? Where is the data? all kinds everywhere What kind of organization?  terminology: different ontologies  systems: personal machines, social networks  distribution: different localization  security: different protocols  quality: incomplete / inconsistent information heterogeneous

6. Abiteboul – DBPL - 2013 6 Example of processing Alice and Bob are getting engaged. Their friends want to offer them an album of photos where they are together To make such a photo album Find friends of Alice & Bob (say with Facebook) for each friend, find where she keeps her photos (say, Picassa) find the means to access her photos possibly via friends find the photos that feature Bob and Alice together, e.g., using tags or face recognition software possibly ask someone to verify the results Some reasoning is needed to execute these tasks automatically!

7. Abiteboul – DBPL - 2013 A typical Web user Overwhelmed by the mass of information Cannot find the information needed Is not aware of important events Cannot manage/control how others access and use his/her own data 7

8. Abiteboul – DBPL - 2013 YOU need help! How can systems help? We need to move from a Web of text to a Web of knowledge  In the spirit of semantic Web To better support user needs,  Systems need to analyze what is happening and construct knowledge  Systems should exchange knowledge  Systems should reason and infer knowledge 8

9. Abiteboul – DBPL - 2013 Thesis All this forms a distributed knowledge base with processing based on automated reasoning 9

10. Abiteboul – DBPL - 2013 10 Our topic Distributed reasoning Exchanging facts and rules Webdamlog Access control with access control

11. Abiteboul – DBPL - 2013 11 The Web as a distributed knowledge base Webdamlog: a rule-based language for the Web Access control in Webdamlog The Webdamlog system Conclusion

12. Abiteboul – DBPL - 2013 12 Webdamlog: a datalog-style language Datalog A prehistoric language by Web time... + nice and compact syntax + well-studied with many extensions + recursion essential: network cycles Webdamlog Not as simple/beautiful & procedural Needed for real Web applications! Webdamlog is not datalog

13. Abiteboul – DBPL - 2013 Webdamlog: an extension of datalog Datalog programfof(x,y) :- friend(x,y) fof(x,y) :- friend(x,z), fof(z,y) Extensional facts(stored in the database) friend(“peter”,”paul”) friend(“paul”, “mary”) friend(“mary”,”sue”) Intentional facts (derived) fof(“peter”,”paul”) fof(“peter”,”mary”) fof(“peter”, “sue”) fof(“paul”, “mary”)fof(“paul”, “sue”) fof(“mary”,”sue”) 13

14. Abiteboul – DBPL - 2013 14 Webdamlog: an extension of datalog Extends datalog negation, updates, distribution, delegation, time For a world that is distributed: autonomous and asynchronous peers dynamic: knowledge evolves; peers come and go Influenced by Active XML (INRIA) - for distribution & intentional data Dedalus (UC Berkeley) - for time & implementation

15. Abiteboul – DBPL - 2013 15 Facts Facts are of the form m@p(a 1,..., a n ), where m is a relation name& p is a peer name a 1,..., a n are data values (n is the arity of m@p) the set of data values includes the relations and peer names Examples friend@my-iphone(“peter”, “paul”) extensional fof@my-iphone(“adam”, “paul”) intentional

16. Abiteboul – DBPL - 2013 16 Examples of facts data & metadata: pictures@alice-iphone( 1771.jpg, “Paris”, 11/11/2011 ) ontology: isA@yago.com("Elvis”, theKing) annotations: tags@delicious.com(“wikipedia.org”, encyclopedia) localization: where@alice(pictures, picasa/alice) access rights: right@picasa(pictures, friends, read) security: secret@picasa/alice; public@picasa/alice

17. Abiteboul – DBPL - 2013 17 Rules Rules are of the form $R@$P($U) :- (not) $R 1 @$P 1 ($U 1 ),..., (not) $R n @$P n ($U n ) where $R, $R i are relation terms $P, $P i are peer terms $U, $U i are tuples of terms Safety condition $R and $P must appear positively bound in the body each variable in a negative literal must appear positively bound in the body A term is a variable or a constant Examples coming up, stay tuned

18. Abiteboul – DBPL - 2013 18 State transition Choose some peer p randomly – asynchronously Compute the transition of p the database updates at p the messages sent to other peers the delegations of rules to other peers Keep going forever (I 0, Γ 0, ∅ ) ➝ (I 1, Γ 1, Γ 1 * ) ➝... ➝ (I n, Γ n, Γ n * ) ➝... Fair sequence: each peer is selected infinitely often

19. Abiteboul – DBPL - 2013 The semantics of rules Classification based on locality and nature of head predicates (intentional or extensional) Local rule at my-laptop: all predicates in the body of the rules are from my-laptop Local with local intentional headclassic datalog Local with local extensional headdatabase update Local with non-local extensional headmessaging between peers Local with non-local intentional head view delegation Non-localgeneral delegation 19

20. Abiteboul – DBPL - 2013 20 Local rules with local intentional head Example: Rule at peer my-laptop friend is extensional, fof is intentional fof@my-iphone($x, $y) :- friend@my-iphone($x,$y) fof@my-iphone($x,$y) :- friend@my-iphone($x,$z), fof@my- iphone($z,$y) fof is the transitive closure of friend Datalog = Webdamlog with only local rules and local intentional head

21. Abiteboul – DBPL - 2013 21 Local rules with local extensional head A new fact is inserted into the local database believe@my-iphone(“Alice”, $loc) :- tell@my-iphone($p,”Alice”, $loc), friend@my-iphone($p)

22. Abiteboul – DBPL - 2013 22 Local rules with non-local extensional head A new fact is sent to an external peer via a message $message@$peer($name, “Happy birthday!”) :- today@my-iphone($date), birthday@my-iphone($name, $message, $peer, $date) Extensional facts: today@my-iphone(March 6) birthday@my-iphone("Manon”, “sendmail”, “gmail.com”, March 6) sendmail@gmail.com("Manon”, “Happy birthday”)

23. Abiteboul – DBPL - 2013 23 Local rules with non-local intentional head View delegation! boyMeetsGirl@gossip-site($girl, $boy) :- girls@my-iphone($girl, $loc), boys@my-iphone($boy, $loc) Semantics of boyMeetGirl@ gossip-site is a join of relations girls and boys from my-iphone Formally, my-iphone delegates a rule boyMeetGirl@ gossip-site (g,b) for each g, b, l, girls@my-iphone(g,l), boys@my-iphone(b,l)

24. Abiteboul – DBPL - 2013 24 Non-local rules: general delegation (at my-iphone): boyMeetsGirl@gossip-site($girl, $boy) :- girls@my-iphone($girl, $loc), boys@alice-iphone($boy, $loc) Suppose that girls@my-iphone(“Alice”, “Julia's birthday”) holds. Then my-iphone installs the following rule at alice-iphone (at alice-iphone): boyMeetsGirl@gossip-site(“Alice”, $boy) :- boys@alice-iphone($boy, “Julia's birthday”) When girls@my-iphone(“Alice”, “Julia's birthday”) no longer holds, my-iphone uninstalls the rule

25. Abiteboul – DBPL - 2013 25 Non-local rules: general delegation (at my-iphone): boyMeetsGirl@gossip-site($girl, $boy) :- girls@my-iphone($girl, $loc), boys@alice-iphone($boy, $loc) An alternative, more database-ish, way of looking at this: at my-iphone : seed@alice-iphone($girl, $loc):- girls@my-iphone($girl, $loc) at alice-iphone : boyMeetsGirl@gossip-site($girl, $boy) :- seed@alice-iphone($girl, $loc), boys@alice-iphone($boy, $loc) view delegation

26. Abiteboul – DBPL - 2013 26 Complexity of delegation: illustration fof(x,y) :- friend(x,y) (at p) fof@p(x,y) :- peers@p( $q ), friend@ $q (x,y) If peers@p contains 100 000 tuples peers@p(q 1 ),...., peers@p(q 100 000 ) This rule will install 100 000 rules! for i=1 to 100 000 (at q i ) fof@p(x,y) :- friend@q i (x,y) Data complexity transformed into program complexity

27. Abiteboul – DBPL - 2013 27 Summary of results [PODS 2011] Formal definition of the semantics of Webdamlog Results on expressivity  the model with delegation is more general, unless all peers and programs are known in advance Convergence is very hard to achieve  positive Webdamlog  strongly stratified programs with negation

28. Abiteboul – DBPL - 2013 28 The Web as a distributed knowledge base Webdamlog: a rule-based language for the Web Access control in Webdamlog The Webdamlog system Conclusion

29. Abiteboul – DBPL - 2013 Requirements Data access Users would like to control who can read and modify their information Data dissemination Users would like to control how their data are transferred from one participant to another, and how they are combined, with the owner of each piece of data keeping some control over it Application control Users would like to control which applications can run on their behalf, and what information these applications can access. 29

30. Abiteboul – DBPL - 2013 The general picture The privileges we consider: read, write, grant For read: Coarse grained access control: at the relation level Fine grain access control: at the tuple level 30

31. Abiteboul – DBPL - 2013 Insertion in extentional relations Definition of intensional relations Requires write privilege on the target relation [at Alice] alicePhotos@Bob($f) :- person@Alice($p, “Friend”), personInPhoto@Alice($pid, $p), photo@Alice($pid,−, $f) [at Alice] allPhotos@Alice($f) : alicePhotos@Alice($f) [at Bob] allPhotos@Alice($f) :- bobPhotos@Bob($f) 31

32. Abiteboul – DBPL - 2013 Who can read a fact ? – default Extensional relations: if you have read privilege to the relation Intensional relations: if you have read privilege to the relation & if you can read all the tuples that have been used to create this fact – provenance of the fact 32

33. Abiteboul – DBPL - 2013 Digression: provenance Provenance of a tuple How it was constructed: conjunction Alternatives: disjunction 33

34. Abiteboul – DBPL - 2013 34 Digression: provenance graph gossip@p(Jane, John) rule 3 × girls@p(Jane, Julia’s birthday) boys@p(John, Julia's birthday) rule 1 × × boyMeetsGirl@p(Jane, John) × + (Also used for maintenance in case of update)

35. Abiteboul – DBPL - 2013 Coarse grain access control [at Alice] alicePhotos@Bob($f) :- person@Alice($p, “Friend”), personInPhoto@Alice($pid, $p), photo@Alice($pid,−, $f) alicePhotos@Bob is extensional Whoever has read access to alicePhotos@Bob sees all the relation 35

36. Abiteboul – DBPL - 2013 Fine grain access control [at Alice] allPhotos@Alice($f) : alicePhotos@Alice($f) [at Bob] allPhotos@Alice($f) :- bobPhotos@Bob($f) allPhotos@Alice is intensional Sue who has read privilege to allPhotos@Alice and alicePhotos only, can see only the photos of Alice in allPhotos Lili who has read privilege to the three relations, sees everything 36

37. Abiteboul – DBPL - 2013 Overwriting the default for intensional data Let us change the rule to: [at Alice] allPhotos@$x($f) :- alicePhotos@Alice($f), friends@Alice($x) Issue: you can read the photos only if you also have read privilege to friends@Alice 37

38. Abiteboul – DBPL - 2013 Overwriting the default for intensional data [at Alice] allPhotos@$x($f) :- alicePhotos@Alice($f), [hide friends@Alice($x)] Hide: block the provenance from friends@Alice Similar mechanism for extensional data – expose 38

39. Abiteboul – DBPL - 2013 Issues with non local rules [at Bob] message@Sue(“I hate you”) :- date@Alice(d) aliceSecret@Bob(x) :- date@Alice(d), secret@Alice(x) Ignoring access rights, by delegation, this results in running [at Alice] message@Sue(“I hate you”) :- date@Alice(d) aliceSecret@Bob(x) :- date@Alice(d), secret@Alice(x) 39

40. Abiteboul – DBPL - 2013 Default solution: sand box We run the rule at Alice in a Sandbox We use the access rights of Bob So the second rule does not succeed in sending secrets The message specifies that this is done at Bob’s request So requires authentication/signatures Alternative: delegation without sandbox. Possible if the peer that asks for the delegation is given the privilege to install rules at the other peer – Here if Alice gives Bob the right to install a rule in her environment 40

41. Abiteboul – DBPL - 2013 Access control implementation A program with access control is compiled locally in a Webdamlog program without that is executed Access control data is managed like any other data Relation acl (defines relation access) Relation kind (ext or int) Based on provenance implemented as a distributed graph On-going work on optimization 41

42. Abiteboul – DBPL - 2013 42 The Web as a distributed knowledge base Webdamlog: a rule-based language for the Web Access control in Webdamlog The Webdamlog system

43. Abiteboul – DBPL - 2013 43 The Webdamlog engine Based on Bud developed at UC Berkeley Manages knowledge  Stores facts and rules  exchanges knowledge with other engines  performs reasoning

44. Abiteboul – DBPL - 2013 44 The engine: beyond Bud Compilation of (Bud’s language) Main Webdamlog features not supported by Bud 1. Variable relation and peer names 2. Delegations with dynamic changes of the program Webdamlog+AC ⇒ Webdamlog ⇒ Bloom

45. Abiteboul – DBPL - 2013 45 The Webdamlog peer Support communication with other peers and with users Support common security protocols Support wrappers to external systems such as Facebook Provides Web interfaces

46. Abiteboul – DBPL - 2013 46 Provenance graphs Records the history of derivation Provenance semiring semantics [Green et al. 07] Used for performance optimization Used for fine grain access control Other possible uses such as explanation of results

47. Abiteboul – DBPL - 2013 47 The Web as a distributed knowledge base Webdamlog: a rule-based language for the Web Access control in Webdamlog The Webdamlog system Conclusion

48. Abiteboul – DBPL - 2013 Thesis Let us turn the Web into a distributed knowledge base with billions of users supported by billions of systems analyzing information extracting knowledge exchanging knowledge inferring knowledge 48

49. Abiteboul – DBPL - 2013 Webdamlog Language A language for distributed data management [PODS 2011] Datalog with distribution, updates, messaging Main novelty: delegation Implementation WebdamExchange peer in Java [demo ICDE 2011] Webdamlog engine based on Bud [demo Sigmod 2013] Access control: on-going work with Miklau- Stoyanovich Probabilistic Webdamlog: on-going work with Deutch- Vianu 49

50. Cambridge University Press, 2012 http://webdam.inria.fr/Jorge Grazie !