The web was born as a fundamentally open space. However, in the last few years, it has become a closed and controlled space, in contradiction to the purpose of its creation. Most web users today are limited to a dozen online social networks (OSNs) that hold their data and restrict their choices and interactions [1].

OSNs have experienced massive growth in popularity and have become one of the most used daily web applications. Platforms like Facebook, Twitter, and Instagram have changed how people communicate and interact [2]. They attract people with several free social services, like looking up new friends, creating relationships, sharing, and searching for content [3].

Verborgh affirms that social networks actively collaborate with the movement towards the centralization of information on the web, as they collect information from users with or without consent and store this in centralized databases, becoming a kind of data silo [4]. Therefore, OSNs are centralized and need a central authority that controls user profile data and others data [5,6].

Using OSNs gives users the false sense that they are in total control of their data despite the service providers having actual authority over their data [7]. According to Cutillo et al. [8], the fact that users in OSNs are usually linked to friends, family, and acquaintances leads to the belief that OSNs offer a more secure, private, and trusted Internet-mediated environment for online interaction.

Consequently, users must trust a third party to store and manage their data [9]. Unfortunately, the centralization aspect of OSNs has become a privacy issue among their users [10]. Service providers can use improperly collected personal and behavioral data from users [11]. They manipulate many users’ information (personal interests, social relationships, political opinions, and economic preferences) and can obtain insights about users [12].

According to Marcella and Stucki [13], privacy is the action an individual takes to establish boundaries over their private domain, controlling public access by adopting privacy requirements of their choice. Their private domain relates to their personal information, which is necessary to maintain control against unwanted access. In the context of decentralized online social networks (DOSNs), this involves implementing appropriate mechanisms for users to define granular access policies, ensuring that only specific parts of their information are accessible to certain groups or individuals.

Unfortunately, recent scandals, including the Cambridge Analytica data scandal¹, have proved that OSNs are unreliable and present vulnerabilities. Observing cases of privacy violations has become habitual, and the OSN service providers ignore these cases [12].

According to the literature, the main issues with OSNs are that: The third parties control the user’s data centrally [1,14]; users lack control over how their data is shared [11,12]; users lack control over which of their data is shared [12,15]. The last issue mentioned is particularly crucial when we need to ensure a high level of granularity in providing privacy. Several works [16,17] found in the literature have proposed methods, ontologies, and implementations to provide privacy for web application content. Some of these works [16–18] are for privacy in generic domains such as content management system or web services. Moreover, some [19,20] provide privacy for the specific domain of OSNs. However, none of these works address the issue of applying privacy to data with high levels of granularity.

Therefore, decentralized solutions have been explored to address the OSNs issues [21,22]. Much research about Web decentralization and DOSN has been developed, such as Solid [23], Musubi [24], WebBox [25], and Diáspora [26]. Indeed, in the DOSNs’ context, some privacy issues are overcome due to their decentralized aspect but leverage others. In this way, DOSNs solve the problem of centralization and give the users control over their data [5]. However, the task of controlling data sharing is complex for end-users, especially if the level of data granularity is high [27]. Proposals such as web access control (WAC) and access control list (ACL) enable the definition of access control policies (ACP) with a lower level of granularity. For example, WAC is designed to restrict access to entire documents rather than specific data. Therefore, a user aiming to limit access to particular information in their friend of a friend (FOAF) profile document would encounter difficulties with this technology [28].

In this article, we present a privacy solution for DOSNs related to the problem of data sharing with a high level of granularity. We propose a privacy approach incorporating an ontological model based on semantic rules and a service that consumes this model and enforces fine-grained access control about the data. Our approach uses the Solid ecosystem as a personal data store (PDS) implementation, providing a decentralized environment for DOSNs composed of a personal online datastore (POD) container where the model will be stored. PDS exemplifies a technological effort to enhance users’ data control. This user-centric approach serves as a private data repository, addressing both user data control and privacy issues using a decentralized data processing method. PDS represents a paradigm shift in the relationship between citizens and service providers, placing individuals at the forefront. This decentralization underscores the importance of user choice, giving individuals the authority to determine the destiny of their data [1]. This approach is DOSN-PRIV: Model and services for privacy in DOSNs.

This section provides an overview of current privacy control solutions related to our proposal. The criteria use to compare related works with our proposal are presented in Table 1. In Table 2, the related works are compared with the solution proposed in this work, and through the results of the comparison criteria, it is possible to observe that there were different access control proposals for various domains. One of the proposals uses the strategy of using semantic web rule language (SWRL) rules, and several others make use of ontologies. However, the approach proposed by our research focuses on building an ontological privacy model for DOSNs, using SWRL rules, and additionally proposes a privacy support service that uses the model and rules to enable access control with a high level of granularity to data in DOSN environments.

Jiang and Zhang [29] proposed blockchain-based decentralized online social network (BCOSN), a framework leveraging blockchain technology to address user privacy in DOSNs. The framework tackles privacy leakage by separating access control and data storage services. It utilizes smart contracts for access control and identity management, while encrypted data is stored in a distributed storage service.

Belchior et al. [30] proposed self-sovereign identity-based access control (SSIBAC), which incorporates conventional access control models and blockchain. The authors’ proposal differs from ours in that we propose improvements in access control to DOSNs through a model and a privacy support service. Rahman et al. [31] proposed a context-aware access control framework for DOSNs using blockchain technology to define privacy policies. They implement ACLs through a set of smart contracts, specifically, the access control contract for controlling access to network resources, the reputation contract (RC) for establishing a trustworthy system, and the inspector contract (IC) for inspecting user behavior. These contracts are employed to define fine-grained access control to resources.

