Current Social Web applications provide users with means to easily publish their personal information on the Web. However, once published, users cannot control how their data can be accessed apart from applying generic preferences (such as \friends" or \family"). In this paper, we describe how we enable ner-grained privacy preferences using the Privacy Preference Ontology (PPO); a light-weight vocabulary for de ning privacy settings on the Social Web. In particular, we describe the formal semantic model of PPO and also present MyPrivacyManager, a privacy preference manager that let users (1) create privacy preferences using the aforementioned ontology and (2) restrict access to their data to third-party users based on pro le features such as interests, relationships and common attributes.
de ne such ne-grained settings. While data from major websites is generally not modelled directly in RDF, wrappers can easily be implemented through their API. In addition, PPO can be natively used in Social Semantic Web applications, i.e. Social Web applications directly using RDF to model their data, such as Semantic MediaWiki or Drupal 7.
In this paper, we detail the formal model of PPO, and also present a privacy
preference manager (MyPrivacyManager), letting users: (
The remainder of the paper is organised as follows: Section 2 provides an overview of the Privacy Preference Ontology (PPO) and presents use cases for PPO. In Section 3, we present our formal model. In section 4 we present the implementation of MyPrivacyManager. Section 5 discusses related work and Section 6 presents future work and concludes the paper. 2 2.1
The Privacy Preference Ontology (PPO) [10] provides a light-weight vocabulary enabling Linked Data creators to describe ne-grained privacy preferences for restricting (or granting) access to speci c data. PPO can be used for instance to restrict part of a FOAF user pro le only to users that have similar interests. It provides a machine-readable way to de ne settings such as \Provide my phone number only to DERI colleagues" or \Grant write access to this picture gallery only to people I've met in real-life".
As we deal with Semantic Web data, a privacy preference (Figure 1), de nes:
(
As mentioned in section 1, current social networks provide minimum privacy settings such as granting privileges to all people belonging to one's social graph to access his/her information. Suppose a social network which provides users to specify which information can be accessed by speci c users not necessarily in one's social graph, for instance having similar interests. Although applications are being developed to export user information from closed social networks into RDF, the privacy settings are platform dependent such that the privacy settings cannot be reused on other platforms. Moreover, privacy preferences cannot make use of other platform's information, for instance, de ning a privacy preference that restricts access to users from one platform and grants users from another platform. Therefore, a system is required that provides users to create ne-grained privacy preferences described using PPO which can be used by different platforms. This system will provide users to be fully in control who can access their personal information and who can access their published RDF data. Additionally, the user can set privacy preferences to control which data can be used by recommender systems or other applications. 3
As portrayed in gure 1, a PPO-based privacy preference consists of: (
De nition 1: Restrictions. A restriction applies to a Resource, a Statement
or a Named Graph (Fig. 1), where:
{ A Resource (instance of rdfs:Resource) is identi ed by its own URI;
{ A Statement consists of a < subject; predicate; object > triple, each being
instances of rdfs:Resource6;
{ A Named Graph consists of (
Let St be a statement, U a URI, S be a subject, P a predicate, O an object, N G a named graph and A an access control privilege. Let Subject(U; St) mean that U is subject of St, P redicate(U; St) mean that U is a predicate of St, Object(U; St) mean that U is an object of St, RDF Graph(St; N G) mean that St is contained within the RDF graph of N G and AssignAccess(U; A) mean that A is assigned to U .
Restricting access to a resource is de ned as follows.
(
In other words, restricting access to a resource restricts access to all statements involving that resource as subject, predicate or object.
Restricting access to a statement is de ned as follows.
Restricting access to a named graph is de ned as follows.
(
De nition 2: Conditions. A condition de nes whether what is being restricted has: { a resource's URI identi ed as a statement's subject or object; { an instance of a class which is de ned as a statement's subject or object; { a statement contains a particular literal as a value and; { a statement that contains a particular property.
Let St be a statement, U a URI, C a class and A an access control privilege. Let Subject(U; St) mean that U is subject of St, Object(U; St) mean that U is the object of St, RDF T ype(U; C) mean that U rdf:type C and AssignAccess(U,A) mean that A is assigned to U .
The condition resource as subject is de ned as follows.
The condition resource as object is de ned as follows.
The condition class as subject is de ned as follows.
(
de nes the read and/or write privilege (de ned by the WAC), and it is de ned as:
AccessControl = fread,writeg: De nition 4: Access Space. An Access Space contains an access query that is executed to check whether a requester satis es speci c attributes. An access space can have multiple queries and therefore, it can be de ned as the set:
AccessSpace = faccessquery1,...,accessqueryng: 3.2
De nition 5: A Privacy Preference. A privacy preference is the set of all the sets Restrictions, Conditions, Access Control Privilege and Access Space and it is de ned as:
PrivacyPreference
[ AccessControl [ AccessSpace:
(
A privacy preference applies when requested information matches with the restricted statement(s), resource(s) and/or named graph(s). This is de ned as follows. Let St be a requested statement, R a requested resource, N G a requested named graph and P a privacy preference. Let ApplyP rivacyP ref erence(P ) mean that P is applied, Statement(St; P ) mean that St is a restricted statement in P , Resource(R; P ) mean that R is a restricted resource in P and N amedGraph(N G; P ) mean that N G is a restricted named graph in P . Then:
(
The relationship between restrictions and conditions consists of a mapping from restricted statements RS to condition statements CS, which this mapping is de ned as M : RestrictedStatements(RS) 7! ConditionStatements(CS). IF M = false THEN :ApplyPrivacyPreference(P).
However, there are situations where restrictions are not de ned but only conditions are de ned within a privacy preference. In this case, the mapping is performed between the RequestedInformation(RI) and the ConditionStatements(CS). This mapping is de ned as M : RequestedInformation(RI) 7! ConditionStatements(CS). IF M = true THEN ApplyPrivacyPrefence(P). Therefore, applying a privacy preference based on the mapping between restricted or requested statements and condition statements is de ned as: 8PM(P) ! ApplyPrivacyPreference(P).
The access space query Q is executed on the requester's authenticated information. IF AccessSpace(Q) = true THEN AccessControl(A) de ned in the privacy preference is granted to the requester. IF AccessSpace(Q) = false THEN the requester is :AccessControl(A). 4
This section presents MyPrivacyManager7, a privacy preference manager for the Social Semantic Web. It was developed to validate PPO and the formal model, i.e. to implement the creation of privacy preferences for RDF data described using PPO, and make sure the preferences are applied when requesting information, to lter requested data. Although MyPrivacyManager is designed to work with any Social Semantic Data8, we will focus on de ning privacy preferences for FOAF pro les. With FOAF pro les, our aim is to illustrate how the formal model can be applied to create privacy preferences and how personal information can be ltered based on such preferences.
Figure 2 illustrates the MyPrivacyManager architecture, which contains: (
MyPrivacyManager employs the federated approach whereby everyone has his/her own instance of MyPrivacyManager. As opposed to the majority of Social Web applications which are centralised environments whereby the companies o ering such services have the sole authority to control all user's data, this federated approach ensures that everyone is in control of their privacy preferences [1]. Moreover, users can deploy their instances of MyPrivacyManager on whichever server they prefer. 7 Screencast online { http://vmuss13.deri.ie/myprivacymanager/screencast/screencast.html 8 Consists of Social Web data formatted in RDF or any other structured format 9 ARC2 | http://arc.semsol.org 10 Although ARC2 was used for the implementation of MyPrivacyManager, any RDF store can be used.
The WebID protocol [12] provides a mechanism whereby users can authenticate using FOAF and SSL certi cates.
The WebID protocol implemented in MyPrivacyManager uses the libraries provided by foaf.me11 which calls the WebID authentication mechanism o ered by the FOAF+SSL Identity Provider Service12. This provides a secure delegated authentication service that returns back the WebID URI of the user which links to the FOAF document of the user signing in. If the identity service does not return back the WebID, then it means that the authentication has failed.
Once the user is authenticated, MyPrivacyManager matches the WebID URI with the WebID URI of the owner of that instance. If the owner is signed in, then the interface provides options where the user can create privacy preferences. On the other hand, if the user signed in is a requester, then the FOAF pro le of the owner of that particular instance is requested. The Privacy Preferences Enforcer module is called (described later in this section) to lter the FOAF pro le according to the privacy preferences speci ed by the owner of that instance. 4.2
MyPrivacyManager provides users an interface to create privacy preferences for
their Social Semantic Data. The interface displays (
The system provides pro le attributes (extracted from the user's pro le)
which the user can share classi ed as follows: (
The attributes, extracted from the FOAF pro le, which the user can select
which to whom to share information must have are categorised as follow: (
Once the user selects which information to share and to whom, he/she clicks on the save button for the system to generate automatically the privacy preference using PPO. Figure 4 illustrates an example of a privacy preference described using PPO and created from MyPrivacyManager that restricts access to a person's name and nick name to those users who are work colleagues. Although rei cation is used, we intend to use named graphs in order to reduce the number of statements. 4.3
MyPrivacyManager provides users to view other people's FOAF pro le based on privacy preferences by logging into third party's instance. On the contrary of common Social Networks which are public by default, MyPrivacyManager enforces a private by default policy. This means that if no privacy preferences are set for a pro le or for speci c information, then this is not granted access to be viewed. In the near future, MyPrivacyManager will be modi ed to provide a feature where users can select which default setting they wish to enforce { public or private.
The sequence in which privacy preferences are requested and enforced is
performed as illustrated in gure 5 which consists of: (
MyPrivacyManager handles each privacy preference separately since each preference may contain di erent access spaces. Once the system retrieves the privacy preferences, for each preference it tests the access space queries with the requester's FOAF pro le. If the access space query on the requester's FOAF pro le returns true, then the privacy preference is considered, however, if it returns false, then that particular privacy preference is ignored. Since the access space can contain more than one access query, in the case when one access query returns true and the other false, then by default the system enforces that the access space is true. The system then processes the restrictions and conditions de ned in the privacy preference.
The system will formulate the restrictions and conditions as a group graph pattern. This group graph pattern from each privacy preference will be used to create a SPARQL query and the result from this query will be the ltered FOAF pro le that can be accessed by the requester. The group graph pattern constructed from each privacy preference are combined using the keyword UNION within the same SPARQL query. Once the SPARQL queries are formalised, the access control privilege is assigned to the user. However, currently the system only accepts the acl:Read property since its purpose is to view the ltered FOAF documents of other users. 5
The Web Access Control (WAC) vocabulary13 describes access control privileges for RDF data. This vocabulary de nes the Read and Write access control privileges (for reading or updating data) as well as the Control privilege to grant access to modify the access control lists (ACL). This vocabulary is designed to specify access control to the full RDF document rather than specifying access control properties to speci c data contained within the RDF document. As pointed out in [9], the authors observe that protecting data does not merely mean granting access or not to the full RDF data but in most cases, users require more ne-grained privacy preferences that de ne access privileges to speci c data. Therefore, ne-grained privacy preferences applied to RDF data using our solution create a mechanism to lter and provide customised RDF data views that only show the speci c data which is granted access. 13 WAC | http://www.w3.org/ns/auth/acl
The authors in [8] propose a privacy preference formal model consisting of relationships between objects and subjects. Objects consist of resources and actions, whereas subjects are those roles that are allowed to perform the action on the resource. Since the privacy settings based on this formal model combine objects and actions together, this requires the user to de ne the same action each time with di erent objects rather than having actions separate from objects. Thus, this method results in de ning redundant privacy preferences. Moreover, the proposed formal model relies on specifying precisely who can access the resource. Our approach provides a more exible solution which requires the user to specify attributes which the requester must satisfy.
The authors in [3] propose an access control framework for Social Networks by specifying privacy rules using the Semantic Web Rule Language (SWRL) 14. This approach is also based on specifying who can access which resource. Moreover, this approach relies that the system contains a SWRL reasoner. In [5] the authors propose a relational based access control model called RelBac which provides a formal model based on relationships amongst communities and resources. This approach also requires to speci cally de ne who can access the resource(s).
In [11] the authors propose a method to direct messages, such as microblog posts in SMOB, to speci c users according to their online status. The authors also propose the idea of a SharingSpace which represents the persons or group of persons who can access the messages. The authors also describe that a SharingSpace can be a dynamic group constructed using a SPARQL CONSTRUCT query. However, the proposed ontology only allows relating the messages to a pre-constructed group.
In [7] the authors propose a system whereby users can set access control to RDF documents. The access controls are described using the Web Access Control vocabulary by specifying who can access which RDF document. Authentication to this system is achieved using the WebID protocol [12] which provides a secure connection to a user's personal information stored in a FOAF pro le [6]. This protocol uses FOAF+SSL techniques whereby a user provides a certi cate which contains a URL that denotes the user's FOAF pro le. The public key from the FOAF pro le and the public key contained in the certi cate which the user provides are matched to allow or disallow access. Our approach extends the Web Access Control vocabulary to provide more ne-grained access control to the data rather than to the whole RDF document. 6
In this paper we presented a formalisation of the PPO that can be used as a model whilst creating privacy preferences for any structured data. Since structured data can be used easily by other platforms taking advantage of Semantic Web technologies, privacy preferences described using the PPO can be utilised by 14 SWRL | http://www.w3.org/Submission/SWRL/ any system that implements the formal model. Moreover we presented MyPrivacyManager which implemented the formal model of PPO in order to demonstrate how to create privacy preferences for Social Semantic Data, primarily focusing on user pro les described using FOAF. MyPrivacyManager also demonstrates how data is ltered on the basis of these privacy preferences.
Similar to all prototype systems, further enhancements is required to enrich MyPrivacyManager. It will be extended to demonstrate how data from current Social Networks such as Facebook can be ltered based on privacy preferences de ned in PPO. Furthermore, since MyPrivacyManager assumes that the requester's information is trustworthy, the system will be extended to incorporate methodologies on how to assert the trustworthiness of requesters.