Abstract
Personal information has become one of the most valuable coins on the Internet. Companies gather a massive amount of data to create rich profiles of their users, trying to understand how they interact with the platform and what are their preferences. However, these profiles do not follow any standard and are usually incomplete in the sense that users provide different subsets of information to distinct platforms. Thus, the quality and quantity of the data vary between applications and tends to inconsistency and duplicity. In this context, the Social Linked Data (SOLID) initiative proposes an alternative to separate the user’s information from the platforms which consume it, defining a unique and autonomous source of data. Following this line, this study proposes Pushed SOLID, an architecture that integrates SOLID in the user’s smartphone to store and serve their information from a single entity controlled by the users themselves. In this study, we present an implementation of the Pushed SOLID proposal with the aim of experimentally assessing the technical viability of the solution. Satisfactory performance results have been obtained at battery consumption and response time. Furthermore, users have been interviewed about the proposal, and they find the solution attractive and reliable. This solution can improve the way data are stored on the Internet, empowering users to manage their own information and benefiting third party applications with consistent and update profiles.
1. Introduction
Internet applications have become an important part of our daily routines. Every day, thousands of users interact with social networks, sharing new content, consuming posts, and communicating with others. Platforms are concerned on keeping users interested on the services they supply, so that one of the main challenges is providing the appropriate content to the right audience. Successful social webs such as Facebook (https://www.facebook.com), Twitter (https://www.twitter.com), Amazon (https://www.amazon.com), Netflix (https://www.netflix.com), or Spotify (https://www.spotify.com) provide customised services for their users based on their preferences and habits [1]. For this, the storage of personal data becomes critical for applications which benefits from fidelity to enhance the experience and competency [2]. However, these practises are not always favourable both for users and companies. The centralisation and privatisation of the information storage can drive to poor services and risks among other factors.
The privatisation and centralisation of the information is a common practise for applications and companies. Data provide a significant competitive advantage which enables a deeper understanding of the market and users. Services can be improved and adapted to the changing demands of audience which can be analysed and studied to infer these conclusions [3]. Besides, targeted advertisement makes data collection lucrative [4]. However, this privatisation trend drives sites to form information silos, so that data storage is performed independently and autonomously. Hence, the access for other applications is disabled, and users do not enjoy much control over their data. As a consequence, these policies result in potential privacy problems, inconsistencies, duplicity, and insecurity issues.
The lack of any storage standard for information and the unwillingness to share data between platforms have direct consequences on users and companies. Reutilisation of information is not a common mechanism in this kind of application. Users who create an account on a new platform do not find easy by default to port information, friend lists, and interests in new profiles. It is true that many services allow login with Facebook or Google credentials; however, this drives to another point: privacy and dependency. Many of these platforms require accepting terms and conditions which involve targeted publicity, empowering these companies [5]. Therefore, many users place blind confidence in these policies [6], which eventually can result in data leaks [7] and in the use of information for private ends [8–10]. This illusion of control is evident when information and profiles cannot be deleted definitively even when users deactivate their accounts [11]. However, the inconsistencies and duplicity are also significant collateral effects of the privatisation.
Considering most of the applications are reluctant to share their stored information, there is a large set of data duplicated between services [12]. Information about identification, address, contact, and interests are common topics in registration processes. For example, fields such as name, phone, sex, or birthday are required for new profiles in platforms such as LinkedIn (https://www.linkedin.com/signup), Facebook (https://es-es.facebook.com/r.php), or Twitter (https://twitter.com/i/flow/signup). This way, the inputted data are duplicated, resulting in future inconsistencies. A little change in any of these parameters would oblige the user to update the information one by one. As a result, it is common that services recommend content according to past values such as addresses or interests. Likewise, this is typical on multimedia platforms such as music streaming services which recommend content according to previous reproductions. Thus, e.g., if two music streaming platforms are used in unbalanced times, the performance will not be accurate in any of them. Thus, inconsistencies and duplicity affect the user experience, which becomes wasted and results in a bad service for both application and costumer.
As a response for this, there are proposals which attempt to provide alternative models for data storage. Following the basis of data decentralisation, some of the most popular are WebBox [13] or Diaspora [14]; however, Social Linked Data (SOLID) initiative [15] becomes the most relevant among these solutions. SOLID proposes the decentralisation of the information to separate applications and personal data [16]. This way, users store their information in autonomous entities called Personal Online DataStores (PODS). Therefore, applications would adopt a model where they do not store data but request it from PODS. Thus, users are able to control accesses and authorise or deny petitions. Adopting this model provides users and companies an enriched experience based on accuracy, privacy, and control, giving response to information duplication and inconsistencies. This way, PODS becomes useful elements to enhance the experience for users and to improve companies’ services.
In the present work, we propose the deployment of SOLID PODS on smartphones. This combination exploits the pervasive and contextual characteristics of these devices to provide a new storage model for personal data. Smartphones are appropriate devices to store data since most of the information involved in the applications processes are obtained from them [17, 18]. They become relevant sources of information, so that they can be easily integrated in the data flows without requiring further changes in applications. Therefore, smartphones are suitable devices to store PODS with the user profile, keeping personal information and relevant data for applications. Thus, external apps request access which the user can authorise or deny. As a result, the user is able to know which applications are consuming information and when, whereas companies benefit from a reliable update and consistent data source.
To present this work, the rest of the study is organized in four main sections. Next, some alternative proposals for data storage are introduced, and the differences with our approach are analysed. Then, our proposal is described in detail, including a reference implementation. Following, an assessment of the prototype is presented to study the acceptation and technical viability of the solution. And finally, last section draws some conclusions about the study.
2. Related Works
As the present work, many approaches have brought solutions for alternative data storage. The management and storage of personal information have elicited multiple works which try to bring transparency and control for the users. In this line, even some big companies manifest concern and corporate responsibility about the data government and propose mechanisms to help users. This is the case of Apple and its tool to enable or disable apps to track the user’s activity [19]. This function increases the control over the data and its diffusion. However, the tool does not provide a mechanism to avoid data replication and inconsistencies. For this, there are other works which provide further mechanisms and privacy from external accesses. Some proposals focus on the way the data is shared through a set of entities, while others focus on centralising the storage on just one point. Examples of these can be the HAT project [20], Freenet [21], the DAT Foundation [22], the Threefold Net [23], the ActivityPub [24], the Safe Network [25], or the BBC Databox [26]. However, recently, the SOLID initiative has become one of the most relevant.
Works such as by Paulos [27], Eisenstadt et al. [28], Ramachandran et al. [29], and Mannens et al. [30] take SOLID as a base for implementations which exploit the potential of the tool and develop new functions and mechanisms.
The work developed by Paulos et al. [27] brings a deep usage of SOLID for health purposes. Taking into account the massive amount of health data collected by wearables and training devices, this proposal study an alternative storage architecture based on SOLID. The project investigates about the decentralisation of the records stored by companies such as Fitbit, Apple, or Google into a model based on SOLID deployed in the smartphone. This way, issues such as privacy, consistency, and private management are addressed. However, in contrast with our proposal, the solution stores health data to protect privacy and consistency, while our project provides a tool to centralize information and serve any kind of information to third applications.
In the case of Eisenstadt et al. [28], the work centres on providing a reliable certification method for COVID-19 test results. This way, the project brings an architecture for storing tamper-proof and privacy-preserving certification that allows the identification of people who has submitted to Coronavirus tests. For this purpose, the study makes use of SOLID PODS running on phones, guarantying the privacy of the contained information. Eventhough the project makes use of smartphones to deploy PODS, the purpose centres on providing a validation and certification tool. Thus, the solution does not implement services to store and serve personal information. However, our work offers the mechanism to manage the individual’s data as services for third parties.
In the same way, Ramachandran et al. [29] also proposed SOLID as a tool for data verification and confidentiality. Thus, the project connects SOLID PODS and Blockchain to create a decentralized architecture which provides a reliable mechanism for data storage, keeping integrity and privacy.
The project proposed by Mannens et al. [30] presented a model to streamline governmental processes making use of the SOLID PODS. The idea comes up as a response to the large amount of personal information that governments store and how institutions keep multiple copies. Issues such as consistency, access control, and privacy are addressed through the use of PODS, following legal frameworks. Therefore, citizens manage their information storing the data in their private PODS and allowing public institution the access. As a result, citizens get control over their data while responding to store inconsistencies between institutions. However, the solution is not a universal tool for information gathering but centred on bureaucracy and official institutions.
These approaches implement SOLID on smartphones. The solutions equip PODS with new behaviour and possibilities, defining a decentralized architecture based on individual devices. The proposals integrate SOLID for concrete purposes such as certification, validation or, in the case of Paulos [27], storing. However, even though these implementations exploit SOLID, they do not draw a global mechanism for data storage. This way, evaluating the different alternatives, we believe it is interesting to equip smartphones with a real relevance at information management and align their possibilities with SOLID mechanisms. Thus, this proposal places smartphones as the core of data storage to serve a new paradigm where privacy and decentralisation suppose the key element of the information government.
Pushed SOLID provides an information profile which could serve as potential tool for multiple purposes. Projects [17, 31–33] which require a profile to manage, process, and export data can be easily integrated with the architecture. In the same way, solutions [34–36] could find in the present proposal a reliable mechanism for implementation.
In the next section, the details of the proposed work are explained, and the internal mechanisms of the solution are provided.
3. Pushed SOLID
This study proposes an architecture which combines the intimate nature of smartphones and the powerful philosophy of the SOLID initiative. The solution mixes these two lines into a project which situates the user in the centre of the information management. Thus, smartphones become the store of their data, empowering the devices to serve as providers of the information to the external applications which require it. This proposal aims to provide a response to the increasing interest in data governance and presents a solution for inconsistencies and duplicity of information on personal profiles.
3.1. System Definition
The proposed architecture relies on a set of components which collaborate to provide the information to external requests as shown in Figure 1. This scheme explains the complete process to communicate a petition from an external application () to the SOLID PODS () of the user, executed on its smartphone. This way, three main entities shape the architecture: the SOLID PODS () and Pusher app () in the smartphone () and API Gateway () in the server. Additionally, Firebase () is used to communicate petitions between the server and the smartphone and the external application () is the one which begins the process. Next, the elements of the architecture are detailed and explained.
The SOLID PODS is the entity in charge of storing the personal information. This element is executed locally in the user’s smartphone. It has been designed to be deployed on a server; however, in the current proposal, they have been adapted to be deployed on smartphones. Thus, the PODS stores data locally in the device, independently from any external entity. In the current proof of concept of the solution, users can interact with the platform using the default web interface in the phone. Considering the main goal of this implementation is analysing the viability of the proposal, the interactions can be done using the default front.
Once the SOLID PODS is configured, it is ready to provide information. However, the data store is locally deployed, so it can not be accessed externally, and only the own phone visualises the platform. Nevertheless, we want to provide the requested information to external apps (), so that it is required an additional mechanism to perform this. Hence, we turn to the Pusher application () to manage external requests. This application provides communication between the API Gateway () and the SOLID Server () which runs on the smartphone. The API Gateway is required to effectively resolve the petitions and to map the SOLID domain requests with the address of the device. Nevertheless, the adoption of this intermediate layer does not work against the decentralized philosophy since the API Gateway does not store further data than the tuples related to addressing the petitions. In order to perform this communication between the API Gateway and the smartphone, Firebase () [37] is used to connect the petitions from with the device.
Firebase is a technology developed by Google which enables a simple push-based communication between entities regardless of the technology used for Internet connectivity (Wi-Fi, 4G, or others). We have considered Firebase as a communication component for its simplicity but can be easily replaced by a similar open-source mechanism like MQTT [38], which would allow information transfer between the layers. Nevertheless, Firebase provides reliable performance and its terms of usage specify how the data stored by the technology are basic information required to operate [39].
Once Firebase communicates the petitions received in the API Gateway, this component communicate the request with the smartphone executing a callback method of Pusher app. Therefore, the method executed in Pusher app asks for the required information to the SOLID PODS, which selects the corresponding data from the profile and returns the values. As a result, Pusher app provides the requested data to the API Gateway. Considering the callback method identifies the requester entity and SOLID PODS counts with access control; security and validation tasks can be easily integrated in the process. As a result, the technical details to replicate the implementation process can be found in the project repository (https://bitbucket.org/spilab/solidsituational.context).
Considering these three components of the system, the way they are coordinated begins from the installation and configuration of the SOLID PODS and the Pusher application. Once these two elements are operative, the Pusher app communicates the addition with the API Gateway, which will be in charge of mapping incoming petitions to the corresponding smartphone. For this, the token ID of Firebase is updated from the Pusher app, in the case it changes. Therefore, the API Gateway keeps updated with the latest value required to operate.
The detailed working of Pushed SOLID is shown in Figure 2, which identifies all steps and collaborations between the different layers. First, the external application () requires a concrete set of information from a user (step 1) (e.g., a new web platform where a user is creating an account). This way, instead of having to input all their personal data, the new member provides its SOLID Domain (2). This variable is the public username of its SOLID PODS and serves as main identification in the architecture. Therefore, the application only have to demand the required data to the API Gateway (), providing the SOLID domain. The API Gateway is the only entity which truly knows where the information is stored. Thus, this layer uses Firebase technology to easily communicate with smartphones through push notifications. Moreover, the API Gateway maps the SOLID Domain with the Firebase ID and notifies the corresponding smartphone () about the petition (3). As a result, the device receives the notification and asks the user for acceptance to allow the external app access to the information (4). This transaction is carried out with the Pusher application () which executes a callback method invoked when the API Gateway receives interactions. Then, the user is asked to allow or deny petitions. This way, the permissions can be configured, defining concrete requester as reliable. This operation can be performed straightly in the SOLID PODS or using the Pusher app. In the case the permission is favourable, the local SOLID PODS () provides the required information to the Pusher app. Then, the application responds to the API Gateway with the data (5). Finally, the API Gateway returns the answer to the requesting platform () and the process is completed (6).
Considering this procedure, Pushed SOLID becomes a suitable tool to manage the information both for users and applications. Users are able to keep all their personal information in just one place: their phone, which physically stores the data. Furthermore, it is possible to identify all applications and entities which access the profile. Thus, the user can authorise and revoke petitions at any time. On the other hand, applications benefit from the centralisation of the data in the PODS. This solution guarantees the reliability of the information and that the personal profiles are complete and updated. Besides, inconsistencies and data replication are solved, providing uniformly a common source of data for all applications. As a result, information can be shared between platforms, and it is possible to track the entities which consume our data and the storage becomes standardised. Hence, the way personal information is stored in the Internet could change, bringing a new philosophy based on control and governance for the user.
3.2. Use Case
We have already approached to some of the issues which affect users experience due to the independence of the data between platforms. One of the most recurrent is enjoying a service using multiple platforms, such as music streaming, where users tend to distribute reproductions among several applications [40]. This section compares the ordinary scenario for a user who does not use Pushed SOLID and how the proposal can improve the experience.
For this example, we consider two of the most used music streaming platforms [41]: Amazon Music and Spotify. Both applications count with a recommendation system based on historical reproductions and favourite lists, so the more a user uses a given platform, the more accurate suggestions are got from that platform. However, these applications store the information privately and they do not share it with other services. This way, these politics become inconvenient when users consume more than one streaming platform. Thus, the irregular time spent in each service drives to inaccurate recommendations. Considering this, the proposed use case represents a possible scenario (Figure 3): a user spends 90% of time () listening to music with Spotify () and 10% () using Amazon Music (). As a result, the knowledge about preferences is unbalanced, so that Amazon Music cannot provide accurate recommendations while Spotify lacks on a 10% of the music reproductions. Therefore, this context can highly affect the user experience ().
As a response for this recurrent situation, Pushed SOLID proposes the unification of the knowledge generated from platforms in the SOLID PODS (). Thus, the information about historical reproductions and favourite music is stored in a single entity: the SOLID profile (). This way, music streaming platforms read and modify the same music preferences independently from the usage time. As a result, all applications provide recommendations as if they would be used every time. This improvement is reflected on Figure 3 where both Amazon Music and Spotify consume the same information about music preferences.
As a result, Pushed SOLID improves the recommendation performance of the music streaming platforms and provides a better experience, sharing data sources and democratizing the custom experiences possibilities. In the same way, the user is not the only beneficiary since applications will be able to perform more accurate recommendations independently from the time of usage. Thus, Pushed SOLID becomes a very interesting solution for information management, whereas the data governance befalls completely on the user. Considering the proposal uses the smartphone as a data provider, performance and consumption become two main issues for the technical viability. Moreover, next section evaluates the implementation of the architecture and analyses the response of the solution under daily use, checking the technical viability of the solution.
4. Pushed SOLID Validation
The architecture proposes the use of the smartphone as the centre of all our profiles on the Internet. This means that the device is in charge of managing all incoming data petitions and satisfying them with the corresponding information. Luckily, the technical capabilities of the smartphones have been constantly improving during the last years. However, the high requirements of the proposal suppose a challenge for devices, involving factors such as battery consumption and response time. In addition, it is relevant to consider the possible controversy nature of the project. Taking into account the goal of the platform is managing the large set of personal information distributed along the Internet, user’s perception is critical to build a reliable solution. Considering this two points, an experimental evaluation about user’s opinion and a system assessments about the performance and technical viability of the proposal has been performed. For this evaluation, the implementation of Pushed SOLID counts with PODS which stores a profile with personal information, historical music played, and main interests (Table 1).
The assessments performed in the experiment followed two dimensions: the perception and usability of the solution and the technical performance of the implementation.
4.1. Usability Tests
The perception and feeling of the users is a critical variable for the proposal. Considering the main goal is managing all personal information, it becomes clearly relevant to study the reaction and opinion from users when they use the prototype. Thus, several steps were considered to perform usability tests. Therefore, a methodology based on user testing [42] was applied to obtain reliable answers. Following this guideline, we were able to elaborate a testing context which allowed us to analyse the perception of the idea and the first opinions after its use. This way, a group of users participated and answered two different surveys.
The first step was to select a group of sixteen users, who are not related with the project, and to introduce them to the purpose of Pushed SOLID. The background of the participants varied, with only six technicians. This way, we try to avoid bias.
Then, a first survey about the perception of the idea was done, addressing privacy politics, data centralisation, and opinions, from a neutral point of view. This way, the questions raised clearly the issue, approaching current tendencies and the concept that users have understood about the proposal. The answers were based on ranges: each question () raised a topic and testers had to provide a score () from , according to the relevance they give to that specific topic. Additionally, a comments box gathered opinions and suggestions. The questions included in the perception survey are given in Table 2. Thus, an average of the obtained results from the survey is shown in Figure 4. Besides, since is not a scoring topic but a text parameter, the most recurrent words in the answers are considered. Additionally, a control question was introduced to check if any respondent answered randomly. As a result, all users answered correctly.
Figure 4 shows the obtained scores in the perception survey. The results manifest the interest from users about the proposal and about the phone as the centre of information management. In the same way, testers also showed distrust regarding data management policies in companies (), especially in those participants who were technicians. For the questions concerning the project concept, users reflected interest for centralisation (), defining the overall valued dimension. In the same way, testers also think that public would approve and adopt the proposal (). However, the values define this characteristic as the lowest rated regarding the work. In the case of the main purpose of Pushed SOLID, users think this can become a solution for store issues like replication or inconsistencies (). Additionally, the answers in are analysed considering the recurrence of words. For this, we have considered as common concepts those words which are included in the abstract description of the solution. Therefore, concepts like smartphone (appeared 14 times in responses, considering “phone” as synonym), Internet (13), privacy (11), data (10), and information (6) are ignored. As a result, the words which repeat the most and are not common are centralisation (10), companies (9), security (7), trust (6), change (6), and music (4). Hence, the messages were mainly focused on manifesting the relevance of the idea as a disruptive tool which proposes a great change at data management through centralisation. Besides, the tendency manifests how there is a widespread concern about providing security mechanisms to guarantee a safe storage in the smartphone, defining this as the main core of the project. Also, there were comments which support that companies should take part in the proposal, manifesting the importance of providing a good experience also for enterprises. At last, some contributions were focused on potential applications like music services. Considering the results obtained in the first interaction with users, the survey discloses significant interest in the proposal by the testers.
Once the first approach was finished, testers interacted with the platform. The tasks they performed mainly focused on user experience, so that they created a PODS and inputted information. Besides, they supervise information petitions from external applications. In the same way as the previous step, testers answered a survey about the user experience using the proposal implementation. Hence, testers scored () from , the satisfaction and user-friendliness of the solution. The questions included in the survey are given in Table 3. As a result, Figure 5 shows the obtained average results.
Figure 5 shows the obtained results from the user experience survey. In average, the scores denote testers have had a successful experience, specially technicians. For , the average of answers situates the information input with 2.69, around one point below . The most rated parameter in the survey was with 3.69. Hence, these results show a great acceptance for a novel proposal. Testers mainly highlight the simplicity at using the platform, especially for the registration process and configuring the SOLID PODS. Additionally, the suggestions and comments in are also interesting. In the same way as previous survey analysis, the opinions in the comments field are addressed with the most recurrent words. Thus, the words which repeat the most were user interface (11 times), easy (10), comfortable (9), battery (8), performance (5), and integration (4). These recurrences manifest some of the most favourable points of the proof of concept. Users talked about the user interface and the way the application is easy to configure. Also, testers place a value on the comfort of checking the information as well as the incoming petitions from external applications. In the same way, performance and battery were two of the most recurrent issues, standing out the importance of providing a good efficiency in the execution. As a result, the implemented solution provides a successful user experience with an easy-to-use interface.
Considering the obtained results in the usability tests, the proposal fulfils the requirements of usability and provides a disruptive solution to manage information. However, it is important to highlight the performance requirements that the prototype meets. For this, the next section assesses the technical behaviour of the solution, evaluating the consumed battery and the response time and drawing a discussion of the results.
4.2. Technical Performance
One of the main dimensions of the project is the technical viability. Considering the architecture proposes the smartphones as the provider for all information required by applications, the solution must guarantee a good performance. This way, parameters such as the energy consumption and response time become critical variables to analyse. In this section, the provided implementation of the Pushed SOLID is assessed in a laboratory context where random petitions are simulated to evaluate battery consumption in the smartphone devices and the time required to obtain a concrete data from the PODS. Next, the setup configuration is explained and the results are discussed.
4.2.1. Assessment Setup
In order to evaluate the platform, an assessment setup is built. This scenario is composed by two different contexts: the laboratory and the smartphones. Each of them is in charge of deploying any of the three different entities involved in the architecture: external application which performs petitions (), the API Gateway which communicates petitions with smartphones (), and smartphones which executes the Pusher app () and the SOLID PODS to store the information (). Considering this, an experimental context is built to simulate a heavy charge of petitions to the architecture. Figure 6 represents graphically the process.
The petitions are generated in the laboratory context. It is shaped by two computers, computer and (Table 4). The first one deploys the API Gateway (), whereas the second one send petitions to it, simulating the activity of an external application (). follows Algorithm 1 to request the data to the API Gateway, which communicates with the smartphones. The smartphone context is shaped by two devices: smartphones and (Table 5). Both devices are submitted to a daily use by their owners while executing a SOLID PODS and answering automatically the petitions generated by . As a result, the raised scenario proposes a experimental context where the performance of the platform can be easily tested. Every time performs a petition, the time lapsed between the request and the response is registered. In the same way, both smartphones and monitor the battery consumed by serving the data from the PODS.
|
The proposed execution scheme is performed during three days continuously, following the instructions of Algorithm 1. This way, there are two programmed peaks of petitions during the first two days. These events try to check the capability of the platform to provide response to a large set of requests, while analysing the impact on the response time and battery average. The number of petitions performed during an hour in the experiment ranges from zero to twelve. Therefore, the traffic does not follow a clear pattern and changes randomly. This idea corresponds with the goal of providing an irregular and realistic flow of messages. For this, a generated number and a waiting time of five minutes is used. As a result, this behaviour tries to provide a changing number of requests based on the average number of notifications that smartphones use to receive in a day [43]. Once the execution concludes, outcomes are obtained. The next section discusses the results and extracts conclusions.
4.2.2. Result Analysis
After three days of executions, the results are obtained. There are two sources of results: computer B (), which has been monitoring the response time, and smartphones A () and B (), which have monitored the battery level evolution. These two variables are specially relevant to qualify the performance of the platform, since they reflect critical values for the purpose of the solution. This way, the battery consumption and response time are introduced.
On the one hand, the battery consumption ( (%) with s as the corresponding smartphone) represents the percentage of battery consumed by the application execution. Smartphones run two main components: the SOLID PODS and the Pusher app. The first one waits for petitions from Pusher app which, at the same time, receives requests from the API Gateway, using Firebase. Therefore, the consumption of energy is an important part of the project. Considering that Internet application would require information to the smartphone, it is important to provide availability in the service. For this, the energy consumed by the architecture must be low in smartphones. In order to obtain realistic results, and have been submitted to daily use by their owner with tasks such as surfing the net, messaging, multimedia, and geopositioning. The experiment is focused on analysing how Pushed SOLID can be embed in the day-to-day routines and address the quality of its integration with the rest of functions. Therefore, we discarded the assessment in a controlled environment, focusing in results obtained from a real context. This way, some inaccuracies are assumed, such as distinguishing between consumptions in WiFi or cellular network. For this task, the android Battery Monitoring Tool [44, 45] has been used. As a result, the obtained values correspond with a realistic context.
On the other hand, the response time ( (ms)) represents the time elapsed between a petition is done by an external app and the information is received by the entity. This way, this parameter becomes especially relevant since the information must be provided quickly to the multiple demanding applications. Factors such as the CPU usage, the memory available, and the Internet connection can affect the results, but this also enriches the outcomes. Considering the idea is integrating the service with an average use of the smartphone, it is interesting to study the response of the architecture when the device is submitted to a real use. Once the executions are completed, the results are obtained. Thus, Figures 7 and 8 show the outcomes.
Figure 7 shows the evolution of the battery in and during the three days of executions. The figure represents three different variables as a function of the execution time (): the battery evolution of both smartphones ( and ) and the number of generated requests (). As can be seen, there is not a clear connection between and the battery evolution ( and ). There are two programmed peaks in at on days 1 and 2. These events were preset to find more evident impact on battery. However, as can be seen, the battery is not directly affected by the requests. Therefore, we can deduce that the energy consumption derived from the architecture operation on the smartphones is very low. Additionally, the Android Battery Monitoring Tool indicates consumption below 0% for Pusher app, a report which matches with the battery consumption trajectory.
In the case of , Figure 8 shows the recorded times to respond to external applications as a function of the execution time (). Thus, for this case, we can appreciate a connection between and . The average of response time rounds (ms) with a median number of petitions of . The programmed peaks of requests have a direct impact on the time required to solve the petitions. Thus, increases from the average value up to more than 7000 (ms), evidencing that the solution is sensitive to a large number of requests. Moreover, in the case of the rest of the petitions, there are some values above one second. The size of the transmitting messages varies, depending if it is a petition or it is a response, between 582 bytes and 612–1024 bytes, respectively. Therefore, it is difficult to identify the size as a bottleneck. Nevertheless, This delay can be introduced by the API Gateway, which performs a waiting time to receive information from the smartphone. As a result, the time required to retrieve information from the smartphone can be optimized. However, considering the main goal of the assessment is analysing the viability of the proposal, the delays can be accepted.
The prototype developed as a proof of the concept of Pushed SOLID provides a valid solution to store our personal data on phones. The approach has been tested to study the technical viability of the project and the results are favourable. Two of the main features the proposal must provide are acceptable energy consumption, which does not affect significantly the battery, and a reasonable response time which guarantee an effective service for external apps. Thus, once the tests have been performed, the results are favourable. On the one hand, the deployment of the SOLID PODS and Pusher app in the smartphones does not have a significant impact on the battery. In fact, the obtained results manifest how low is the energy consumed by the solution. Besides, the petition peaks do not specially affect the battery performance. On the other hand, the response time is sensitive to the simultaneous requests. However, the average time required to provide information is low and satisfies the requirements of the service.
Considering the two dimensions of the assessment, usability and technical performance, we can consider the prototype as a good implementation of the architecture. The implemented solution becomes a reliable method to identify the possibilities of the project and its scope. As summary, the involved testers manifest significant interest for the proposal and the qualitative evaluations show its technical viability. Therefore, the project represents a successful work line with a promising approach to a new data paradigm. In order to define some considerations in the assessment, the next subsection draws the threats to the validation process, identifying some relevant considerations about the results. Furthermore, the last section brings conclusions about the proposal and the advances that the work implements.
4.3. Threats to Validity
In this section, we address the most relevant threats to validity which can condition the performed assessment. For this, two points are approached: tests with users and the smartphone operability.
One of the most relevant stages in the validation of Pushed SOLID is the usability tests. These activities involved a set of research studies to know the concern and opinion of potential users about the proposal. The results manifested a good response from research studies who considered the system as an appropriate alternative option for data storage. However, it must be considered that six of the sixteen users who participated in the experiment were technicians, acquainted with brand new solutions and novel technologies. In the case of other participants, who are ten, they were not technical profiles, so they provide more reliable results for the user testing.
On the other hand, the operability of the smartphone becomes also a threat. The smartphone which executes Pushed SOLID can loose connectivity or its battery can get discharged, so that petitions from external applications can be missed. For this, we rely on the inherent usage patterns of the user and how smartphones use to be always connected and alive. According to studies like [46–48], most users keep their phones with battery during all the day, as well as connected to the Internet. Therefore, we consider the proposal can likely be operative in almost all situations.
5. Conclusion
Personal data have become a very valuable coin for Internet companies. The custom services and advertisement are a relevant issue for enterprises which find publicity as an important source of incomes. As a result, companies keep private their data from other apps, lacking of any standard, and bringing also replication and inconsistencies between platforms. In response to this, the SOLID initiative proposes an alternative storage philosophy which centralises information on uniquely individual entities called PODS. Thus, users keeps all their information while controlling the external accesses to the data. In this framework, we propose Pushed SOLID, an architecture which deploys SOLID PODS on user’s smartphone. Thus, the information is stored in the device, which serves as provider of the data to external requests. This way, the user can easily authorise or deny accesses to the PODS.
With the objective of studying the possibilities of the work and the technical viability, a prototype of the proposal was implemented. Thus, a group of testers were interviewed about their opinion of the project, obtaining very good feedback. Users considered the model as a suitable response to the uncontrolled and massive storage of personal data. Besides considering the solution situates the smartphone as the centre of the implementation, it is relevant to guarantee the technical viability. For this, performance assessments were performed to study the impact of the solution on battery consumption and the response time of the requests. As a result, the experimental tests showed a good response of the prototype for both parameters, battery and response time. As a result, the obtained results manifest the relevance of the proposal and the technical viability.
Considering the assessments and evaluations of the proposal, Pushed SOLID can be considered as a valid solution for data storage. The possibility of keeping all personal data on the Internet in just one device enhances the users control over their own information. This way, both users and enterprises benefit from the work. On the one hand, users are empowered with a reliable knowledge about the entities which access to their data, being able to refuse requests while keeping a track on the consumed information. On the other hand, enterprises obtain updated and consistent information while issues like replication are solved. As a result, Pushed SOLID proposes a new paradigm on the Internet which becomes a new way of understanding privacy, while users and enterprises are benefited.
Data Availability
The implementation is available on the repository of the project: https://bitbucket.org/spilab/solidsituational.context. Furthermore, results and obtained data are also included.
Conflicts of Interest
The authors declare that they have no conflicts of interest.
Acknowledgments
This work was supported by the 4IE+ Project (0499-4IE-PLUS-4-E) funded by the Interreg V-A España-Portugal (POCTEP) 2014–2020 program, the project RTI2018-094591-B-I00 (MCI/AEI/FEDER,UE) by the Department of Economy, Science and Digital Agenda of the Government of Extremadura (GR18112 and IB18030), and by the European Regional Development Fund.