Esteves et al. [27] present an extension of Solid’s ACL with additional functionality to enforce an individual’s data-sharing preferences. They focus on three points, i.e., legal compliance, user-defined preferences for data sharing and use, and transparency of data practices. Once ACL cannot specify complex rules, permissions, and prohibitions policies over the resources, they create an open digital rights language (ODRL) profile is created using data privacy vocabulary (DPV) to overcome these issues. They extended the ACL with ODRL, allowing it to express permissions and prohibitions in granular (broad or fine-grained) policies and utilize DPV to reach data protection and privacy concepts. In our work, we used SWRL-based rules to achieve granular privacy policies.

Abid and Daud [32] aimed to address issues related to the sharing of resources. Therefore, they proposed a dynamic and fine-grained privacy-aware access control model in OSNs to enhance the privacy of text-based resources. They employed parsing and natural language processing, along with identity access-control manager and clustering algorithms, to dynamically select a specific set of users relevant to the resource and create rules/policies.

Braun and Käfer [33] proposed attribute-based access control in a Solid POD using verifiable credentials (VCs). At the same time, the authors proposed the Boneh, Boyen e Shacham (BBS+) signature scheme, a secure, multi-message digital signature protocol, to reveal only attributes needed for authentication and authorization. In our work, controlling access to resources in a Solid POD is managed through a model and service for privacy by using SWRL rules.

Tama and Wicaksana [34] conducted a performance evaluation of DSON built on blockchain technology. The study identified a key limitation: The necessity for a blockchain specifically designed to accommodate the unique demands of social media platforms. Their findings suggest that integrating both on-chain and off-chain storage solutions enhances the performance of decentralized social media applications by reducing response time.

DOSN-PRIV is our proposal for using an ontological model and a service to provide users with privacy in high granularity in the context of DOSNs. This proposal is based on five requirements, which we present in subsection 3.1. In addition, we describe the architecture for DOSN-PRIV, comprising the model and service, in subsection 3.2. We also describe the ontological model and privacy service in subsections 3.4 and 3.5, respectively. Finally, subsection 3.3 presents the concept of POD and how it is used to store the DOSN-PRIV model.

We developed DOSN-PRIV, taking into account the requirements shown in Table 3. These requirements were based on the works proposed by Gates [35], Carminati and Ferrari [36], Raji et al. [37], Sayaf and Clarke [38], and Capadisli et al. [39]. In the R1 requirement (Table 3), a user can manage the access control to a resource based on its relationship with the requester user. For example, only relatives can access a family album or only coworkers can access information about the job location. The R2 requirement (Table 3) focuses on guaranteeing that a user can grant or block access, for example, to specific information about its profile, a picture, or a post. With the following requirement (R3 in Table 3), a user can flexibly grant access to a user or group of users. For example, it is possible to give access to a user’s birthday or address to a group of family member, but a specific friend outside that group can also access it. Using the R4 requirement (Table 3), users can remove friends from any group and add them to another. Access control must take into account the dynamism of social relationships. For example, if two users are friends from high school, they belong to a high school group. They become part of a university group when they change to a university. Finally, with the R5 requirement (R5 in Table 3), users can choose where their data will be stored and maintain complete control over it. For example, they can define who is allowed to access it.

These requirements cover a broad range of privacy needs, focusing on fine-grained control and user autonomy including usability, default privacy settings, and even transparency. In addition, they are essential as they empower users to control their data, which is a significant concern in OSNs. However, many users may not want to engage deeply with privacy settings. In this case, we can take some solutions, for example, 1) implementing default privacy settings so that the data can be protected without requiring user intervention; 2) showing a preset privacy options (e.g. public, friends only, and private), making the privacy management easier; 3) reminding users periodically to review and adjust their privacy settings as needed.

The privacy concept is about the right of individuals to handle their data. To address this, we designed an architecture (Fig. 1) incorporating an ontological model based on rules and a privacy service permitting fine-grained ACPs.

Fig. 1 depicts our privacy architecture proposal, which is composed of three layers: Client, DOSN-PRIV, and POD. In this context, clients perform requests to the DOSN-PRIV service, which realizes the intermediation between the client and the user’s resources stored on its POD. Finally, using the DOSN-PRIV model, POD controls access (granting permission or blocking) to the user’s resources.

We implemented all components of the architecture presented in Fig. 1 and used the implementation to realize the evaluations described in Section 4. The DOSN-PRIV model was serialized as a web ontology language (OWL) [40] ontology as described in subsection 3.4 and stored in POD, which is implemented as described in subsection 3.3. DOSN-PRIV service was developed as a web service as described in subsection 3.5.

As part of the DOSN-PRIV architecture (see Fig. 1) proposed in this work, we used the POD infrastructure provided by Solidcommunity.net². This infrastructure is a prototype implementation of a Solid server [41].

Solid is a linked data principles-based approach that consists of open standards, protocols, and conventions for creating a decentralized social network environment. Solid borrows the semantic web technologies, and according to Sambra et al. [41], Solid applications run as client-side web applications and store their data in PODs.

