Feedback Isabel

thesis/content/00-abstract-de.tex

@@ -1,5 +1,5 @@
 Trotz zahlreicher Skandale um den Datenschutz in etablierten sozialen Netzwerken (Facebook, Google+), erfreuen sich die Plattformen noch immer großer Beliebtheit. Alternative soziale Netzwerke, die den Fokus auf den Schutz der Daten ihrer Benutzer gelegt haben, fehlt es an Attraktivität, sodass sie regelmäßig scheitern. Wenn die Nutzer den sozialen Netzwerken trotz mangelhaftem Datenschutz treu bleiben, müssen Wege gefunden werden, wie ihre Daten dennoch geschützt werden können. Ein hybrider Ansatz ermöglicht die gewohnte Nutzung der Plattform und verwendet einen weiteren Kommunikationsweg zum Austausch schützenswerter Daten.
 
-Das Ziel dieser Arbeit war die Ausarbeitung eines Konzepts für ein hybrides soziales Netzwerk sowie die Validierung durch einen Prototyp. Im Rahmen des Konzepts wurden die Interessen der Stakeholder aufgezeigt und Anforderungen an die hybride Lösung definiert. Für die Umsetzung wurden konkrete Lösungsstrategien für Architektur und Client benannt. Der Prototyp wurde als Android App für Twitter erstellt. Das IPFS-Protokoll zur dezentralen Speicherung von Daten in Kombination mit der verteilte Datenbank GUN wurde für einen sicheren Datenaustausch eingesetzt.
+Das Ziel dieser Thesis war die Ausarbeitung eines Konzepts für ein hybrides soziales Netzwerk sowie die Validierung durch einen Prototyp. Im Rahmen des Konzepts wurden die Interessen der Stakeholder aufgezeigt und Anforderungen an die hybride Lösung definiert. Für die Umsetzung wurden konkrete Lösungsstrategien für Architektur und Client benannt. Der Prototyp wurde als Android App für Twitter erstellt. Für einen sicheren Datenaustausch wurde das IPFS-Protokoll zur dezentralen Speicherung von Daten in Kombination mit der verteilte Datenbank GUN eingesetzt.
 
-Das Ergebnis zeigt, dass das Konzept umsetzbar ist und die definierten Ziele zu einer qualitativ hochwertigen Lösung führen. Der Hybrid OSN Prototyp erfüllt die zuvor definierten Anforderungen nahezu vollständig. Für Likes und Tweets kann der Nutzer selbst entscheiden, über welches Netzwerk die Daten mit anderen Nutzern geteilt werden sollen. Die Lösung ist nutzerfreundlich und bedarf nur minimal Konfigurationsaufwand.
+Das Ergebnis zeigt, dass das Konzept umsetzbar ist und die definierten Ziele zu einer qualitativ hochwertigen Lösung führen. Der Hybrid \acf{OSN} Prototyp erfüllt die zuvor definierten Anforderungen nahezu vollständig. Für Likes und Tweets kann der Nutzer selbst entscheiden, ob über das offizielle Twitter Netzwerk oder das private Netzwerk die Daten mit anderen Nutzern geteilt werden sollen. Die Lösung ist nutzerfreundlich und bedarf nur minimalem Konfigurationsaufwand.

thesis/content/00-abstract-en.tex

@@ -1,5 +1,5 @@
 Despite numerous scandals about data protection in established social networks (Facebook, Google+), the platforms still enjoy great popularity. Alternative social networks, which have focused on protecting the data of their users, lack attractiveness, so they regularly fail. If users remain loyal to social networks despite poor data protection, ways must be found to protect their data. A hybrid approach enables the natural use of the platform and uses another communication channel to exchange sensitive data.
 
-The goal of this work was to work out a concept for a hybrid social network and to validate it with a prototype. Within the scope of the concept, the interests of the stakeholders were identified, and requirements for the hybrid solution were defined. For the implementation, we mentioned concrete solution strategies for architecture and client. The prototype was created as an Android app for Twitter. The IPFS protocol for decentralized data storage in combination with the distributed GUN database was used for secure data exchange.
+The goal of this thesis was to work out a concept for a hybrid social network and to validate it with a prototype. Within the scope of the concept, the interests of the stakeholders were identified, and requirements for the hybrid solution were defined. For the implementation, concrete solution strategies for architecture and client were mentioned. The prototype was created as an Android app for Twitter. For secure data exchange, the IPFS protocol for decentralized data storage in combination with the distributed GUN database was used.
 
