Browse Source

final corrections

Carsten Porth 5 years ago
parent
commit
44a529bc7e

+ 6 - 0
thesis/bib/bibliography.bib

@@ -618,4 +618,10 @@
   isbn      = {0132126958, 9780132126953},
 }
 
+@Misc{mastodonXXXXstats,
+  title        = {{The Federation - a statistics hub | Mastodon stats}},
+  howpublished = {\url{https://the-federation.info/mastodon}},
+  note         = {Online, accessed 22.03.2019},
+}
+
 @Comment{jabref-meta: databaseType:bibtex;}

+ 3 - 3
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.
+Trotz zahlreicher Skandale um den Datenschutz in etablierten sozialen Netzwerken (Facebook, Google+), erfreuen sich die Plattformen noch immer großer Beliebtheit. Alternativen sozialen Netzwerken, 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 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 Ziel dieser Thesis war die Ausarbeitung eines Konzepts für ein hybrides \acf{OSN} 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 \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.
+Das Ergebnis zeigt, dass das Konzept umsetzbar ist und die definierten Ziele zu einer qualitativ hochwertigen Lösung führen. Der Hybrid \ac{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.

+ 3 - 3
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.
+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 notwithstanding 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 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 goal of this thesis was to work out a concept for a hybrid \acf{OSN} 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 \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.
+The result shows that the concept is implementable and that the defined goals lead to a high-quality solution. The Hybrid \ac{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.

+ 4 - 4
thesis/content/01-introduction.tex

@@ -1,6 +1,6 @@
 \chapter{Introduction}
 \label{ch:introduction}
-The World Wide Web celebrated its 30th birthday in March 2019. From the beginning in 1989 up to now, the Internet has evolved and has changed the lives of many people forever. Thanks to digitalization, analog processes such as banking and shopping can now be handled conveniently online. Moreover, the ongoing technology improvements catalyze the digitalization and make it possible to be online almost anywhere. The Internet is also not stopping at the digitalization of social life. Social networks like MySpace and Facebook became popular at the beginning of the 2000s, enabling networking with other users and sharing personal content. Social networks are still very popular today. Facebook, the largest \acf{OSN}, has 2.3 billion active users per month, connecting almost a third of the world's population \cite{facebook2019reportq4}. With the use of such social platforms, the user makes himself a transparent for the service provider of the \ac{OSN}. Personal data is a valuable asset whose protection is of particular importance. By using the platform and sharing this information, the user puts trust in the service provider. Trust that his data will be handled responsibly, stored securely, and not made available to third parties. However, the past has taught us that this is not always the case. Several incidents became public proving the lack of protection and the misuse of personal data on \acp{OSN}.
+The World Wide Web celebrated its 30th birthday in March 2019. From the beginning in 1989 up to now, the Internet has evolved and has changed the lives of many people forever. Thanks to digitalization, analog processes such as banking and shopping can now be handled conveniently online. Moreover, the ongoing technology improvements catalyze the digitalization and make it possible to be online almost anywhere. The Internet is also not stopping at the digitalization of social life. Social networks like MySpace and Facebook became popular at the beginning of the 2000s, enabling networking with other users and sharing personal content. Social networks are still very popular today. Facebook, the largest \acf{OSN}, has 2.3 billion active users per month, connecting almost a third of the world's population \cite{facebook2019reportq4}. With the use of such social platforms, the user makes himself transparent for the service provider of the \ac{OSN}. Personal data are a valuable asset whose protection is of particular importance. By using the platform and sharing this information, the user puts trust in the service provider. Trust that his data will be handled responsibly, stored securely, and not made available to third parties. However, the past has revealed that this is not always the case. Several incidents became public showing the lack of protection and the misuse of personal data on \acp{OSN}.
 
 \section{Motivation}
 \label{sec:motivation}
@@ -12,12 +12,12 @@ The binding to the respective \ac{OSN} is so strong that switching to another, m
 
 \section{Contribution}
 \label{sec:contribution}
-The goal of this work is to define the requirements for a hybrid solution and to prove its feasibility in the form of a prototype. Within the scope of the concept for a hybrid solution, the requirements for the \ac{OSN}, the hybrid client app and the network for secure data exchange have to be defined, and potential problems and limitations have to be identified. Based on these requirements, the elaboration of solution strategies for the implementation is possible. 
+The goal of this work is to define the requirements for a hybrid solution and to prove its feasibility in the form of a prototype. Within the scope of the concept for a hybrid solution, the requirements for the \ac{OSN}, the hybrid client app and the network for secure data exchange have to be defined as well as potential problems and limitations. Based on these requirements, the elaboration of solution strategies for the implementation is possible. 
 
 For the prototype, an Android application that exchanges private data with other users via a \ac{P2P} network is created. The previously defined requirements should be fulfilled in the best possible way. Both the selection of the \ac{OSN} and the technologies used need to be carefully evaluated.
 
-With the Hybrid \ac{OSN} app for Twitter, we present a solution that allows private data to be shared securely with other users of the same app without complicated configuration. Thus, everyone can protect their privacy and still use the usual features of the \ac{OSN}.
+With the Hybrid \ac{OSN} app for Twitter, we present a solution that allows private data to be shared securely with other users of the same app without complicated configuration. Thus, everyone can protect their privacy and still use Twitter as before.
 
 \section{Outline}
 \label{sec:outline}
-The remainder of this thesis is structured as follows. In Chapter \ref{ch:background}, a comprehensive overview of different network and system architectures is given for a better understanding of this work. In particular, the basics of software system architectures and their characteristics are described, as well as \ac{P2P} networks and \acp{dApp}.  Chapter \ref{ch:related-work} is about relevant work and projects in the context of this thesis. In Chapter \ref{ch:concept}, the general concept of a hybrid \ac{OSN} is discussed, and requirements to the solution are defined. Furthermore, several solution strategies are carried out. Chapter \ref{ch:proof-of-concept} describes our implementation of the concept in the form of an Android app for the hybrid use of Twitter. The design decisions and architecture are considered as well.  Chapter \ref{ch:evaluation} evaluates the Hybrid \ac{OSN} prototype with the previously defined requirements. Besides, the limitations and threats are discussed. Finally, Chapter \ref{ch:conclusions} summarizes this work and gives an outlook for future work.
+The remainder of this thesis is structured as follows. In Chapter \ref{ch:background}, a comprehensive overview of different network and system architectures is given for a better understanding of this work. In particular, the basics of software system architectures and their characteristics are described, as well as \ac{P2P} networks and \acp{dApp}.  Chapter \ref{ch:related-work} is about relevant work on privacy protection and projects in the context of this thesis. In Chapter \ref{ch:concept}, the general concept of a hybrid \ac{OSN} is discussed, and requirements to the solution are defined. Furthermore, several solution strategies are carried out. Chapter \ref{ch:proof-of-concept} describes our implementation of the concept in the form of an Android app for the hybrid use of Twitter. The design decisions and architecture are considered as well.  Chapter \ref{ch:evaluation} evaluates the Hybrid \ac{OSN} prototype with the previously defined requirements. Besides, the limitations and threats are discussed. Finally, Chapter \ref{ch:conclusions} summarizes this work and gives an outlook for future work.

+ 4 - 8
thesis/content/02-background/dapps.tex

@@ -1,4 +1,4 @@
-The term Web 1.0 refers to the beginnings of the Internet, which consisted of simple static web pages. The central idea was to present or consume content. The characteristic of Web 2.0 is the user's participation in the creation process. Thus, a series of platforms (blogs, social networks) was launched on which users can provide content and connect. Typically, Web 2.0 platforms have a centralized structure, which entails the problems mentioned in the previous chapter. On the occasion of the 30th anniversary of the World Wide Web in March 2019, the initiator Tim Berners-Lee summed up that the Internet was misused - partly due to the system design \cite{berners-lee2019web30}.
+The term Web 1.0 refers to the beginnings of the Internet, which consisted of simple static web pages. The central idea was to present or consume content. The characteristic of Web 2.0 is the user's participation in the creation process. Thus, a series of platforms (blogs, social networks) was launched on which users can provide content and connect to each other. Typically, Web 2.0 platforms have a centralized structure, which entails the problems mentioned in the previous chapter. On the occasion of the 30th anniversary of the World Wide Web in March 2019, the initiator Tim Berners-Lee summed up that the Internet was misused - partly due to the system design \cite{berners-lee2019web30}.
 
 With the next version 3.0 of the web, more transparency, security, and fairness should be created. However, while there is broad agreement on what is meant by terms Web 1.0 and Web 2.0, there is no uniform definition of Web 3.0 that has prevailed to date. There are many ideas, but no final solution yet. An interpretation of what Web 3.0 is, is all about decentralization, hence it is also called the \acf{dWeb}. In this context, Web 3.0 is considered an umbrella term for a group of emerging technologies such as blockchain, crypto currencies, and distributed systems which are interconnected to create novel applications, so-called \acf{dApp}. Although decentralized applications have existed for a long time (e.g., BitTorrent), these applications do not meet the criteria of a \ac{dApp}.
 
@@ -18,16 +18,12 @@ Johnston et al. and Siraj Raval name the following four criteria for a \ac{dApp}
 In addition to the criteria of a \ac{dApp}, Johnston et al. also describe a classification system for \acp{dApp} considering if they have their own blockchain or they use another \ac{dApp}'s blockchain \cite{johnston2015dapp}:
 
 \begin{itemize}
-	\item \textbf{Type 1}: Use their own blockchain (e.g. Bitcoin, Ethereum, EOS).
-	\item \textbf{Type 2}: Protocols, to use another blockchain of type 1 with own tokens (e.g. Omni Protocol).
+	\item \textbf{Type 1}: Use their own blockchain (e.g., Bitcoin, Ethereum, EOS).
+	\item \textbf{Type 2}: Protocols, to use another blockchain of type 1 with own tokens (e.g., Omni Protocol).
 	\item \textbf{Type 3}: Protocols with own tokens, which in turn use protocols of a \ac{dApp} of type 2.
 \end{itemize}
 
-Over 1900 dApps use the Ethereum platform \cite{dappsXXXXstats} and in terms of market capitalization, 94 of the top 100 tokens base on Ethereum \cite{dappsXXXXtokens}. Ethereum is a public, decentralized blockchain and at the same time a system for the execution of smart contracts. The associated token is called \ac{ETH} and is required to execute the smart contracts on the \ac{EVM}.
-
-Since the storage of large amounts of data in the blockchain is expensive, the data are often stored elsewhere, and only one reference is written into the blockchain. \ac{IPFS} has become the preferred decentralized storage location.
-
-Examples of \acp{dApp} that use the Ethereum - \ac{IPFS} combination are the social networks Peepeth and AKASHA, which are introduced in the following chapter.
+Over 1900 dApps use the Ethereum platform \cite{dappsXXXXstats} and in terms of market capitalization, 94 of the top 100 tokens base on Ethereum \cite{dappsXXXXtokens}. Ethereum is a public, decentralized blockchain and at the same time a system for the execution of smart contracts. The associated token is called \ac{ETH} and is required to execute the smart contracts on the \ac{EVM}. Since the storage of large amounts of data in the blockchain is expensive, the data are often stored elsewhere, and only one reference is written into the blockchain. \ac{IPFS} has become the preferred decentralized storage location. Examples of \acp{dApp} that use the Ethereum - \ac{IPFS} combination are the social networks Peepeth and AKASHA, which are introduced in the following chapter.
 
 Among the disadvantages of \acp{dApp} are the costs associated with actions and the handling of tokens. The tokens are stored in a wallet, and this wallet has to be accessible by the \ac{dApp}. Therefore, a special web browser or an extra browser add-on is required. Before the first usage, the user has to obtain the token somehow. The acquisition is usually complex and therefore represents a barrier for some users to use the application. Because of this, unfortunately, only experienced users can fulfill the prerequisites to use a \ac{dApp}.
 

+ 7 - 15
thesis/content/02-background/software-system-architecture.tex

@@ -24,33 +24,25 @@ The software system architecture describes the relationships and properties of i
 
 \subsection{Centralized Applications}
 \label{sec:centralized-applications}
-In a centralized application (see Figure \ref{fig:architecture-centralized}), the software essentially runs on a central node with a static address with which all other nodes communicate. This central node is called a server and the nodes connected to it are called clients. The clients use the services of the server.
+In a centralized application (see Figure \ref{fig:architecture-centralized}), the software essentially runs on a central node with a static address with which all other nodes communicate. This central node is called a server and the nodes connected to it are called clients. The clients use the services of the server. Typically, web applications are designed as centralized applications. The clients are usually (mobile) apps or browsers that act as the interface to the user. Examples are social networks such as Facebook and Twitter.
 
-Typically, web applications are designed as centralized applications. The clients are usually (mobile) apps or browsers that act as the interface to the user. Examples are social networks such as Facebook and Twitter.
+The advantages of a centralized architecture include that new clients can easily join the system simply by connecting to the server. Also, the maintenance of the software is easy to perform, since only the server node needs to be updated. These structures are also advantageous for the speed and the associated user experience since servers are generally reachable via fast connections, have sufficient resources and do not need to use complicated routes across several nodes. Due to the special role of the server, the authentication of a client in the system is easy to perform. Only the server has to check whether the client performs the actions to which it is authorized and can intervene if necessary. If a client is offline, this has no negative impact on the architecture because the software essentially runs on the server. Clients only need to have low resources.
 
-The advantages of a centralized architecture include that new clients can easily join the system simply by connecting to the server. Also, the maintenance of the software is easy to perform, since only the server node needs to be updated. These structures are also advantageous for the speed and the associated user experience since servers are generally reachable via fast connections, have sufficient resources and do not need to use complicated routes across several nodes. Due to the special role of the server, the authentication of a client in the system is easy to perform. Only the server has to check whether the client solely performs the actions to which it is authorized and can intervene if necessary. If a client is offline, this has no negative impact on the architecture because the software essentially runs on the server. Clients only need to have low resources.
-
-The biggest disadvantage with this architecture is that failure or the blockade of the server leads to a collapses of the entire system. So, the server is the single point of failure of the whole system. Due to the design, the server has all the data. This makes him not only a popular target for hackers but also brings the clients into total dependency on the server. 
-
-With regard to web platforms like Facebook, having access to all the data can be used to provide an improved user experience by adapting the software to the user's needs. But it can also be used for targeted advertising or sensible data can even get sold to third parties. Furthermore, the server decides which data to send to the client, which brings with it the danger of censorship. As the number of clients increases, the server must scale to have sufficient resources.
+The biggest disadvantage with this architecture is that failure or the blockade of the server leads to a collapses of the entire system. So, the server is the single point of failure of the whole system. Due to the design, the server has all the data. This makes him not only a popular target for hackers but also brings the clients into total dependency on the server. With regard to web platforms like Facebook, having access to all the data can be used to provide an improved user experience by adapting the software to the user's needs. But it can also be used for targeted advertising or sensible data can even get sold to third parties. Furthermore, the server decides which data to send to the client, which brings with it the danger of censorship. As the number of clients increases, the server must scale to have sufficient resources.
 
 \subsection{Decentralized Applications}
 \label{sec:decentralized-applications}
-What are the advantages and disadvantages of centralized applications, is mostly reversed in decentralized systems. Unlike centralized applications, decentralized applications do not have a single point of failure (see Figure \ref{fig:architecture-decentralized}). However, there is no node in the system that has all the data which makes accessing information sometimes hard. There is any number of nodes that perform the tasks of a server and by exchanging with other servers in total form a complete system.
+What are the advantages and disadvantages of centralized applications, is mostly reversed in decentralized systems. Unlike centralized applications, decentralized applications do not have a single point of failure (see Figure \ref{fig:architecture-decentralized}). However, there is no node in the system that has all the data which makes accessing information sometimes hard. There are any number of nodes that perform the tasks of a server and by exchanging with other servers in total form a complete system.
 
-Another advantage is that each server only handles the number of users covered by its resources. New servers contribute additional resources to the overall system. Distributed applications cannot be disabled easily because a new server can be started at any time that does not fall under a lock. Because the data are not centrally available, they cannot be processed, so that user data are better protected. Also, there is no longer a prominent attack target. So, hacking a single server loses lucrativeness.
+Another advantage is that each server only handles the number of users covered by its resources. New servers contribute additional resources to the overall system. Distributed applications cannot be disabled easily because a new server can be started at any time that does not fall under a lock. Because the data are not centrally available, they cannot be processed, so that user data are better protected. Also, there is no longer a prominent attack target. Hence, hacking a single server loses lucrativeness.
 
-The drawbacks include the difficulty of finding data because they are spread across multiple servers. Search functionalities are thus difficult to implement. If a server is taken offline, the data are no longer available, even if the system itself remains functional. To tackle this issue, data needs to be replicated. Since there is no longer a central point that is managed by an operator, rolling out updates is difficult. This raises the challenge that server nodes of different versions of the same application can still work together.
+The drawbacks include the difficulty of finding data because they are spread across multiple servers. Search functionalities are thus hard to implement. If a server is taken offline, the data are no longer available, even if the system itself remains functional. To tackle this issue, data needs to be replicated. Since there is no longer a central point that is managed by an operator, rolling out updates is difficult. This raises the challenge that server nodes of different versions of the same application can still work together.
 
 Examples of decentralized applications are the social networks diaspora* and Mastodon. In these networks, each user can operate a server on his own. Unlike Facebook, the decision on the existence of the service is therefore not in the control of the operator, but the user.
 
 \subsection{Distributed Applications}
 \label{sec:distributed-applications}
-A feature of distributed applications is the computation across all nodes (see Figure \ref{fig:architecture-distributed}). At the same time, a single task is executed in parallel on several nodes of a system, and the entire system delivers the result in total. The boundaries between decentralized and distributed networks are becoming blurred. A decentralized network consisting only of servers corresponds quasi to a distributed network.
-
-In distributed applications, there is no hierarchy with servers or clients. Each node is equal to the other nodes with everyone performing the same tasks. For this reason, a node in this architecture is called a peer. The structure is then referred to as \ac{P2P}. With such structures, there are no scaling problems, since each node contributes the required resources itself. Thus, the resources of the entire system grow with each new node added.
-
-BitTorrent is an application that belongs to this architecture type. It solves the problem of downloading large files efficiently. When downloading a file, it is offered by several nodes so that different pieces can be loaded in parallel from various sources in difference to \ac{HTTP} where only one source provides the file. Each peer not only downloads files but also provides files to other users. In order to avoid that nodes solely download (so-called Leechers) but also contribute, they are penalized with slow download speeds. This principle is known as \textit{tit for tat}.
+A feature of distributed applications is the computation across all nodes (see Figure \ref{fig:architecture-distributed}). At the same time, a single task is executed in parallel on several nodes of a system, and the entire system delivers the result in total. The boundaries between decentralized and distributed networks are blurred. A decentralized network consisting only of servers corresponds quasi to a distributed network. In distributed applications, there is no hierarchy with servers or clients. Each node is equal to the other nodes with everyone performing the same tasks. For this reason, a node in this architecture is called a peer. The structure is then referred to as \acf{P2P}. With such structures, there are no scaling problems, since each node contributes the required resources itself. BitTorrent is an application that belongs to this architecture type. It solves the problem of downloading large files efficiently. When downloading a file, it is offered by several nodes so that different pieces can be loaded in parallel from various sources in difference to \ac{HTTP} where only one source provides the file. Each peer not only downloads files but also provides files to other users. In order to avoid that nodes solely download (so-called Leechers) but also contribute, they are penalized with slow download speeds. This principle is known as \textit{tit for tat}.
 
 \subsection{Comparison}
 \label{sec:architecture-comparison}

+ 2 - 2
thesis/content/03-related-work/activitypub.tex

@@ -8,7 +8,7 @@ Users are called actors in ActivityPub and are represented by an associated acco
 
 \begin{figure}[h!]
 	\includegraphics[width=1.0\textwidth]{activitypub-communication}
-	\caption{Concept of the Social \ac{API} protocol: The user fetches messages with an \ac{HTTP} GET request to his inbox and posts messages using an \ac{HTTP} POST request. The inbox is filled by \ac{HTTP} POST requests from other users. \cite{w3c2018activity-pub}}
+	\caption{Concept of the Social \ac{API} protocol: The actor fetches messages with an \ac{HTTP} GET request to his inbox and posts messages using an \ac{HTTP} POST request. The inbox is filled by \ac{HTTP} POST requests from other actors. \cite{w3c2018activity-pub}}
 	\label{fig:activitypub-communication}
 \end{figure}
 
@@ -30,7 +30,7 @@ This protocol defines the exchange of activities between actors of different ser
 
 \subsubsection{Application Examples}
 \label{sec:mastodon}
-The most popular application example is the social network Mastodon\footnote{https://joinmastodon.org/}. Mastodon is a decentralized network based on free and open source software. Everyone is invited to host their own platform. With currently 1.6 million users it is the most significant implementation of the ActivityPub Protocol. The Federation Protocol is used for communication between the individual servers. The Social \ac{API} is not used, instead Mastodon offers its own \ac{API}\footnote{https://docs.joinmastodon.org/api/guidelines/} for communication with the client.
+The most popular application example is the social network Mastodon\footnote{https://joinmastodon.org/}. Mastodon is a decentralized network based on free and open source software. Everyone is invited to host their own platform. With currently 2 million users it is the most significant implementation of the ActivityPub Protocol \cite{mastodonXXXXstats}. The Federation Protocol is used for communication between the individual servers. The Social \ac{API} is not used, instead Mastodon offers its own \ac{API}\footnote{https://docs.joinmastodon.org/api/guidelines/} for communication with the client.
 
 Networking with other users is not limited to mastodon instances. Each service that has implemented the ActivityPub Protocol allows its actors to network with actors of entirely different applications because the communication is standardized. So it is possible without problems to follow an actor of the video platform PeerTube\footnote{https://joinpeertube.org/en/} as Mastodon actor and be notified when he uploads a new video there.
 

+ 2 - 2
thesis/content/03-related-work/akasha.tex

@@ -1,10 +1,10 @@
-In early 2015, Mihai Alisie (co-founder of Ethereum) had the idea for AKASHA. AKASHA is a social network that differs from other known social networks mainly in its decentralization. The absence of a central server meant that censorship was ruled out by design. This is realized by the two technologies Ethereum and the \acf{IPFS}. Electron, React, Redux, and NodeJS complete the technology stack so that the primary programming language is JavaScript \cite{akasha2016unveiling}. In addition to Mihai Alisie, ten other employees now work at AKASHA. Furthermore, the founders of Ethereum (Vitalik Buterin) and \ac{IPFS} (Juan Benet) advise the project \cite{akasha2016advisors}.
+In early 2015, Mihai Alisie (co-founder of Ethereum) had the idea for AKASHA. AKASHA is a social network that differs from other known social networks mainly in its decentralization and use of the blockchain. The absence of a central server meant that censorship was ruled out by design. This is realized by the two technologies Ethereum and the \acf{IPFS}. Electron, React, Redux, and NodeJS complete the technology stack so that the primary programming language is JavaScript \cite{akasha2016unveiling}. In addition to Mihai Alisie, ten other employees work at AKASHA. Furthermore, the founders of Ethereum (Vitalik Buterin) and \ac{IPFS} (Juan Benet) advise the project \cite{akasha2016advisors}.
 
 Alisie sees AKASHA as \enquote{the missing puzzle piece that will enable us to tackle two of the most critical challenges we face today as a modern information-based society: freedom of expression and creative perpetuity}\cite{akasha2016unveiling}. The central goal is therefore to prevent censorship and to obtain information over a long period.
 
 AKASHA offers the typical functionalities known from other social networks. These include creating a profile and connect with other profiles. Posting content and commenting on other entries. Furthermore, there is a message system and the possibility to tip other users. Instead of a central server, AKASHA uses the Ethereum testnet Rinkeby and \ac{IPFS} to store data, so AKASHA can be called a \ac{dApp}. The messaging system is implemented via Whisper. \ac{ETH} is required to execute all actions in order to write to the blockchain, but this can be easily requested in the test network.
 
-After a proof of concept had validated the idea, the technology stack mentioned above was defined, and development began at the beginning of 2016. The first goal was to create a client based on Electron for Windows, Linux, and MacOS. In January 2017, the first functional alpha version was completed and tested with a closed circle of users. Over time, additional functions were added, bugs fixed, and performance optimized. In November 2017, a web version of AKASHA\footnote{https://beta.akasha.world/} was introduced. This was a big step towards a better user experience since the web client does not need to download the Ethereum Rinkeby blockchain which took around 30\,minutes on the first run. But, the web version only works in browsers running MetaMask and \ac{IPFS} Companion extensions. The public beta phase started in February 2018 with the primary goal to see how the application behaves under heavy load.
+After a proof of concept had validated the idea, the technology stack mentioned above was defined, and development began at the beginning of 2016. The first goal was to create a client based on Electron for Windows, Linux, and MacOS. In January 2017, the first functional alpha version was completed and tested with a closed circle of users. Over time, additional functions were added, bugs fixed, and performance optimized. In November 2017, a web version of AKASHA\footnote{https://beta.akasha.world/} was introduced. This was a big step towards a better user experience since the web client does not need to download the Ethereum Rinkeby blockchain which took around 30\,minutes on the first run. But, the web version only works in browsers running MetaMask and \ac{IPFS} Companion extensions. The public beta phase started in February 2018 with the primary goal to see how the application behaves under heavy load. \cite{akasha2016unveiling,akasha2017horizons}
 
 With the announcement of the web version, the team behind AKASHA also introduced their own AETH token. This token has the unique feature that it can take different states. By locking AETH, the user receives \textit{Mana} which regenerates every day as long as the AETH remains locked. Performing interactions, for example liking, commenting or publishing posts, consumes \textit{Mana} and \ac{ETH}, but not AETH. When \textit{Mana} is used to vote for something, the content's author receives the same amount as \textit{Essence} which can be converted into new AETH tokens. The third state is called \textit{Karma} and functions as a all time score of received \textit{Essence} even though it has been used to mint AETH. \textit{Karma} is necessary to unlock new features inside AKASHA. \cite{akasha2017horizons}
 

+ 2 - 2
thesis/content/03-related-work/diaspora.tex

@@ -12,8 +12,8 @@ The diaspora* back end is written in Ruby, the front end to the user is a websit
 
 For staying in contact with friends on other platforms like social networks (Facebook, Twitter) or blogs (Tumblr, Wordpress), the initial idea was to connect these platforms. Data exchange should work both ways. Posts published on diaspora* should also appear on other platforms at the same time. Also, posts from the other networks should be viewed in diaspora*. Diaspora* should play the role of a social media hub. Unfortunately, the \acp{API} of some platforms have become increasingly limited as instances of misuse of the interfaces have become public.
 
-The data of the users are unencrypted on a pod so that someone having access to the database can see them \cite{diasporaXXXXfaq-users}. In order to protect his own data in the best possible way, the operation of a separate diaspora* instance is necessary. The communication between the pods is encrypted with \ac{SSL} protocol \cite{diasporaXXXXfaq-users}. Furthermore, the exchanged messages are first signed (Salmon Magic Signatures), then symmetrically encrypted with \ac{AES}-256-\ac{CBC} \cite{diasporaXXXXmagic-signatures}. The \ac{AES} key is encrypted with the public key of the recipient and sent together with the encrypted message.
+The data of the users are stored unencrypted on a pod so that someone having access to the database can see them \cite{diasporaXXXXfaq-users}. In order to protect his own data in the best possible way, the operation of a separate diaspora* instance is necessary. The communication between the pods is encrypted with \ac{SSL} protocol \cite{diasporaXXXXfaq-users}. Furthermore, the exchanged messages are first signed (Salmon Magic Signatures), then symmetrically encrypted with \ac{AES}-256-\ac{CBC} \cite{diasporaXXXXmagic-signatures}. The \ac{AES} key is encrypted with the public key of the recipient and sent together with the encrypted message.
 
-Diaspora* does not use the ActivityPub protocol, but its own diaspora* federation protocol\cite{diasporaXXXXprotocol}. Other platforms such as Friendica\footnote{https://friendi.ca/}, Hubzilla\footnote{https://zotlabs.org/page/hubzilla/hubzilla-project} or Socialhome\footnote{https://socialhome.network/} can also communicate via the diaspora* federation protocol. There is no official \ac{API}, which makes app development difficult. Diaspora* points out that the website is also usable on mobile devices, so there is no need for a native application \cite{diasporaXXXXfaq-users}.
+Diaspora* does not use the ActivityPub protocol (see Chapter \ref{sec:activitypub}), but its own diaspora* federation protocol\cite{diasporaXXXXprotocol}. Other platforms such as Friendica\footnote{https://friendi.ca/}, Hubzilla\footnote{https://zotlabs.org/page/hubzilla/hubzilla-project} or Socialhome\footnote{https://socialhome.network/} can also communicate via the diaspora* federation protocol. There is no official \ac{API}, which makes app development difficult. Diaspora* points out that the website is also usable on mobile devices, so there is no need for a native application \cite{diasporaXXXXfaq-users}.
 
 According to the statistics of the-federation.info on 24$ ^{th} $ February 2019, 679\,723 users were registered on a total of 251 pods. Over the last 12 months, 19\,591 new users have joined the network. In January 2019, only 30\,042 (4.4\,\%) users were active. However, the numbers are incomplete, as some pods do not share information and there may be more than the 251 listed pods. \cite{diasporaXXXXstats}

+ 2 - 2
thesis/content/03-related-work/facecloak.tex

@@ -1,4 +1,4 @@
-Researchers Luo, Xiu, and Hengartner of the University of Waterloo in Ontario propose an architecture to protect personal information on social networking platforms \cite{luo2009facecloak}. Protection is achieved by transmitting fake data to the social network server and storing the correct data encrypted on a third party server. Authorized users can then replace the fake data with the correct data when they visit the site containing protected data. The prerequisite is that all users use a specific browser extension that communicates with the third party server and replaces content. In concrete terms, this was implemented for Facebook and both a server and an extension for the Firefox browser were created and successfully tested.
+Researchers Luo, Xiu, and Hengartner of the University of Waterloo in Ontario propose an architecture to protect personal information on social networking platforms \cite{luo2009facecloak}. Protection is achieved by transmitting fake data to the social network server and storing the real data encrypted on a third party server. Authorized users can then replace the fake data with the correct data when they visit the site containing protected data. The prerequisite is that all users use a specific browser extension that communicates with the third party server and replaces content. In concrete terms, this was implemented for Facebook and both a server and an extension for the Firefox browser were created and successfully tested.
 
 \subsubsection{Design Principles}
 FaceCloak's design is based on the following four principles:
@@ -31,7 +31,7 @@ In addition to adhering to the above design principles, the proposed architectur
 \end{itemize}
 
 \subsubsection{FaceCloak for Facebook}
-To protect the privacy of Facebook users, Luo, Xiu, and Hengartner have created a Firefox browser extension according to the previously described architecture, as well as a server application for storing encrypted real data \cite{facecloakXXXXdownload}. The extension uses \ac{AES} and a key length of 128 bits to encrypt the data. The indices for the encrypted data are calculated using SHA-1. The authors propose an e-mail for the key exchange. For this purpose, the browser extension automatically generates e-mail texts and recipient lists and forwards them to the standard e-mail program. The recipients then have to store the received keys in the extension manually.
+To protect the privacy of Facebook users, Luo, Xiu, and Hengartner have created a Firefox browser extension according to the previously described architecture, as well as a server application for storing encrypted real data \cite{facecloakXXXXdownload}. The extension uses \ac{AES} and a key length of 128 bits to encrypt the data. The indices for the encrypted data are calculated using SHA-1. The authors propose an e-mail for the key exchange. For this purpose, the browser extension automatically generates e-mail texts and recipient lists and forwards them to the standard e-mail client. The recipients then have to store the received keys in the extension manually.
 
 In order to protect data with FaceCloak, the prefix @@ must be added to the information in a text field. For other form elements such as dropdowns, radio buttons or checkboxes, the extension creates additional options that also start with @@. When submitting the form, the extension intervenes and replaces the data marked with @@ with fake data. The data to be protected are encrypted with the stored keys and transferred as a key-value pair to the third party server where it is stored. FaceCloak can protect all profile information, but only for name, birthday, and gender algorithms for the meaningful creation of fake data are implemented. In addition to profile information, the extension can also protect Facebook Wall and Facebook Notes data. The contents of arbitrary Wikipedia articles are transmitted as fake data to avoid attracting attention with random and unusual character strings.
 

+ 2 - 4
thesis/content/03-related-work/lifesocial.tex

@@ -34,9 +34,7 @@ In order to store the data effectively, Graffi introduced the Distributed Linked
 
 \subsubsection{Security}
 \label{sec:lifesocial-security}
-When registering, a new user enters a user name and password. The password is used to generate a key pair for asymmetric encryption. The public key serves as user id and node id at the same time.
-
-All data are encrypted for secure and authenticated communication. A new symmetric key is generated for each data object (so-called \texttt{SharedItem}) and used to encrypt the data. The symmetric key is then encrypted asymmetrically with the recipient's public keys and added to the shared item to an \ac{ACL}. Users who are not in the \ac{ACL} cannot decrypt the symmetric keys and therefore have no access to the data. Finally, the shared item is signed by the author. Signed \texttt{SharedItems} are called \texttt{CryptedItems}.
+When registering, a new user enters a user name and password. The password is used to generate a key pair for asymmetric encryption. The public key serves as user id and node id at the same time. All data are encrypted for secure and authenticated communication. A new symmetric key is generated for each data object (so-called \texttt{SharedItem}) and used to encrypt the data. The symmetric key is then encrypted asymmetrically with the recipient's public keys and added to the shared item to an \ac{ACL}. Users who are not in the \ac{ACL} cannot decrypt the symmetric keys and therefore have no access to the data. Finally, the shared item is signed by the author. Signed \texttt{SharedItems} are called \texttt{CryptedItems}.
 
 \subsubsection{Prototype}
 \label{sec:lifesocial-prototype}
@@ -54,6 +52,6 @@ LifeSocial is based on the previously described framework. The software runs und
 	\label{fig:lifesocial-screenshots}
 \end{figure}
 
-All functionalities (like login, profile, friends, groups) are designed as plugins to load them dynamically. Besides the usual social media functionalities, there are also plugins for file exchange, games (Tic Tac Toe) or a whiteboard. A separate store is planned, where users can download additional plugins.
+All functionalities (login, profile, friends, groups, and more) are designed as plugins to load them dynamically. Besides the usual social media functionalities, there are also plugins for file exchange, games (Tic Tac Toe) or a whiteboard. A separate store is planned, where users can download additional plugins.
 
 Graffi moved to the University of Paderborn in 2011 and has been a professor at the University of Düsseldorf since 2012 \cite{graffiXXXXlinkedin}. LifeSocial has since been renamed to LibreSocial and has been looking for participants for an alpha test on their website\footnote{https://libresocial.com/en/startpage/} since 2016. The screenshots on the LibreSocial website show a completely overhauled user interface with a web front end. Since the project website was not changed since May 2016 and there were no further publications, the current status is unclear.

+ 3 - 5
thesis/content/03-related-work/peepeth.tex

@@ -1,14 +1,12 @@
 Bevan Barton created Peepeth and launched the platform in March 2018. Peepeth\footnote{https://peepeth.com/welcome} is a microblogging platform that is very similar to Twitter in functionality and design. There are also other parallels to Twitter: Instead of a blue bird in the logo, Peepeth uses a penguin and instead of \textit{tweeting} users \textit{peep}. The maximum post length is limited to 280 characters, which has no technical cause but was taken over from Twitter. The main difference to Twitter is the decentralization.
 
-From Peepeth's point of view, social media is broken. The major problem is, that \ac{OSN} service providers control the online identities of users, sell their data, and violate their privacy. The news feeds are manipulated to drive the user to a higher level of interaction at any price. Besides, the platforms are teeming with trolls, bullying and flame wars. Barton wants to counter these grievances. Therefore there is no advertising on Peepeth. 
+From Peepeth's point of view, social media is broken. The major problem is, that \ac{OSN} service providers control the online identities of users, sell their data, and violate their privacy. The news feeds are manipulated to drive the user to a higher level of interaction at any price. Besides, the platforms are teeming with trolls, bullying and flame wars. Barton wants to counter these grievances. Therefore there is no advertising on Peepeth and no use of the user data for any purpose. 
 
-The website Peepeth.com is the front end of a \ac{dApp}, which uses the Eteherum blockchain and \ac{IPFS}. This front end can theoretically be exchanged arbitrarily, and Peepeth's data can be read and written because of the open blockchain protocol. No Ethereum test network is used, but the main network.
-
-The execution of transactions on the Ethereum blockchain is associated with costs. Peepeth pays the fee for its users. The necessary capital was collected via a crowdfunding campaign. However, when accounts distribute spam, Peepeth no longer carries the price for writing to the blockchain. The resulting charge should make spamming unattractive and reduce it to a minimum. Although Peepeth covers the costs, the user has to sign the transactions. Therefore, Peepeth requires a \ac{dApp} browser (e.g., Opera) or a browser that has been extended by a wallet (e.g., using MetaMask browser extension). \cite{peepeth2018free,peepeth2018free2,peepeth2018free3}
+The website Peepeth.com is the front end of a \ac{dApp}, which uses the Eteherum blockchain and \ac{IPFS}. This front end can theoretically be exchanged arbitrarily, and Peepeth's data can be read and written because of the open blockchain protocol. No Ethereum test network is used, but the main network. The execution of transactions on the Ethereum blockchain is associated with costs. Peepeth pays the fee for its users. The necessary capital was collected via a crowdfunding campaign. However, when accounts distribute spam, Peepeth no longer carries the price for writing to the blockchain. The resulting charge should make spamming unattractive and reduce it to a minimum. Although Peepeth covers the costs, the user has to sign the transactions. Therefore, Peepeth requires a \ac{dApp} browser (e.g., Opera) or a browser that has been extended by a wallet (e.g., using MetaMask browser extension). \cite{peepeth2018free,peepeth2018free2,peepeth2018free3}
 
 In order to keep transaction fees low, the actions executed on Peepeth are collected on the server hosting the front end and written to the blockchain in batches every hour. Several actions are bundled in one file and transaction. The actual contents are written as \ac{JSON} file to \ac{IPFS} and only the reference hash is stored on the blockchain. \cite{peepeth2018free2}
 
-While the smart contracts are open source, the front end is closed source. So it is impossible to understand what is happening on the server hosting the front end Peepeth.com. Image files are not only stored in \ac{IPFS} but also mirrored at \ac{AWS} to provide a better user experience. The client does not communicate directly with \ac{IPFS}, but the server behind the front end communicates with the two back end technologies \ac{IPFS} and Ethereum blockchain, as shown in Figure \ref{fig:peepeth-architecture}.
+While the smart contracts are open source, the front end is closed source. So it is impossible to understand what is happening on the server hosting the front end Peepeth.com. Image files are not only stored in \ac{IPFS} but also mirrored at \acf{AWS} to provide a better user experience. The client does not communicate directly with \ac{IPFS}, but the server behind the front end communicates with the two back end technologies \ac{IPFS} and Ethereum blockchain, as shown in Figure \ref{fig:peepeth-architecture}.
 
 \begin{figure}[h!]
 	\centering

+ 1 - 1
thesis/content/03-related-work/twitterize.tex

@@ -48,7 +48,7 @@ In the third phase, users can exchange messages using the previously shared hash
 \subsubsection{Proof of Concept}
 As proof of concept, Daubert et al. implemented Twitterize as an app for Android. The app was programmed in Java, the code remained closed source, and the app is not available from the Google Play Store. The representation of the data in the app takes place on different timelines. In addition to the standard home and user timelines, each hashtag gets its timeline which is accessible via a tab.
 
-For encryption 128bit keys with \ac{AES} \ac{CBC} is used. The keys are exchanged between the users via \ac{NFC} or QR codes. Since data structures, such as \ac{JSON}, are too verbose, the tweets are encoded using the Base64 algorithm. To distinguish between message types, rarely used UTF-8 symbols are utilized to give the messages a rough structure. The formation of the overlay network and the exchange of messages then works as described above.
+For encryption 128bit keys with \ac{AES} \ac{CBC} is used. The app provides support for the key exchange between the users via \ac{NFC} or QR codes. Since data structures, such as \ac{JSON}, are too verbose, the tweets are encoded using the Base64 algorithm. To distinguish between message types, rarely used UTF-8 symbols are utilized to give the messages a rough structure. The formation of the overlay network and the exchange of messages then works as described above.
 
 The design of the Twitterize architecture meets the privacy requirements. The other requirements for implementation were also achieved during the creation of the app. With the exchange of keys via \ac{NFC} or QR codes an easy way for key management was found and implemented. Just a few seconds of physical proximity are enough to form a group.
 

+ 4 - 4
thesis/content/04-concept.tex

@@ -2,14 +2,14 @@
 \label{ch:concept}
 \input{content/04-concept/introduction}
 
-\section{Requirements to the Hybrid \ac{OSN}}
-\label{sec:requirements}
-\input{content/04-concept/requirements}
-
 \section{Stakeholders}
 \label{sec:stakeholders}
 \input{content/04-concept/stakeholders}
 
+\section{Requirements to the Hybrid \ac{OSN}}
+\label{sec:requirements}
+\input{content/04-concept/requirements}
+
 \section{Restrictions}
 \label{sec:restrictions}
 \input{content/04-concept/restrictions}

+ 1 - 1
thesis/content/04-concept/introduction.tex

@@ -1,7 +1,7 @@
 The reason for the inadequate protection of personal data lies in the centralized system structure used by all leading social platforms (e.g., Facebook and Twitter). With this structure, the data are stored centrally and mostly unencrypted. The service provider therefore inevitably has access to this data. It is not transparent to users, which data the service provider record during the use and what happens to the data.
 On the one hand, the user data are evaluated to improve the user experience (suggestions for content matching the user’s preferences using recommender systems), but on the other hand also to make a profit. With personalized advertisement and, in the worst case, by selling the data, revenues are generated. Furthermore, the protection of data against access by third parties via official interfaces (harvesting) or unauthorized hacking cannot be ruled out (e.g., Facebook's incident with Cambridge Analytica in March 2018 \cite{facebook2018cambridge-analytica}). Last but not least, due to applicable law, it may be necessary for data to be transferred to secret services or government agencies (e.g., Facebook had more than 100\,000 requests from governments between January and July 2018 \cite{facebookXXXXtake-down}).
 
-The criticism of the protection of privacy on the Internet, especially in social networks, is not new. Already in 2010, the founders of diaspora* discovered that no social network sufficiently protects the privacy of users\cite{diaspora2010kickstarter-pitch}. Although the problems and dangers of centralized \acp{OSN} are known for a long time and new scandals regularly become known to the public, the users remain mostly loyal to the respective social networks. As a result of the Cambridge Analytica incident, Facebook lost only a few users in Europe but is in the meantime back on the previous level \cite{facebook2019reportq4}. Alternative social networks, which focus on privacy protection (e.g., Vero\footnote{https://www.vero.co}, Ello\footnote{https://ello.co}), lack attractiveness regarding their design, complexity, and functionality. As a consequence, they do not get enough users and often fail after a short time. The connection to the respective social network is so strong that the barrier for switching to another, more secure social network is not overcome. The amount of content already created, the social network built up, and a large number of contacts using the same platform all create this so-called lock-in effect.
+The criticism of the protection of privacy on the Internet, especially in social networks, is not new. Already in 2010, the founders of diaspora* discovered that no social network sufficiently protects the privacy of users \cite{diaspora2010kickstarter-pitch}. Although the problems and dangers of centralized \acp{OSN} are known for a long time and new scandals regularly become known to the public, the users remain mostly loyal to the respective social networks. As a result of the Cambridge Analytica incident, Facebook lost only a few users in Europe but is in the meantime back on the previous level \cite{facebook2019reportq4}. Alternative social networks, which focus on privacy protection (e.g., Vero\footnote{https://www.vero.co}, Ello\footnote{https://ello.co}), lack attractiveness regarding their design, complexity, and functionality. As a consequence, they do not get enough users and often fail after a short time. The connection to the respective social network is so strong that the barrier for switching to another, more secure social network is not overcome. The amount of content already created, the social network built up, and a large number of contacts using the same platform all create this so-called lock-in effect.
 
 If switching to another platform is not an option, it is necessary to look for better ways to protect privacy on existing platforms. The Researcher Training Group (RTG) \enquote{Privacy and Trust for Mobile Users}\footnote{https://www.informatik.tu-darmstadt.de/privacy-trust/privacy\_and\_trust/index.en.jsp} in area B \enquote{Privacy and Trust in Social Networks} conducts research in this field. Subarea B.2 focuses especially on the protection of privacy in hybrid social networks. A hybrid solution allows the users of centralized \ac{OSN} to use the platform as usual. Though, additional procedures for the protection of privacy are integrated so that users gain control over their data. The hybrid approach uses the idea of a private \ac{P2P} network that allows users to communicate securely. The business models of service providers often have data from their users as a central element. Therefore, a solution must be found to provide anonymous data from the private network so that the business models can continue to function. \cite{rtgXXXXarea-b, rtgXXXXarea-b2}
 

+ 2 - 2
thesis/content/07-conclusion.tex

@@ -4,11 +4,11 @@ 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}. 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.
+This thesis first introduced the problems around privacy protection in centralized, well-established \acp{OSN}, and the motivation for this work. Afterwards, 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}. Then, 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.
+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. 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.