PODs are decentralized personal storage spaces where the owner controls the creation, editing, and data control management. PODs are a type of PDSs, and users can choose to host their server or obtain a POD from a specific provider (e.g., Solid Community³ or Inrupt⁴). Users can have as many PODs as they want and easily switch between them. Solid applications might communicate with any POD server, independent of service, provider, or location [41].

As shown in Fig. 2, an essential feature of POD servers is that they must support resource description framework (RDF) and non-RDF resource storage (resource storage in Fig. 2) and allow primary linked data platform (LDP) access to resources. In Fig. 2, LDP is a Linked Data specification that defines a set of rules for building HTTP services capable of reading and writing RDF data. PODs also use an ACL (see Fig. 2) to control access to stored data and can optionally accept SPARQL for data retrieval.

Solid uses web identifier (WebID) for authentication and digital identification of end users. A WebID profile is an RDF document that describes its owner and is usually stored on a POD server. This document contains RDF triples with internationalized resource identifier (IRI) to identify the subject linked to the profile document [42].

Different PODs providers can provide the necessary infrastructure for hosting and managing PODs. Consequently, users are allowed to choose their POD providers and switch between providers whenever they want [43]. In this work, SOLID provides all aspects of a decentralized social network we need for our DOSN-PRIV proposal. In addition, the SOLID prototype implementation also provides for our DOSN-PRIV architecture all means for storage and query over our proposed DOSN-PRIV model in subsection 3.4. To use the Solid prototype implementation, we have integrated it into our DOSN-PRIV architecture and its implementation by using web services as described in subsection 3.5.

To develop the DOSN-PRIV model, we used the ontology development methodology proposed by Noy and McGuinness [44], and we serialized the model as an OWL ontology. This methodology represents a simple, iterative, user-friendly guide to developing ontologies. It is composed of seven steps: 1) determining the domain and scope of the ontology; 2) considering reusing existing ontologies; 3) enumerating essential terms in the ontology; 4) defining the classes and the class hierarchy; 5) defining the properties of classes-slots; 6) defining the facets of the slots; 7) creating instances.

Considering that the DOSN-PRIV model is a privacy ontology in the context of a decentralized social network, in the first step, we elicited the privacy requirements used in the model development, as depicted in subsection 3.1.

In the second step, we reused some ontologies related to the proposed domain. Consequently, among other benefits, we reduced the processing cost and the memory needed for the privacy support service to make inferences using the model. In this sense, the reused ontologies were FOAF [45], vCard [46], iContact [47], Relationship [48], and semantically-interlinked online communities (SIOC) [49].

In the third step, we enumerated essential terms in the ontology necessary to build our DOSN-PRIV model, such as access, permission, read, write, share, post, and personal profile document. Next, we created new terms in the ontology linked to access control and DOSN. Thus, we added thirteen classes, seven object properties, and five data properties, as seen in Table 4.

The following steps relate to the model implementation and imply the definition of classes, hierarchy, properties, and restrictions. Figs. 3 and 4 represent the proposed model, and it is possible to observe its classes, data properties, and object properties.

We formalized the DOSN-PRIV model through an OWL ontology and used SWRL rules to define fine-grained ACPs. This way, DOSN’s users can specify their privacy preferences using SWRL. Besides that, the DOSN-PRIV model uses the namespace prefix dosn-priv to abbreviate the uniform resource identifier (URI) of the model.

We separated the DOSN-PRIV model into two pieces for better visualization: One refers to the access control (Fig. 3) and another refers to DOSN (Fig. 4). Moreover, for a better interpretation, we use the following legend: Rectangles represent classes, circles represent data types, dashed arrows interconnecting rectangles indicate subclasses, solid arrows between rectangles represent object properties, and solid arrows from rectangles to a circle represent data properties.

We also use colors to identify whether classes are new or reused from other ontologies. Green rectangles represent FOAF inherited classes. Orange rectangles represent SIOC inherited classes. Pink rectangles represent vCard inherited classes. Purple rectangles represent iContact inherited classes. Finally, blue rectangles represent new terms we created for DOSN-PRIV.

In the following, we detail some classes and properties as shown in Fig. 3 for a better understanding. The dosn-priv:Permission represents the possible user permissions types. It has three subclasses: dosn-priv:Read, dosn-priv:Write, and dosn-priv:Share. The class dosn-priv:Access represents the access type to resources. It has three subclasses dosn-priv:Private, dosn-priv:Controlled, and dosn-priv:Public. The object property dosn-priv:permissionType is responsible for creating a relationship between foaf:Agent and dosn-priv:Permission classes. The (foaf:Agent, dosn-priv:permissionType, dosn-priv:Read) triple allows the user to access the resources for reading. This same triple can be formed using dosn-priv:Write or dosn-priv:Share, giving the user access to the resources for writing or sharing, respectively. The object property dosn-priv:accessType relates owl:Thing (representing things or resources) to the dosn-priv:Access class. An owl:Thing is accessible only by its creator when the dosn-priv:accessType is set to dosn-priv:Private. On the other hand, everyone can access the owl:Thing when setting dosn-priv:accessType to dosn-priv:Public. Finally, it is possible to set dosn-priv:accessType to dosn-priv:Protected. In this case, an owl:Thing is accessible in a controlled manner according to ACP defined by the creator. The object property dosn-priv:permissionOn allows the creation of an association between foaf:Agent and owl:Thing instances. Finally, the data property dosn-priv: permissionRead defines what specific information fragment the user can read.