-The result shows that the concept is implementable and that the defined goals lead to a high-quality solution. The Hybrid OSN prototype meets the previously defined requirements almost entirely. For Likes and Tweets, the user can decide which network should be used for data exchange with other users. The solution is user-friendly and requires minimal configuration effort.
+The result shows that the concept is implementable and that the defined goals lead to a high-quality solution. The Hybrid \acf{OSN} prototype meets the previously defined requirements almost entirely. For Likes and Tweets, the user can decide if the official Twitter network or the private network should be used for data exchange with other users. The solution is user-friendly and requires minimal configuration effort.

thesis/content/01-introduction.tex

@@ -5,7 +5,7 @@
 \label{sec:motivation}
 Numerous scandals about data protection in \acp{OSN} have proven that user data are not sufficiently protected. In March 2018 it became known that the data of 87 million Facebook users were made available to the company Cambridge Analytica \cite{facebook2018cambridge-analytica}. During a security investigation in March 2019, Facebook found that the passwords of several hundred million users were stored unencrypted in plain text \cite{facebook2019passwords}. After an analysis by Google revealed a severe bug in the \ac{API} that allowed the personal data of 52.5 million users to be retrieved, it was decided to close their platform Google+ \cite{google-plus2018shutdown}.
 
-However, although these circumstances are well known, users remain mostly loyal to their \ac{OSN}. As a result of the Cambridge Analytica incident, the number of daily Facebook users dropped only briefly in Europe but is in the meantime back on the previous level \cite{facebook2019reportq4}. Alternative \acp{OSN}, which focus on protecting their users' data, regularly fail to get a sufficiently large user base or establish a business model to ensure their operation. For example, the decentralized \ac{OSN} Diaspora* has less than 700\,000 users after nine years and the \ac{OSN} OpenBook\footnote{https://www.openbook.social/en/home} needed a second Kickstarter crowdfunding\footnote{https://www.kickstarter.com/projects/1520156881/openbook-privacy-friendly-fun-and-honest-social-ne} round after the first one failed \cite{openbookXXXXkickstarter}.
+However, although these circumstances are well known, users remain mostly loyal to their \ac{OSN}. As a result of the Cambridge Analytica incident, the number of daily Facebook users dropped only briefly in Europe but is in the meantime back on the previous level \cite{facebook2019reportq4}. Alternative \acp{OSN}, which focus on protecting their users' data, regularly fail to get a sufficiently large user base or establish a business model to ensure their operation. For example, the decentralized \ac{OSN} diaspora* has less than 700\,000 users after nine years and the \ac{OSN} OpenBook\footnote{https://www.openbook.social/en/home} needed a second Kickstarter crowdfunding\footnote{https://www.kickstarter.com/projects/1520156881/openbook-privacy-friendly-fun-and-honest-social-ne} round after the first one failed \cite{openbookXXXXkickstarter}.
 
 The binding to the respective \ac{OSN} is so strong that switching to another, more secure \ac{OSN} does not seem to be an option. To better protect users' data on existing platforms, other ways have to need to be examined. The Doctoral College \enquote{Privacy and Trust for Mobile Users} works on \enquote{Privacy and Trust in Social Networks (Resarch  Area  B)} \cite{rtgXXXXarea-b}. Especially the subarea B.2 \enquote{Privacy Protection via Hybrid Social Networks} is about hybrid solutions that combine established \acp{OSN} and privacy-preserving approaches \cite{rtgXXXXarea-b2}. As part of these researches, this work is motivated to provide a detailed concept for a hybrid solution to protect the user's data and verify the idea with a prototype.
 

thesis/content/06-discussion.tex

@@ -1,6 +1,6 @@
 \chapter{Evaluation}
 \label{ch:evaluation}