In Fig. 4, we present the classes and properties of the complete DOSN model, structured according to their respective vocabularies in the following. The FOAF vocabulary includes several key classes. The foaf:Person class represents an individual, with data properties such as foaf: firstName, foaf:lastName, and foaf:surname for name identification. The foaf:knows object property establishes relationships with other foaf:Person instances, while additional relationships can be defined through properties like rel:childOf, rel:closeFriendOf, rel:collegeOf, rel:engagedOf, rel:friendOf, rel:grandChildOf, rel:grandParentOf, rel:parentOf, rel:siblings, rel:spouseOf, and rel:worksWith. The foaf:Organization class represents entities such as companies or societies, identified by the vcard:organization-name data property. The foaf:Agent class acts as a more general entity, encompassing both foaf:Person and foaf:Organization, and includes properties like foaf:birthday (for the agent’s birthday), con:preferredURI (for WebID), and ic:hasMail (for the agent’s email). Other FOAF-related classes include foaf:Group, representing a collection of foaf:Agent entities with common interests, and foaf:PersonalProfileDocument, which links to a foaf:Agent through the foaf:primaryTopic property. Other important properties include con:preferredURI, which refers to a URI for a person or organization, and foaf:birthday, which represents the birthday of a foaf:Agent.

The SIOC vocabulary is also crucial for the DOSN model. The sioc:UserAccount class represents a user’s account in an online community, linked to its owning foaf:Agent through the foaf:account and sioc:account_of properties, with the account name specified by foaf:accountName. The sioc:ImageGallery class describes an image gallery, where photos are linked using the triple (sioc:ImageGallery, dcterms:hasPart, dosn-priv:Photo). The sioc:follows property indicates that one sioc:UserAccount follows another, while sioc:likes is used to indicate endorsement of a dosn-priv:Post. The sioc:sharedBy property represents a sioc:Post shared by a sioc:UserAccount.

The vCard and IC vocabularies provide additional classes and properties. The vcard:Address class models physical addresses, linking a foaf:Agent to an address via the vcard:hasAddress property, with details such as vcard:street-address, vcard:country-name, vcard:postal-code, vcard:locality, and vcard:region used to describe the address. The vcard:Gender class models gender, with subclasses like vcard:Male, vcard:Female, and vcard:Unknown, and uses the vcard:hasGender property to relate gender to entities, such as (foaf:Person, vcard:hasGender, vcard:Female). The ic:PhoneNumber class represents phone numbers, with subclasses for cell (ic:CellNumber), home (ic:HomeNumber), and work numbers (ic:WorkNumber), and properties like ic:hasPhoneNumber, ic:hasAreaCode, and ic:hasCountryCode to specify phone details.

Finally, within the DOSN-PRIV namespace, the dosn-priv:Post class defines a social media post, which can include content such as videos (dosn-priv:Video subclass), text (dosn-priv:Note subclass), or photographs (dosnpriv:Photo subclass). Key properties of this class include dosn-priv:id (a unique identifier), dosn-priv:createdDateTime (the creation date and time), and dosn-priv:message (the content of the post). The dosn-priv:Page class represents a page associated with a sioc:UserAccount in a social network, linked through the dosn-priv:hasPage property, with dosn-priv:holds indicating that the page contains posts. Properties like dosn-priv:hasComment and dosn-priv:numComment are used to refer to and count comments on a dosn-priv:Post.

In this subsection, we describe the DOSN-PRIV service. It is part of the privacy architecture proposal presented here. The service is available on the web and accessible through HTTP requests. Its primary role is to intercept resource requests sent to users’ PODs and then grant access following privacy policies defined by POD’s owner based on the DOSN-PRIV model.

Users can request resources from others through endpoints made available by the DOSN-PRIV service. Fig. 5 presents the DOSN-PRIV service architecture, composed of four components: Communication, interpreter, inference engine, and query engine.

The communication component is responsible for the communication between the DOSN-PRIV service and the client application (steps 1 and 5 in Fig. 5), the user’s POD (step 2 in Fig. 5), and internal components of the architecture (steps 3 and 4 in Fig. 5). DOSN-PRIV and client applications communicate through HTTP requests to available endpoints. The communication with POD happens through HTTP requests from DOSN-PRIV to the user’s POD. In turn, the communication between internal components occurs through object instantiation and method calls. The interpreter obtains the DOSN-PRIV model through the communication component, converting it into a Java object.

The inference engine component is responsible for inferring new knowledge based on user access policies. It uses the Openllet, an OWL 2 reasoner in Java, built on top of Pellet [50], that receives the model generated by the interpreter component and returns it with new inferred knowledge (step 3 in Fig. 5).

At last, the component query engine receives the model containing the data inferred by the inference engine (step 4 in Fig. 5), performs SPARQL queries on the model, and returns the obtained data to the requester (step 5 in Fig. 5).

We used the following technologies in the DOSN-PRIV service development: Java 8⁵, Spring Boot⁶, Apache Jena⁷, and Openllet⁸. Spring Boot is part of the Spring Framework that facilitates building RESTful APIs. Apache Jena is a free and open-source framework for building semantic web and linked data applications. Finally, the Openllet is an OWL description logic (DL) reasoner.

Algorithm 1 describes the access control process executed by the DOSN-PRIV service in response to the request made by the client application. The client realizes the request to the service and sends the user’s WebID as a parameter. DOSN-PRIV service loads the data owner POD’s DOSN-PRIV model and uses the inference engine to infer new knowledge based on the policies declared in that model. From that moment on, the service, using the received WebID, performs a SPARQL query on the model to verify the requestor access rights. Finally, the client gets the right to access data in compliance with the privacy policies defined by the data owners.ners.

We chose our evaluation method based on the features and limitations of our initial prototype. While our prototype lacks some advanced functionalities in mature systems, we designed the evaluation method to rigorously test and validate key aspects of the proposed model under controlled conditions. This approach allows us to focus on performance metrics essential for real-world service implementations and assess the ontology’s effectiveness in performing specific tasks. Although the prototype’s limitations constrain our ability to simulate real-world environments, we remain confident in our method. Moving forward, we plan to expand our evaluation to include cases that are more practical and gather feedback from a broader audience to validate further and enhance our approach.

In this section, we present the two approaches used to evaluate the DOSN-PRIV model and the DOSN-PRIV service, as well as the methods and tools used in these evaluations. In addition, we discuss the results of each evaluation.

In this evaluation, we adopted the task-based approach proposed by Porzel and Malaka [51]. According to the authors, this approach assesses the effectiveness of an ontology in performing specific tasks.

To evaluate the ontological model in this approach, we designed a privacy-supported DOSN scenario. Consequently, the model was loaded with user profiles and post data, along with a specific set of SWRL rules responsible for restricting or authorizing access to data.

In DOSNs, users control their data and are responsible for declaring SWRL rules that represent their privacy preferences. Therefore, appropriate tools are needed to view and edit such rules. Several works in the literature have proposed tools to view and edit SWRL and rules [52–54]. It is beyond the scope of this work to develop tools for viewing and editing SWRL rules.

Fig. 6 depicts the modeling of the DOSN scenario developed for this evaluation stage. We use the Solid ecosystem structure as POD for storing the DOSN-PRIV model. In addition, we employed the DOSN-PRIV service to consume the model held in POD and apply the access control rules. Based on the modeling of the DOSN scenario, as presented in Fig. 6, access control rules were applied to assess the model’s compliance with the privacy requirements presented in Table 3. Below, we present the access control rules applied in this evaluation and the results obtained.

Access control 1 (see Fig. 7) : Person1 only permits your friends to access his data. This access control comprises Rules 1 and 2 (Listings 1 and 2). Rule 1 indicates a friendship relationship between Person1 and another individual (p). Person1 controlls access to his address1. This implies that individual p has permission to access address1. Rule 2 defines the components of address1 and their specific access permissions. Finally, in Listing 3, we find the response (Answer 1) to our rules.

Access control 2 (see Fig. 8): Person1 grants Person3 access to data from his profile (Listing 4). Specifically, the first-name (Listing 5) and country-name (Listings 6 and 7). From these rules, we received the Answer 2 (Listing 8). Finally, with Rules 7 and 8 (Listings 9 and 10), Person1 grants Person2 access to the post2. Applying these rules, we received the Answer 3 (Listing 11).

Access control 3 (see Fig. 9): Person1 only permits members of the Family group (Listing 12 and 13) and Person4 to access his photos (Listings 15 and 16). Applying Rules 12 and 13, we received the Answer 4 (Listing 14), and applying Rules 15 and 16, we received the Answer 5 (Listing 17).

Access control 4 (see Fig. 10): Person1 permits members of the University group to access freshman photos (Rule 13 on Listing 18). Person1 removes Person4 from the HighSchool group and adds him to the University group (Rule 14 on Listing 19).

In Fig. 10, the application of Rules 13 and 14 (Listings 18 and 19) results in presenting freshman photos exclusively to members of the University group, as we can see in Answer 6 (Listing 20). In addition, we create three SPARQL queries (Query 1, Query 2, and Query 3) to demonstrate the scenario where Person1 removes one of the members from the HighSchool group (Person4) and adds him to the University group as shown in Figs. 11–13. This action grants Person4 access to the freshman’s photos.

As shown in Fig. 11, Query 1 (see Listing 21) returns the list (see Query Answer 1 in Listing 22) of members and groups in which Person4 appears as a member of the HighSchool group. According to the DOSN-PRIV model, the object property foaf:member must be used to move an individual from one group to another. In this case, Person1 removed Person4 from the HighSchool group and added him to the University group.

As shown in Fig. 12, Query 2 (see Listing 23) returns the list (see Query Answer 2 in Listing 24) of all members of the HighSchool group. In Query Answer 2 (Listing 24), Person4 is no longer a member of the HighSchool group. Finally, as depicted in Fig. 13, Query 3 (see Listing 25) returns all members (see Query Answer 3 in Listing 26) of the University group. In Query Answer 3 (Listing 26), Person4 is now a member of the University group.

According to the task-based approach, the evaluation results of the DOSN-PRIV model indicate compliance with the requirements outlined in Table 3. By applying access control scenario 1, we demonstrated that the privacy requirement R1 was satisfied. The model and the SWRL rules effectively controlled access based on the relationship. In the specific access control scenario under consideration, Person1 defined that only people with a friendship relationship (rel:friendOf) had access to their address data. Therefore, the DOSN-PRIV model met requirement R1 by ensuring access control based on relationships.

By applying access control scenario 2, we demonstrated that the DOSN-PRIV model met the requirement R2. This requirement matching was achieved through rules demonstrating ACPs with a high level of granularity. Rules 3–6 grant access to Person3 to specific data from Person1’s profile: first name (firstName) and country (country-name). Rules 7 and 8 are responsible for granting Person2 access to Person1’s Post2. In this sense, by allowing access control with high granularity in both cases, the DOSN-PRIV model satisfied the R2 specification.