-This chapter is on the evaluation of the Hybrid \ac{OSN} app. It is discussed to which extent the previously defined requirements and quality goals were fulfilled and validated how realistic the requirements are in general. Afterwards, limitations are discussed, and a threat model mentions potential problems.
+This chapter is about the evaluation of the Hybrid \ac{OSN} app. It is discussed to which extent the previously defined requirements and quality goals were fulfilled and validated how realistic the requirements are in general. Afterwards, limitations are discussed, and a threat model mentions potential problems.
 %Furthermore, a comparison to other related work is carried out.
 
 \section{Fulfillment of Requirements and Achievement of Objectives}

thesis/content/06-discussion/achievement.tex

@@ -6,24 +6,22 @@ With regard to the functional requirements previously defined in Chapter \ref{se
 \subsubsection{Standard Functionality}
 As part of this work, a prototype with limited functionality was created. Accordingly, numerous functionalities, such as the direct messaging system, notifications, the posting of images, gifs, videos or surveys, and much more are not implemented. However, it was considered that the prototype implements all essential functionalities so that the basic use of Twitter is possible. These basic functions include displaying the home feed and user feeds (profiles), searching for users and managing the connection (follow, unfollow, mute, block), as well as liking tweets and posting new tweets (incl. reply, retweet).
 
-While the majority of the missing functions were deliberately omitted for time reasons, the \ac{API} also sets limits. For this reason, this requirement must be evaluated as not fulfilled. However, due to the limitations of the \ac{API}, it could not have been fully met. While Twitter is an extremely grateful example due to its simple functionality and generous \ac{API}, the limitations of other \acp{OSN} are much more severe. A missing \ac{API} and crawling prohibited by terms of service would make data exchange between a client and the \ac{OSN} virtually impossible.
+While the majority of the missing functions were deliberately omitted for time reasons, the restricted \ac{API} also sets limits. For this reason, this requirement must be evaluated as not fulfilled. But, due to the limitations of the \ac{API}, it could not have been fully met. While Twitter is an extremely grateful example due to its simple functionality and generous \ac{API}, the limitations of other \acp{OSN} are much more severe. A missing \ac{API} and crawling prohibited by terms of service would make data exchange between a client and the \ac{OSN} virtually impossible.
 
 \subsubsection{Client-side Solution}
 Since it is not possible to execute code on the Twitter's servers, no other solution than a client-side approach is possible. Accordingly, all functions are implemented on the client side, and the requirement is fulfilled.
 
-As described in Chapter \ref{sec:solution-strategy-architecture}, a solution architecture either contains or does not contain additional servers. In the objectives in Chapter \ref{sec:objective}, a solution without additional servers was preferred. However, since GUN requires a relay server to establish the connection between the peers, this self-imposed goal could not be achieved.
+As described in Chapter \ref{sec:solution-strategy-architecture}, a solution architecture either contains or does not contain additional servers. In the objectives in Chapter \ref{sec:objective}, a solution without additional servers was preferred. Though, since GUN requires a relay server to establish the connection between the peers, this self-imposed goal could not be achieved.
 
 \subsubsection{Data Sovereignty}
 The user can decide for himself whether the data are shared with other users via the private network or the Twitter servers when posting or liking a tweet. Since other functionalities that require data from the user (e.g., information in the profile, direct messages) have not been implemented, at least the prototype fulfills the requirement partly.
 
-However, data about user behavior can still be collected. The user is authenticated against the \ac{API} so that his requests can be unambiguously assigned. Using this usage data, Twitter can record which profiles are called up and what the user searches for. This data can also be used to conclude a user's preferences and interests. Hybrid \ac{OSN} offers no protection against this type of data collection.
+Nevertheless, data about user behavior can still be collected. The user is authenticated against the \ac{API} so that his requests can be unambiguously assigned. Using this usage data, Twitter can record which profiles are called up and what the user searches for. This data can also be used to conclude a user's preferences and interests. Hybrid \ac{OSN} offers no protection against this type of data collection.
 
 \subsubsection{Authorized Data Access and Encryption}
-Private data should be accessible only to those users for whom they are intended. However, they should not be accessible to the service provider. Twitter only distinguishes between public and private profiles. While with public profiles every other Twitter user has access to the profile and the tweets, with private profiles only authorized followers can view tweets.
+Private data should be accessible only to those users for whom they are intended. But, they should not be accessible to the service provider. Twitter only distinguishes between public and private profiles. While with public profiles every other Twitter user has access to the profile and the tweets, with private profiles only authorized followers can view tweets. By distributing the public key to decrypt the data via the profile, the same user group is granted access to a user's private tweets, which can also see the official Twitter tweets. The additional symmetric encryption of the public key history by the Hybrid \ac{OSN} app ensures that Twitter cannot decrypt the public key history and thus also the private tweets. Therefore, the requirement can be evaluated as fulfilled.
 
-By distributing the public key to decrypt the data via the profile, the same user group is granted access to a user's private tweets, which can also see the official Twitter tweets. The additional symmetric encryption of the public key history by the Hybrid \ac{OSN} app ensures that Twitter cannot decrypt the public key history and thus also the private tweets. Therefore, the requirement can be evaluated as fulfilled.
+The implementation differs from the standard solution for this problem. Typically, data are encrypted with the recipient's public key to ensure that only the recipient can decrypt it with their private key. Though, in the case of Twitter and the public profiles, the recipient circle of a tweet is not known. Accordingly, it is not possible to explicitly encrypt data for a specific recipient.
-
-The implementation differs from the standard solution for this problem. Typically, data are encrypted with the recipient's public key to ensure that only the recipient can decrypt it with their private key. However, in the case of Twitter and the public profiles, the recipient circle of a tweet is not known. Accordingly, it is not possible to explicitly encrypt data for a specific recipient.
 
 An alternative to the implementation in Hybrid \ac{OSN} would be to encrypt data with the symmetrical Hybrid \ac{OSN} key for public profiles and to encrypt data asymmetrically with the public keys of the recipient for private profiles. The advantage would be that users with a public profile would not have to generate keys and the configuration effort would be reduced. A simpler configuration would have a positive effect on the requirement for minimal configuration effort. The disadvantage would be that a user with a private profile and a large number of approved followers would have to calculate the encryption and upload the data for each. This would be in contrast to the requirement to conserve resources.
 
@@ -36,9 +34,7 @@ The requirement for a platform-independent solution contradicts the actual requi
 \subsubsection{Anonymized Data for the Service Provider}
 Anonymous data from the private network should be shared with Twitter to prevent the service provider's business model from failing. Approximately 87\% (\$\,791 million) of Twitter's revenues in the fourth quarter 2018 were generated by advertisements \cite{twitter2019reportq4}. Thus, the central pillar of Twitter's business model is personalized advertising. Accordingly, data should be of particular interest for Twitter if it is related to a person. Only if Twitter gains knowledge about a user, this knowledge can be used to place targeted advertisements. However, it is precisely this connection between data and user that should be avoided by using Hybrid \ac{OSN}.
 
-As a result, the implementation of the requirement is almost impossible. Even though all data would be transferred to Twitter in an anonymous form for further processing, this data would be entirely worthless for Twitter's business model.
+As a result, the implementation of the requirement is almost impossible. Even though all data would be transferred to Twitter in an anonymous form for further processing, this data would be entirely worthless for Twitter's business model. In this context, it should be emphasized that the use of the \ac{API} does not result in any advertising being displayed to the user. Twitter therefore deliberately accepts that client applications that use the \ac{API} do not contribute to the generation of profits. Against this background, the implementation of this requirement is questionable although it is an essential aspect in the hybrid \ac{OSN} concept.
-
-In this context, it should be emphasized that the use of the \ac{API} does not result in any advertising being displayed to the user. Twitter therefore deliberately accepts that client applications that use the \ac{API} do not contribute to the generation of profits. Against this background, the implementation of this requirement is questionable although it is an essential aspect in the hybrid \ac{OSN} concept.
 
 In order to meet the request and at least to prove the feasibility of the anonymized data provision, the hashtags used were provided anonymously. Twitter could use this data to improve trend recognition and inform users about current, much-discussed topics. Thus, a full analysis of popular hashtags throughout the system enables precise statements.
 
@@ -61,7 +57,7 @@ In the context of the publication of the public key history, changes that are vi
 The Twitter Developer Terms and the Twitter Terms and Conditions were respected. For example, \ac{API} guidelines do not allow the redistribution of Twitter content. For this reason, when tweeting or quoting tweets over the private network, only their ids are stored, not the entire content. Hence, the requirement is fulfilled.
 
 \subsubsection{Good User Experience}
-A good user experience should be achieved by short loading times and understandable and appealing design. The loading times of the private data in Hybrid \ac{OSN} consist of two parts. With GUN, objects of interest must be identified and the data loaded from \ac{IPFS}. In both cases, it has a significant influence on the loading time whether there are enough peers with the searched information in the network. Both systems are designed for short reaction times. However, the loading times cannot be given in figures, since no reliable result could be measured due to the non-reproducible circumstances concerning peer availability.
+A good user experience should be achieved by short loading times and understandable and appealing design. The loading times of the private data in Hybrid \ac{OSN} consist of two parts. First, objects of interest must be identified with GUN. Then, the data has to be loaded from \ac{IPFS}. In both cases, it has a significant influence on the loading time whether there are enough peers with the searched information in the network. Both systems are designed for short reaction times. However, the loading times cannot be given in figures, since no reliable result could be measured due to the non-reproducible circumstances concerning peer availability.
 
 There are no objective standards for an understandable and appealing design. The following examples are intended to show how these demands on the user interface were nevertheless met.
 
@@ -76,12 +72,10 @@ There are no objective standards for an understandable and appealing design. The
 \end{itemize}
 
 \subsection{Quality Goals}
-Quality goals, as defined in Chapter \ref{sec:quality-goals}, should motivate developers to write high-quality code that is easy to customize and maintain.
+Quality goals, as defined in Chapter \ref{sec:quality-goals}, should motivate developers to write high-quality code that is easy to customize and maintain. Concerning the analyzability of Hybrid \ac{OSN}, all modules, classes, methods, and variables were titled with English names. The public methods of the provider classes were documented, and the Clean Code principles were adhered to. 
-
-Concerning the analyzability of Hybrid \ac{OSN}, all modules, classes, methods, and variables were titled with English names. The public methods of the provider classes were documented, and the Clean Code principles were adhered to. 
 
 With JavaScript, the application is written in a language that ranks on eighth place in the TIOBE Index, which measures the popularity of a programming language \cite{tiobe2019index}. At GitHub, JavaScript leads all statistics \cite{github2018programming-language-stats}. Most new repositories are created for JavaScript projects, and most contributions are written in JavaScript. Due to its popularity, many developers should be able to use the Hybrid \ac{OSN} codebase and find their way around quickly. The interfaces to GUN and \ac{IPFS} have been outsourced to individual providers so that they are interchangeable. Thus, the technology can be easily exchanged.
 
-Tests are used to check the proper functioning of the application. For time reasons, this quality goal was neglected for Hybrid \ac{OSN} and thus not achieved. In principle, however, the testing of ionic applications is possible.
+Tests are used to check the proper functioning of the application. For time reasons, this quality goal was neglected for Hybrid \ac{OSN} and thus not achieved. But, in principle, the testing of ionic applications is possible.
 
 The source code should be managed as an open source project to increase confidence in the application. Although version management is used with Git and is also centrally managed on the Git server of the Telecooperation Lab group, the code is not freely accessible here. Thus Hybrid \ac{OSN} cannot be considered an open source application.

thesis/content/06-discussion/threat-model.tex

@@ -2,9 +2,7 @@ In the threat model of Hybrid \ac{OSN} the potential threats for different sub-a
 
 \subsection{Service Provider – Twitter}
 \label{sec:threat-model-service-provider}
-Hybrid \ac{OSN} users can be easily identified by the service provider Twitter, even if they only use the app passively to read private tweets of other users and do not write private tweets themselves.
+Hybrid \ac{OSN} users can be easily identified by the service provider Twitter, even if they only use the app passively to read private tweets of other users and do not write private tweets themselves. For using the Twitter \ac{API}, it is essential to register an app to get an app token. This app token is attached to all requests sent to the Twitter \ac{API}. When logging in on Hybrid \ac{OSN} for the first time, the user accepts to use the app to access Twitter.
-
-For using the Twitter \ac{API}, it is essential to register an app to get an app token. This app token is attached to all requests sent to the Twitter \ac{API}. When logging in on Hybrid \ac{OSN} for the first time, the user accepts to use the app to access Twitter.
 
 So far not implemented, but theoretically possible is that each user creates an app for the use of the \ac{API} on their own. The obtained app token could then be stored in the Hybrid \ac{OSN} app, and the use of the application could be obscured. In this case, the identification possibility via the Hybrid \ac{OSN} app token is omitted, and the passive use would be possible without danger. However, the Twitter developer terms forbid the use of multiple applications for a single use case \cite{twitterXXXXdev-terms}. This restriction is primary for a single developer trying to bypass the request limits. It has to be further evaluated if this rule also applies to multiple developers with only one application each.
 
@@ -12,11 +10,7 @@ Active use requires a public tweet and a reference in the profile description fo
 
 \subsection{GUN}
 \label{sec:threat-model-gun}
-In Hybrid \ac{OSN}, GUN takes the role of a database shared by the peers. The dashboard also establishes a direct connection. The data are publicly accessible and editable.
+In Hybrid \ac{OSN}, GUN takes the role of a database shared by the peers. The dashboard also establishes a direct connection. The data are publicly accessible and editable. The stored data are a combination of hashtag and timestamp, which serve as information for the trends in the Hybrid \ac{OSN} dashboard. For every private tweet of a user, there is an entry consisting of Twitter user id, \ac{IPFS} address hash, and timestamp. Also, there are the private likes, for which there is a counter to the tweet id. For preventing the hashtag and private tweet timestamps from connecting, the time of the hashtag timestamp is set to 00:01. The trends in the dashboard are aggregated by the day, so the exact time is not essential.
-
-The stored data are a combination of hashtag and timestamp, which serve as information for the trends in the Hybrid \ac{OSN} dashboard. For every private tweet of a user, there is an entry consisting of Twitter user id, \ac{IPFS} address hash, and timestamp. Also, there are the private likes, for which there is a counter to the tweet id.
-
-For preventing the hashtag and private tweet timestamps from connecting, the time of the hashtag timestamp is set to 00:01. The trends in the dashboard are aggregated by the day, so the exact time is not essential.
 
 The greatest threat is that an attacker may modify or delete data. By deleting entries, private tweets would no longer be found and thus no longer displayed. Changing the \ac{IPFS} hash would mean that the data could not be found and would also not be displayed. Manipulation of the timestamp would result in private tweets being loaded at the wrong time interval when the feed is loaded and thus positioned at the wrong place. Furthermore, the timestamp in GUN is used to use the appropriate public key from the public key history for decryption. Under certain circumstances, the wrong key would be selected and the private tweet could not be decrypted.
 
@@ -24,9 +18,7 @@ Creating entries for private tweets does not have a significant effect because t
 
 \subsection{\ac{IPFS}}
 \label{sec:threat-model-ipfs}
-Since \ac{IPFS} is publicly accessible, anyone can add and retrieve data. However, it is not possible to change or delete data. A hash of the content addresses the data stored in \ac{IPFS}. Since the content is entirely unknown (especially by encrypting the plaintext content), it is not possible to conclude the hash. A targeted search for private data in \ac{IPFS} is therefore impossible. The encrypted data also does not contain any clues that allow conclusions to be drawn about Hybrid \ac{OSN}.
+Since \ac{IPFS} is publicly accessible, anyone can add and retrieve data. Though, it is not possible to change or delete data. A hash of the content addresses the data stored in \ac{IPFS}. Since the content is entirely unknown (especially by encrypting the plaintext content), it is not possible to conclude the hash. A targeted search for private data in \ac{IPFS} is therefore impossible. The encrypted data also does not contain any clues that allow conclusions to be drawn about Hybrid \ac{OSN}. In combination with the publicly available information from GUN, all private tweet data could be found in \ac{IPFS}. But, because of the encryption of the content, the data are worthless.
-
-In combination with the publicly available information from GUN, all private tweet data could be found in \ac{IPFS}. However, because of the encryption of the content, the data are worthless.
 
 Due to the decentralization of the system, the availability of \ac{IPFS} is always guaranteed. However, only as long as there are peers who make the service possible. If a peer leaves the network, its data are also lost if not reproduced beforehand. Therefore, there is no guarantee for the permanent availability of data.
 
@@ -38,8 +30,6 @@ Disclosure of the source code would reveal the symmetric key. The service provid
 
 \subsection{Authorized Access}
 \label{sec:threat-model-authorized-access}
-A user's private tweets should be readable by all users who can also read the public tweets - except for the service provider Twitter. Therefore, a user posts the \ac{IPFS} hash that leads to the public key history on his timeline.
+A user's private tweets should be readable by all users who can also read the public tweets - except for the service provider Twitter. Therefore, a user posts the \ac{IPFS} hash that leads to the public key history on his timeline. There is a threat that authorized users may create a copy of the decrypted public key history and pass it on to third parties. Since the data in \ac{IPFS} is permanent and therefore not erasable, it can be decrypted at any time later with the appropriate public key.
-
-There is a threat that authorized users may create a copy of the decrypted public key history and pass it on to third parties. Since the data in \ac{IPFS} is permanent and therefore not erasable, it can be decrypted at any time later with the appropriate public key.
 
 If a user decides to change his profile to \enquote{private} in the account settings, the profile will no longer be publicly accessible. Solely accepted followers should then be able to read public and private tweets. A non-approved user is still able to fetch the encrypted private tweets from \ac{IPFS}. However, since the link to the public key history is no longer accessible, the private tweets decryption is not possible. If non-approved users or third parties already have the link to or a backup of the public key history from the past, all private tweets of the past can still be decrypted. Whenever a profile is changed to \enquote{private} a new pair of keys should be generated to ensure that future private tweets are only readable to approved users. Otherwise the latest key is still valid and could be used to encrypt future private tweets.

thesis/content/07-conclusion.tex

@@ -4,13 +4,13 @@ In this chapter, we summarize the work that has been done in this thesis. Beside
 
 \section{Summary}
 \label{sec:summary}
-This thesis first introduced the problems around privacy protection in centralized, well-established \acp{OSN}, and the motivation for this work. Afterward, we provided the relevant background information of software system architectures in general, and in particular for \ac{P2P} networks as well as arising \acp{dApp}. We then presented other approaches trying to increase the user's privacy. To these approaches count extensions which improve the privacy protection during the use of established social networks, decentralized \acp{OSN} including \ac{dApp} \acp{OSN}, which try to serve for better protection by design, and protocols for the communication in distributed networks. Based on the work of the \enquote{Research and Training Group} and their research on \enquote{Privacy Protection via Hybrid Social Networks}, we elaborated a concept for hybrid solutions and defined multiple requirements. Besides, we gave various solution strategies for the implementation of the concept regarding the architecture and the client itself. Then we presented our prototype for Twitter. First, we compared \acp{OSN} and technology and examined their suitability for a proof of concept. Second, we described the architecture and implementation of the Android app. Finally, we discussed to what extent the hybrid \ac{OSN} prototype meets the previously defined requirements including our objectives, the functional and non-function requirements as well as the quality goals. We also analyzed limitations and provided a comprehensive threat model.
+This thesis first introduced the problems around privacy protection in centralized, well-established \acp{OSN}, and the motivation for this work. Afterward, we provided the relevant background information of software system architectures in general, and in particular for \ac{P2P} networks as well as arising \acp{dApp}. Afterwards, we presented other approaches trying to increase the user's privacy. These approaches are extensions for established social networks, decentralized \acp{OSN} including \ac{dApp} \acp{OSN}, and protocols for the communication in distributed networks. Based on the work of the \enquote{Research and Training Group} and their research on \enquote{Privacy Protection via Hybrid Social Networks}, we elaborated a concept for hybrid solutions and defined multiple requirements. Besides, we gave various solution strategies for the implementation of the concept regarding the architecture and the client itself. Then, we presented our prototype for Twitter. First, we compared \acp{OSN} and technology and examined their suitability for a proof of concept. Second, we described the architecture and implementation of the Android app. Finally, we discussed to what extent the hybrid \ac{OSN} prototype meets the previously defined requirements including our objectives, the functional and non-function requirements as well as the quality goals. We also analyzed limitations and provided a comprehensive threat model.
 
 \section{Contributions}
 \label{sec:contributions}
 In the work presented in this thesis, first, we took up the idea of a hybrid \ac{OSN} from the Research and Training group. This idea about an extension for secure and private data exchange in established \acp{OSN} was examined and enriched with precise requirements. These demands involve functional and non-functional requirements, as well as quality goals to ensure a good code quality when implementing. Furthermore, we evaluated the opinions and needs of different stakeholders and discussed restrictions. Conclusive, we presented possible solution strategies.
 
-To prove the feasibility of the hybrid \ac{OSN} concept, we created a unique prototype for Twitter as an Android app. This proof of concept uses the technologies GUN and \ac{IPFS} to provide its users with the possibility of a secure data exchange while still using the default functionality of the \ac{OSN}. We worked out a solution to save data in a flexible, extensible \ac{JSON} format and protect it through the application of symmetrical and asymmetrical encryption algorithms. To the further noticeable features count a user-friendly interface and the avoidance of side effects to other users caused by the use of Hybrid \ac{OSN}. Since the need for configuration was kept on an absolute minimum, everyone is capable of protecting its data by using this app. A dashboard showing the trends in the private network was made to provide the service provider with anonymized data.
+To prove the feasibility of the hybrid \ac{OSN} concept, we created a unique prototype for Twitter as an Android app. This proof of concept uses the technologies GUN and \ac{IPFS} to provide its users with the possibility of a secure data exchange while still using the default functionality of the \ac{OSN}. We worked out a solution to save data in a flexible, extensible \ac{JSON} format and protect it through the application of symmetrical and asymmetrical encryption algorithms. Further noticeable features include a user-friendly interface and the avoidance of side effects to other users caused by the use of Hybrid \ac{OSN}. Since the need for configuration was kept on an absolute minimum, everyone is capable of protecting its data by using this app. A dashboard showing the trends in the private network was made to provide the service provider with anonymized data.
 
 Finally, the evaluation of the prototype against the previously defined requirements demonstrated that the concept is feasible. However, it also became clear that not all requirements are completely fulfillable and the application of the concept to other \ac{OSN} may be very challenging.
 
@@ -20,10 +20,10 @@ The contributions and the presented results of this thesis provide several possi
 
 While GUN solves the problem of a distributed database, it has various limitations and was furthermore identified as a weak point in the threat model. In future work, either the usage of GUN could be improved, or a better solution for a distributed database could be found and implemented.
 
-Field studies of users using the Hybrid \ac{OSN} app could be made as for future work to validate user acceptance of the solution. By learning from the usage behavior, the app could be further optimized to encourage the use of the Hybrid \ac{OSN} app and also improve the concept of a hybrid solution.
+Field studies of users using the Hybrid \ac{OSN} app could be performed as for future work to validate user acceptance of the solution. Through analysis of the user behavior, the app could be optimized to encourage usage of the hybrid ONS app. Additionally, it could improve the concept of hybrid solutions.
 
-Another possible area for future work can be carried out on the anonymized data sharing with the service provider. In-depth analysis of the service provider's demands and the available private date need to be carried out. It has to be evaluated which kind of anonymized data are worthy for the service provider.
+Another topic for future work is the anonymized data sharing with the service provider. In-depth analysis of the service provider's demands and the available private date need to be carried out. It has to be evaluated which kind of anonymized data are worthy for the service provider.
 
-The worked out concept was validated primarily for Twitter. Therefore, an exciting area for future work could be the precise validation for other \acp{OSN}, like Facebook, Instagram or Snapchat. By applying the concept to other \acp{OSN}, the stated requirements could be further refined and thus the overall concept further improved.
+In this thesis, the developed concept was validated for Twitter. Therefore, it would be an exciting challenge to apply the concept to other \acp{OSN}, like Facebook, Instagram or Snapchat. By applying the concept to other \acp{OSN}, the stated requirements could be further refined and thus the overall concept further improved.
 
 Regarding the implementation of hybrid solutions in general, future work could examine how a framework providing the basic functionality of distributed \ac{P2P} extensions may look like. Since they all need to store and retrieve data somehow, basic functions provided via a clean interface by a library could improve the creation of hybrid clients for all any platform.