With access control scenario 3 (Rules 9–12), we demonstrated that the privacy requirement R3 has been satisfied. This requirement satisfaction proves the model’s flexibility because it allows Person4, who is not part of the Family group, to access Person1’s photos (photo1.jpg, photo2.jpg, and photo3.jpg). In other words, through the rules defined by Person1, members of the Family group and Person4 had access to their photos.

In access control scenario 4 (Rules 13 and 14 and SPARQL queries 1–3), we demonstrated the DOSN-PRIV ontological model’s capability to handle the dynamics of social relations in DOSNs. The defined rules specify that members of the University group should only have access to the freshman’s photos. Consequently, when executing Query 1, it was observed that initially, Person4 lost access to the photos because he was not part of the University group but rather the HighSchool group.

In turn, the SPARQL query 2 returned all members of the HighSchool group (in this case, returning only Person6), demonstrating that Person1 had removed Person4 from that group. Subsequently, the SPARQL query 3 retrieved all the members of the University group, revealing the presence of Person4. By following the dynamics of the relationship between Person1 and Person4, where Person 4 could be removed from the HighSchool group and added to the University group, it becomes evident that the DOSN-PRIV model satisfied the R4 privacy requirement.

The R5 privacy requirement concerns the user’s freedom of choice, the location of data storage, and their right to maintain control over them. This issue is addressed by the architecture of DOSNs, as PODs, according to Ref. [41], are storage services accessible through the web and can be hosted by the users or obtained from pod providers.

In this way, the user can maintain control over his data, including applying a high granularity access control, using the privacy architecture presented in subsection 3.2. According to this architecture, the DOSN-PRIV model and its access control rules are stored in the user’s Pod. Thus, the model complies with requirement R5. It allows users to choose how to store their data and enables them to maintain control over their data.

We evaluated the DOSN-PRIV service with a performance evaluation presented in subsection 4.2.1. The performance was measured regarding the response time to the requests realized during our service implementation.

To evaluate the DOSN-PRIV service, experiments were carried out using the JMeter tool. JMeter is an open source software designed for load testing and performance measurement of web applications. The machine used to execute the requests in JMeter was a computer with 8 GB of RAM memory, a 2.0 GHz core i7 processor, and a Linux Mint 18 operating system.

For these experiments, the DOSN-PRIV service was hosted in the cloud on platform as a service (PaaS) Heroku10, which is PaaS with a managed container system with integrated data services, making it a powerful ecosystem for deploying and running applications. In addition, we use the Solid ecosystem structure (see subsection 3.3), creating a decentralized environment for DOSNs and providing the POD structure within which the DOSN-PRIV ontological model was maintained for consumption by the DOSN-PRIV service.

After deploying the DOSN-PRIV service in the cloud and the DOSN-PRIV model in the Solid POD, we conducted experiments to evaluate the behavior of the response time to requests with varied workloads obtained from the combination of different factors and levels. For this, we selected factors and levels considered necessary for evaluating web services related to access control and privacy in the domain of DOSNs. Such factors and levels are represented in Table 5.

The experiments analyzed the interaction between different factors and levels, with ten replications being performed for each experiment and having the response time of requests as the target variable. The first experiment evaluated the service’s response time for the number of policies and requests. This experiment followed the following configurations: The number of policies (2 and 4) and the number of requests (25, 50, 75, and 100).

The second experiment evaluated the response time regarding the number of privacy parameters and the number of requests. For this, the following configurations were used: The number of parameters (10 and 20) and the number of requests (25, 50, 75, and 100). For the factor number of parameters with a level equal to 10, the following parameters were used: ?person, person1, address1, Controlled, Read, and ?countryName. For the parameter quantity factor with a level equal to 20, the previous parameters were used, and additionally: cell-Number1, ?countryCode, ?areaCode, ?phoneNumber, ?streetAddress, ?locality, and ?postalCode.

Given that some of the parameters presented were used more than once in the privacy policies selected for this experiment, we chose to inform each one only once, as we believe it is unnecessary to repeat the information.

The results obtained from the DOSN-PRIV service evaluation experiments, as presented in subsection 4.2.1, demonstrate the time the service took to grant access with a high level of granularity to the user’s data. These findings are significant, considering that they are the bases for evaluating the response time behavior of the service regarding the ability to scale when subjected to different workloads.

The initial evaluation of the DOSN-PRIV service focused on measuring its response time about the number of privacy policies. The result presented in Fig. 14 indicates that the response time of the DOSN-PRIV service increases with the number of privacy policies. We observed this increase across all levels of the request factor. However, it follows a linear growth pattern, demonstrating that the response time scales satisfactorily when subjected to the increased workloads. In this sense, the response time behavior of the DOSN-PRIV service is considered acceptable.

Fig. 15 presents the results of evaluating response time when considering the number of the parameters contained in privacy policies and the number of requests. We observed an increase in the response time as the levels of these factors increased. This behavior was expected, given that a more significant number of parameters in the privacy policy increases complexity, thus impacting the response time. However, we observed a linear growth trend in the response time. This linear behavior demonstrates that the service’s response time is satisfactorily scaled when subjected to the increased workload defined by the number of requests and policies. Therefore, the response time behavior of the DOSN-PRIV service is considered satisfactory.

Section 2 presents some related works we found in the literature related to data access control focusing on privacy issues. Here, we compare these related works with our work regarding how each work implements and evaluates access controls for privacy aspects. Subsection 4.3.1 provides detailed discussion of the similarities and differences between our work and the related studies. Subsection 4.3.2 evaluates the response time of our approach compared to the blockchain-based methods presented in the literature.

Rahman et al. [31] proposed an access control system using smart contracts. Their framework is composed of the access control contract which controls access to resources in the network, RC which provides a trustworthy system, and IC which inspects user behavior. Therefore, all actions performed by a user are publicly visible on the blockchain. Our work uses an ontological model to perform the access control task, and all actions are stored in the individual’s Pods, accessible only by an authorized agent.

Esteves et al. [27] proposed a Solid ACL extension using ODRL to specify and enforce an individual’s data sharing preferences. They created an ODRL profile using data privacy vocabularies (DPV), allowing users to define more complex permission rules and providing fine-grained access control. They presented a Pod architecture as an extension to the Solid Pod specification, proposing the addition of a consent data store component to keep a record of the consent actions already given. In our case, we propose an ontological model to manage the permission process and keep the consent already given semantically attached to the shared information.

Abid and Daud [32] proposed a dynamic and automated access control system in OSN for textual resources and publications. The authorizations are based on the clusters of user interest. The rules check if users are in the same clusters or if there are any family or ownership relationships. Our approach is similar to Abid and Daud’s work as we provide the GROUP entity so that users can be members of it, thus representing that they share the same interests. In addition, as shown in the DOSN Scenario Modeling, we explicitly present a Group Family, which can be considered for one to develop rules in this concern.

Finally, Braun and Käfer [33] used VCs as one potential component for attribute-based authentication and authorization on Solid Pods. The authors, however, did not provide details on how these attributes are disclosed and the rules behind them. The authors claimed that ACPs must be implemented, but there are no details on how the policies are defined and who can define them. Unlike Braun and Käfer’s work, we provide ACPs and the classes and properties for DOSN so that any other DOSN-based application can benefit from it.

Balancing privacy with system performance, particularly response time, in decentralized social networks is challenging. Blockchain-based methods are known for their robust security and decentralized structure. When comparing these methods to our proposed semantic model, the data reveals that our approach exhibits a higher response time.

Table 6 compares our proposed method with some blockchain-based methods from the literature and includes three columns that facilitate the comparison of the response time across different methods. The functionality column describes the action or task being evaluated for the response time, such as updating a post or requesting access. The ten-attributes column indicates that the comparison has been normalized using ten attributes for all methods, as each method evaluated its main functionality using at least ten attributes, ensuring a consistent basis for comparison. Lastly, the average response time (ms) column presents the average response time in milliseconds, reflecting how efficiently each method performs the specified functionality per ten attributes.

In Table 6, Belchior et al. [30] is the only one not focused on social networks but was included because it evaluates access credential requests with a focus on privacy. Its inclusion is particularly valuable as it compares with a different use case scenario, providing broader insights into the performance of our approach across diverse applications.

Jiang and Zhang [29] evaluated the performance of the event mechanism by establishing some social graphs and measuring the time from when a user updates a post to when their friends receive notifications. As a result, they found an average response time of 335 ms when updating a post that notified ten users (friends).

Belchior et al. [30] measured the process’s latency. They divided the process into three phases: Startup, comprising the time necessary to set up the infrastructure to perform access control; connect, comprising the steps of connecting the agents, exchanging credentials, and preparing the environment; access control, properly speaking. Consequently, their work performs access requests for ten credentials with an average response time of 339 ms.

Tama and Wicaksana [34] measured the response time of the smart contract and found it to be 586 ms when posting a text with ten words. They attributed the delay to multiple factors, including network congestion on the blockchain, the number of validators, and the Internet connection speed.

In summary, our method has an average of 760 ms in the response time, slower than the blockchain approaches, such as those by Jiang and Zhang [29] at 335 ms, Belchior et al. [30] at 339 ms, and Tama and Wicaksana [34] at 586 ms. Therefore, comparing the response time with blockchain methods is essential to illustrate where our approach stands and to highlight the trade-offs between security, privacy, and efficiency in decentralized social networks.

Finally, although the response time of our semantic model-based approach is higher than that of blockchain-based proposals, it can provide a flexible framework for privacy management, enabling more granular and dynamic control over privacy policies based on the specific semantics of user interactions and data. This adaptability allows for a refined approach to privacy, as it can consider the relationships between different data elements, which blockchain-based systems, with their rigid structures and immutability, might struggle to accommodate.

Because the DOSN-PRIV model and service and its implementation presented in this article are based on ontologies and web services, both model and service can be reused for the development of privacy systems or applications in two ways: i) They can be reused entirely to create new systems in different domains than the case presented in this article; ii) they can be partially reused through reusing parts of the proposed model and service.

The key strength of DOSN-PRIV is that it offers a simple model that captures the main data aspects relevant to a decentralized social network. Therefore, other researchers could use the model in works related to DOSN or even OSN. The model can be entirely reused to implement high-granularity privacy for a decentralized social network. Alternatively, part of the model can be reused only with the main aspects relevant to a decentralized social network, i.e., without the privacy terms.

Since we used semantic web standards, OWL, and SWL in our model, creating a new version of the DOSN-PRIV model with some or several pre-defined SWRL rules embedded into the model is simple. By doing that, the DOSN application, which reuses our model, will also inherit the pre-defined rules and can modify these rules or easily create new rules.

The DOSN-PRIV service can be reused to create new DOSN applications relying on the DOSN-PRIV model and guaranteeing fine-granted privacy to the application’s users. These applications may be an entire DOSN created from scratch, but they can also be an existing DOSN integrated with our privacy proposal using the DOSN-PRIV service. Another application that may be integrated with the DOSN-PRIV service is one for the graphical generation of SWRL rules. This application can use our service to facilitate the task of creating rules for the user or a DOSN application developer.

Finally, with some changes, the DOSN-PRIV service can provide privacy for generic applications, such as non-DOSN applications. To do that, the DOSN-PRIV service should be simplified to use only the class access control and privacy (see Fig. 3) of the DOSN-PRIV model.

Our proposal explores the privacy challenges in OSNs and proposes a decentralized solution for enhancing user control over their data. While our focus has been on centralization issues and fine-grained access control, it is essential to consider additional aspects of data privacy, such as data value, usage, and time. These dimensions provide a more comprehensive understanding of privacy and its implications.

The data value refers to the significance or worth of user information. In the context of OSNs, user data is sensitive, as it drives the platforms’ business models through targeted advertising and personalized services. Understanding the value of data can help assess the risks and benefits associated with data sharing. Our proposed decentralized solution, DOSN-PRIV, allows users to control their valuable data, ensuring that only specific parts of their information are accessible to particular groups or individuals. This granular control is essential in protecting data with a higher intrinsic value.

In the context of this work, data usage pertains to how service providers utilize collected data. Service providers may use data for various purposes, including marketing, analytics, and sharing with the third parties. Transparent data usage policies are critical to maintaining user trust. Our privacy approach integrates an ontological model (DOSN-PRIV) based on semantic rules, which enforces fine-grained access control and ensures that data usage is aligned with user-defined policies. This alignment helps in preventing misuse and unauthorized access to user data.

Data time involves the temporal aspects of data storage and usage. This includes how long data is stored, the relevance of data over time, and the policies for data deletion. In OSNs, data can be retained indefinitely, posing long-term privacy risks. In addition, data that was once relevant may become obsolete or sensitive over time. Therefore, mechanisms for managing data lifecycle are crucial. Although our proposal can leverage the Solid approach to give users control over the duration their data is stored and shared, our DOSN-PRIV model does not explicitly consider the temporal aspects of data.

In summary, our proposal prioritizes data value, providing granular access control to ensure sensitive information remains secure. We enforce transparent data usage policies, allowing users to define and control how their data is utilized, reducing the risk of misuse and enhancing trust. However, we do not integrate time-based policies for user data in our DOSN-PRIV model and service.

This work presents a privacy architecture for DOSNs composed of the ontological DOSN-PRIV model and the privacy DOSN-PRIV service. The emergence of DOSNs was motivated by problems found in OSNs regarding user privacy. However, even with the emergence of DOSNs and movements in favor of the decentralization of the web, concerns about privacy and data access control continue to concern these users and require better solutions. The privacy and data access control approach presented in this work deals with these issues on DOSN users’ data at a high level of granularity. It is essential since a control with a high level of granularity allows the user to make available only the data he wants to disclose, thus maintaining his privacy.

The DOSN-PRIV model is responsible for modeling access control and modeling DOSN. The results obtained after evaluating the model based on tasks demonstrate that the DOSN-PRIV model meets all privacy requirements proposed for the domain in question, efficiently performing the task of access control in DOSNs. The results obtained with the evaluation of the DOSN-PRIV service pointed out that it satisfactorily performs the task of users controlling access in DOSNs, as it manages the consumption of the model maintained in the POD and applies the rules defined by the user. Additionally, the evaluation demonstrated that the service response time scaled linearly across all combinations of factors and levels. In this sense, the DOSN-PRIV service adequately controls data access in DOSNs.

Our results may be improved in future works. One future task is to optimize the prototype for the evaluation in a realistic and practical environment. We aim to evaluate the proposal with more than one POD. We desire to permit users to store data with different and distributed POD providers.

Another area of future work concerns the creation of access control policies. Our proposal uses SWRL rules to create access control policies, which currently require users to have knowledge of SWRL. In this sense, as future work, we intend to eliminate the need for users to know SWRL when creating access policies, by providing them with a friendly and appropriate interface for constructing and maintaining policies.

Finally, to enhance the DOSN-PRIV model in the future, we can integrate time-based ontologies and semantic rules that allow users to define the duration for which their data remains accessible. By incorporating these ontologies and rules, the DOSN-PRIV model would provide a more dynamic and context-aware approach to data privacy, ensuring that users have control over who can access their data and for how long. This addition would significantly strengthen the privacy framework by addressing long-term data retention risks and aligning data usage with the evolving privacy needs of users.

The information leakage remains a privacy risk in this scenario. For instance, a storage server can act as a curious server and process user data in an unauthorized manner, or third-party applications can share user data with others. Thus, we also consider it a necessary task to investigate solutions to mitigate this threat.

In addition, we envisage the possibility of further improving the DOSN-PRIV model and the DOSN-PRIV service based on the investigation and application of new access control approaches. Finally, we intend to create a DOSN application based on the Solid ecosystem, using the DOSN-PRIV model and the DOSN-PRIV privacy support service.

The authors declare no conflicts of interest.