Browse Source

Feedback Isabel

Carsten Porth 5 years ago
parent
commit
e2b9d27d8c

+ 12 - 0
thesis/bib/bibliography.bib

@@ -469,4 +469,16 @@
   note         = {Online, accessed 22.03.2019},
 }
 
+@Misc{twitterXXXXdev-getting-started,
+  title        = {{Get started with the Twitter developer platform}},
+  howpublished = {\url{https://developer.twitter.com/en/docs/basics/getting-started}},
+  note         = {Online, accessed 22.03.2019},
+}
+
+@Misc{androidXXXXfundamentals,
+  title        = {{Android - Application Fundamentals}},
+  howpublished = {\url{https://developer.android.com/guide/components/fundamentals.html}},
+  note         = {Online, accessed 22.03.2019},
+}
+
 @Comment{jabref-meta: databaseType:bibtex;}

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

@@ -2,13 +2,11 @@ The term Web 1.0 refers to the beginnings of the Internet, which consisted of si
 
 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 understanding of what Web 3.0 is, is all about decentralization, which is why 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 that 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} (see next section).
-
-In the following, the characteristics of a \ac{dApp} are described and individual, essential components are examined in more detail.
+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}.
 
 \subsection{Characteristics of a \ac{dApp}}
 \label{sec:dapp-characterisitics}
-Just as with client-server applications, a \ac{dApp} is also divided into front and back end. The main difference is that the back end is not represented by a centralized server and thus a single point of failure, but by code that is executed in a decentralized P2P network. In the back end so-called smart contracts are used to perform logical operations, and instead of a database, a blockchain is used. There are no special requirements for the front end so that it can be displayed as an app or website. It must only be possible to execute calls from the front end to the back end.
+As with client-server applications, a \ac{dApp} is divided into front and back end. The main difference is that the back end is not represented by a centralized server and thus a single point of failure, but by code that is executed in a decentralized P2P network. In the back end so-called smart contracts are used to perform logical operations, and instead of a database, a blockchain is used. The front end can be created either as an app or website, but it is necessary that calls can be executed from the front end to the back end.
 
 Johnston et al. and Siraj Raval name the following four criteria for a \ac{dApp} \cite{johnston2015dapp,raval2016decentralized}:
 

+ 6 - 6
thesis/content/02-background/p2p.tex

@@ -1,8 +1,8 @@
-The distinctive feature of \ac{P2P} systems is that each participant has the role of both a server and a client. The participants are therefore equal with each other and provide each other with services, which is reflected in the naming. \ac{P2P} networks are usually characterized as overlay networks over the Internet. Concerning the structure of the overlay network, a distinction is made between structured and unstructured networks. The \ac{P2P} principle became mainly well known in 1999 with Napster. With the file-sharing application Napster, it was possible to exchange (mainly copyrighted) songs among the participants without having to offer them from a central server.
+The distinctive feature of \ac{P2P} systems is that each participant has the role of both a server and a client. The participants are therefore equal and provide each other with services, what is reflected in the naming. \ac{P2P} networks are usually characterized as overlay networks over the Internet. Concerning the structure of the overlay network, a distinction is made between structured and unstructured networks. The \ac{P2P} principle became well-known in 1999 with the file-sharing application Napster. The software connected its users and allowed accessing (mainly copyrighted) songs among the participants without having to offer them from a central server.
 
 Popular applications of \ac{P2P} networks are file sharing (e.g., BitTorrent), instant messaging (e.g., Skype) and blockchain technology (e.g., Bitcoin).
 
-Their independence particularly characterizes \ac{P2P} networks: there are no control points and not necessarily a fixed infrastructure. This also has a positive effect on operating costs. Besides, \ac{P2P} networks are self-organized and self-scaling, as each additional user contributes its resources.
+Their independence particularly characterizes \ac{P2P} networks: there are no control points and not necessarily a fixed infrastructure which leads to minimal operating costs. Besides, \ac{P2P} networks are self-organized and self-scaling, as each additional user contributes its resources.
 
 However, there are also some challenges in \ac{P2P} networks that need to be solved for successful operation. These include finding peers in the network (peer discovery) and finding resources (resource discovery). Especially in file sharing networks, solutions have to be found how to motivate users to upload data and not only use the download one-sidedly. The replication of data and the associated availability must also be taken into account in solutions. Another critical issue is the Internet connection of individual participants, which may not be powerful or permanent.
 
@@ -10,9 +10,9 @@ However, there are also some challenges in \ac{P2P} networks that need to be sol
 \label{sec:unstructured-p2p}
 In unstructured \ac{P2P} networks there are no specifications for the overlay network, so the peers are only loosely connected. Due to the loose structures, the failure of one peer has no significant influence on the function of the rest of the network. Another advantage of the unstructured topology is the lower vulnerability.
 
-While such loose structures are easy to create, the performance of the entire network suffers. A multicast request is sent to all connected peers, who forward the request again and flood the entire network. If a peer can respond to the request, it responds by the same route that the request used to reach it. Each request has a validity time (\ac{TTL}) before it is discarded. Popular files with wide distribution can thus be found quickly. However, rare files are difficult to find because the \ac{TTL} may have been reached before. A flooding search is not efficient and provides a large amount of signaling traffic. An example of this approach is Gnutella.
+While such loose structures are easy to create, the performance of the entire network suffers. A multicast request is sent to all connected peers, who forward the request again and flood the entire network. If a peer can respond to the request, it responds by the same route that the request used to reach it. Each request has a validity time (\ac{TTL}) before it is discarded. Popular files with wide distribution can thus be found quickly. However, rare files are difficult to find because the \ac{TTL} may has expired before the request could be completed. A flooding search is not efficient and provides a large amount of signaling traffic. An example of this approach is Gnutella.
 
-In order to counteract the problem of inefficient and complicated searching for resources, in other network implementations, central points are created to answer the search requests. These include Napster, FastTrack, and BitTorrent. Figure \ref{fig:unstructured-p2p} shows a comparison of the search process in the respective networks.
+To address the problem of inefficient and complicated searching for resources, central points are created to answer the search requests. Network implementations using this structure are Napster, FastTrack, and BitTorrent. Figure \ref{fig:unstructured-p2p} shows a comparison of the search process in the respective networks.
 
 \begin{figure}[h!]
 	\centering
@@ -23,12 +23,12 @@ In order to counteract the problem of inefficient and complicated searching for
 
 \subsection{Structured \ac{P2P} Networks}
 \label{sec:structured-p2p}
-By defining a particular structure, for example a circle or a tree, search processes in the overlay network can be designed efficiently and deterministically. In such structured networks, compliance with the structure is strictly controlled. Routing algorithms determine how a node is arranged in the overlay network. The performance of the entire network depends directly on the arrangement of the nodes and how quick changes (joining and leaving nodes) are detected.
+In structured networks, compliance with the structure is strictly controlled. By defining a particular structure, for example a circle or a tree, search processes in the overlay network can be designed efficiently and deterministically. Routing algorithms determine how a node is arranged in the overlay network. The performance of the entire network depends directly on the arrangement of the nodes and how quick changes (joining and leaving nodes) are detected.
 
 Usually, the routing algorithms are based on a \ac{DHT}. Hash tables are data structures in which key-value pairs are stored, whereby the key must be unique. The corresponding value can then be queried via the key. The keys are ids, which are generated with a hash function (e.g., SHA-1). For the addresses of the nodes and the files, ids are created equally, so that they lie in the same address space. For finding a file, it is searched at the node with the same or the next larger id. If it is not available there, it does not exist on the network.
 
 For joining a network, either one or more peers must be known as the entry point, or this information must be obtained from a bootstrap server. When entering a structured network, the joining node is assigned a unique id and thus positions itself in the structure. The routing tables of the nodes affected by the structural change must then be updated.
 
-When leaving a network, this happens either gracefully, and all affected nodes are informed to update their routing tables, or unexpectedly. Therefore, nodes must always check the correctness of their routing tables.
+When leaving a network, this happens either planned, and all affected nodes are informed to update their routing tables, or unexpected. Therefore, nodes must always check the correctness of their routing tables.
 
 Known routing algorithms that use \acp{DHT} include Chrod\cite{stoica2003chord}, CAN\cite{ratnasamy2001scalable}, Pastry\cite{rowstron2001pastry}, Tapestry\cite{zhao2004tapestry} and Kademlia\cite{maymounkov2002kademlia}. Among other things, they differ in their distinct structure and the hash functions used.

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

@@ -5,7 +5,7 @@ In the following, the characteristics and peculiarities of the different archite
 \begin{figure}[h!]
 	\centering
 	\includegraphics[width=1.0\textwidth]{network-architectures}
-	\caption{Schematic representation of various software system architectures. In centralized applications (A), all clients (blue) are in connection with a central server (red), while in decentralized applications (B) several servers provide for improved stability. In distributed applications (C), all nodes have the same role with the same tasks, which is why we also speak of peers (green).}
+	\caption{Schematic representation of various software system architectures. In centralized applications (A), all clients (blue) are in connection with a central server (red), while in decentralized applications (B) several servers provide for improved stability. In distributed applications (C), all nodes have the same role with the same tasks, hence they are called peers (green).}
 	\label{fig:software-system-architecture}
 \end{figure}
 
@@ -13,21 +13,21 @@ In the following, the characteristics and peculiarities of the different archite
 \label{sec:centralized-applications}
 In a centralized application, 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, most web applications are designed as centralized applications. The clients are usually (mobile) apps or browsers that act as the interface to the user. Examples of this are social networks such as Facebook.
+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 such an 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. Such 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 only 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 with the failure or the blockade of the server, the entire system collapses. 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. 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. 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 largely reversed in decentralized systems. Unlike centralized applications, decentralized applications do not have a single point of failure. But 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.
 
-Thus, the advantages of decentralized applications include, in addition to the already mentioned increased reliability, even further advantages. Each server only records the number of users covered by its resources. New servers contribute new 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. So, 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 is no longer available, even if the system itself remains functional. 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 can still work together.
+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 is no longer available, even if the system itself remains functional. 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. Each user can operate his own server in these networks. Unlike Facebook, the decision on the existence of the service is therefore not in the control of the operator, but the user. Bitcoin is also a decentralized application architecture. In doing so, transactions are carried out in a decentralized database (blockchain).
+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. Bitcoin is also a decentralized application architecture. In doing so, transactions are carried out in a decentralized database (blockchain).
 
 \subsection{Distributed Applications}
 \label{sec:distributed-applications}
@@ -35,7 +35,7 @@ A feature of distributed applications is the distributed computation across all
 
 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 different sources in difference to \ac{HTTP} where only one source provides the file. Each node not only downloads but also provides itself to other files. In order to avoid that nodes download only (so-called Leechers) but also contribute, they are penalized with slow download speeds. This principle is known as \textit{tit for tat}.
+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}
@@ -43,15 +43,15 @@ The following table \ref{tab:comparison-architectures} compares the main feature
 
 \begin{table}[h!]
 	\centering
-	\begin{tabular}{l|c|c|c|}
+	\begin{tabularx}{\textwidth}{X|c|c|c|}
 		\cline{2-4}
 		& \multicolumn{1}{l|}{Centralized Systems} & \multicolumn{1}{l|}{Decentralized Systems} & \multicolumn{1}{l|}{Distributed Systems} \\ \hline
 		\multicolumn{1}{|l|}{Scalability}                                                  &                                          & +                                          & ++                                       \\ \hline
 		\multicolumn{1}{|l|}{Maintenance}                                                  & ++                                       & +                                          &                                          \\ \hline
-		\multicolumn{1}{|l|}{\begin{tabular}[c]{@{}l@{}}System \\ Stability\end{tabular}}  &                                          & +                                          & ++                                       \\ \hline
+		\multicolumn{1}{|l|}{\begin{tabular}[c]{@{}l@{}}System Stability\end{tabular}}  &                                          & +                                          & ++                                       \\ \hline
 		\multicolumn{1}{|l|}{Performance}                                                  & ++                                       & +                                          &                                          \\ \hline
-		\multicolumn{1}{|l|}{\begin{tabular}[c]{@{}l@{}}Data \\ Availability\end{tabular}} & ++                                       & +                                          &                                          \\ \hline
-	\end{tabular}
+		\multicolumn{1}{|l|}{\begin{tabular}[c]{@{}l@{}}Data Availability\end{tabular}} & ++                                       & +                                          &                                          \\ \hline
+	\end{tabularx}
 	\caption{Comparison of different software system architectures on scalability, maintenance, system stability, performance, and data availability. The pluses indicate how positive something is relative to the other systems.}
 	\label{tab:comparison-architectures}
 \end{table}

+ 2 - 2
thesis/content/04-concept/quality-goals.tex

@@ -2,14 +2,14 @@ The following quality objectives (Table \ref{tab:quality-goals}) have been defin
 
 \begin{table}[h!]
 	\centering
-	\begin{tabular}{|l|l|}
+	\begin{tabularx}{\textwidth}{|l|X|}
 		\hline
 		\textbf{Quality Goal} & \textbf{Motivation}                                                                                                                                                                   \\ \hline
 		Analyzability         & \begin{tabular}[c]{@{}l@{}}- Module, class and method names in English\\ - Detailed documentation of the public interfaces\\ - Compliance with the Clean Code principles\end{tabular} \\ \hline
 		Changeability         & \begin{tabular}[c]{@{}l@{}}- Common programming language\\ - Program modules against interfaces to keep them interchangeable\end{tabular}                                             \\ \hline
 		Testability           & - The architecture should allow easy testing of all building blocks                                                                                                                   \\ \hline
 		Transparency          & - The application should be Open Source                                                                                                                                               \\ \hline
-	\end{tabular}
+	\end{tabularx}
 	\caption{The quality goals are the relevant requirements and the driving forces that software architects and developers should consider.}
 	\label{tab:quality-goals}
 \end{table}

+ 2 - 2
thesis/content/04-concept/solution-strategy-architecture.tex

@@ -71,13 +71,13 @@ Table \ref{tab:solution-strategy-architecture-comparison} lists the advantages a
 
 \begin{table}[h!]
 	\centering
-	\begin{tabular}{l|l|l|}
+	\begin{tabularx}{\textwidth}{X|l|l|}
 		\cline{2-3}
 		& \textbf{Advantages} & \textbf{Disadvantages} \\ \hline
 		\multicolumn{1}{|l|}{\textbf{\begin{tabular}[c]{@{}l@{}}Own infrastructure\\ (centralized)\end{tabular}}}        & \advantageoi                    & \disadvantageoi                       \\ \hline
 		\multicolumn{1}{|l|}{\textbf{\begin{tabular}[c]{@{}l@{}}Own network\\ (decentralized/distributed)\end{tabular}}} & \advantageon                    & \disadvantageon                       \\ \hline
 		\multicolumn{1}{|l|}{\textbf{External infrastructure}}                                                           & \advantageei                    & \disadvantageei                       \\ \hline
-	\end{tabular}
+	\end{tabularx}
 	\caption{Advantages and disadvantages of the different solution strategies for the hybrid \ac{OSN} architecture.}
 	\label{tab:solution-strategy-architecture-comparison}
 \end{table}

+ 4 - 4
thesis/content/05-proof-of-concept/building-block-view.tex

@@ -1,4 +1,4 @@
-In this section, the context in which Hybrid \ac{OSN} is located is first considered, and then a breakdown into the individual components is carried out. The function of the respective blocks is then described in more detail. Finally, the function of individual components in interaction is explained using the examples of displaying the home timeline and posting a new tweet.
+In this section, the context in which Hybrid \ac{OSN} is located is first considered, and then a breakdown into the individual components is carried out. Furthermore, the function of the respective blocks is described in more detail. Finally, the function of individual components in interaction is explained using the examples of displaying the home timeline and posting a new tweet.
 
 \subsection{Scope and Context}
 \label{sec:scope-and-context}
@@ -11,7 +11,7 @@ Figure \ref{fig:building-block-view} shows a black box view of which other syste
 	\item User 
 \end{itemize}
 
-Infura\footnote{https://infura.io/} is a service that provides access to Ethereum and \ac{IPFS} via a simple interface. Communication with the \ac{API} happens using \ac{HTTP} requests. The connection of \ac{IPFS} in Hybrid \ac{OSN} can thus be carried out in an uncomplicated way. The use of an additional system entails an additional risk typically. However, there is a JavaScript client for \ac{IPFS}, which can be integrated into Hybrid \ac{OSN} and thus the dependency on Infura would be omitted. At present and for the development of the prototype, the decision was made to use Infura for reasons of simplicity. Infura can be used for \ac{IPFS} free of charge and without registration.
+Infura\footnote{https://infura.io/} is a service that provides access to Ethereum and \ac{IPFS} via a simple interface. Communication with the \ac{API} happens using \ac{HTTP} requests. The connection of \ac{IPFS} in Hybrid \ac{OSN} can thus be carried out in a simple way. The use of an additional system entails an extra risk typically. However, there is a JavaScript client for \ac{IPFS}, which can be integrated into Hybrid \ac{OSN} and thus the dependency on Infura would be omitted. For the development of the prototype, the decision was made to use Infura for reasons of simplicity. Infura can be used for \ac{IPFS} free of charge and without registration.
 
 \begin{figure}[h!]
 	\centering
@@ -23,11 +23,11 @@ Infura\footnote{https://infura.io/} is a service that provides access to Ethereu
 \subsection{White Box View}
 \label{sec:white-box}
 
-The used Ionic framework uses Angular in the core, in the concrete case of Hybrid \ac{OSN} Angular 5.2 is used. Accordingly, the Hybrid \ac{OSN} app is in principle an Angular application. The essential building blocks are components, pages, and providers. In the following, these components are described in detail and examples are given of where they are used in Hybrid \ac{OSN}.
+The Ionic framework uses Angular in the core. Accordingly, the Hybrid \ac{OSN} app is in principle an Angular application. The essential building blocks are components, pages, and providers. In the following, these components are described in detail and examples are given of where they are used in Hybrid \ac{OSN}.
 
 \subsubsection{Providers}
 \label{providers}
-Data access is performed using providers (known as services in Angular). For the external services (Twitter \ac{API}, \ac{P2P} database, \ac{P2P} storage), there is one provider each to handle the communication. Besides, providers are used as helper classes that provide specific functionality that is used several times. This functionality includes, for example, encryption and decryption and the compilation of aggregated timelines. Providers are injected into components using the constructor. Table \ref{tab:providers} lists all providers used in Hybrid OSN and their functional descriptions.
+Data access is performed using providers (known as services in Angular). For the external services (Twitter \ac{API}, \ac{P2P} database, \ac{P2P} storage), there is one provider each to handle the communication. Besides, providers are used as helper classes providing specific functionality that is used several times. This functionality includes, for example, encryption and decryption and the compilation of aggregated timelines. Providers are injected into components using the constructor. Table \ref{tab:providers} lists all providers used in Hybrid OSN and their functional descriptions.
 
 \begin{table}[h!]
 	\begin{tabularx}{\textwidth}{|l|X|}

+ 8 - 8
thesis/content/05-proof-of-concept/osn-selection.tex

@@ -8,25 +8,25 @@ To select a suitable \ac{OSN} for the development of a hybrid client, three fact
 
 Facebook was the obvious first choice due to the numerous negative headlines about data protection. With over 2.3 billion users per month (average Q4 2018), it is currently the most widely used social network in the world \cite{facebook2019reportq4}. In the recent past, it has often been criticized for its handling of its users' data. In particular, the scandal surrounding the data analysis company Cambridge Analytica, which had access to the data of up to 87 million users, hit Facebook hard \cite{facebook2018cambridge-analytica,facebook2018api-restriction}. As a result, CEO Mark Zuckerberg had to face the US Congress and the EU Parliament in question rounds and did not leave a good impression by avoiding many questions \cite{facebook2018us-congress,facebook2018eu-parliament}. As a result of this scandal, there were further restrictions to the Facebook \ac{API} \cite{facebook2018api-restriction}.
 
-However, the Facebook \ac{API} is not suitable for developing a new client. The functionalities provided by the \ac{API} offer the possibility to develop an app that can be used within Facebook, for example for a game. So, it is not possible to give a \enquote{Like} for a post through this \ac{API}, which is part of the core functionality of a Facebook client. As discussed in Chapter \ref{ch:concept}, it is possible to access the data through crawling. However, the constant and rapid development would make this an arduous undertaking. Facebook writes in a blog post that the code changes every few hours \cite{facebook2017release}. Therefore it is almost impossible to adjust the crawler fast enough and roll out the adjusted code.
+However, the Facebook \ac{API} is not suitable for developing a new client. The functionalities provided by the \ac{API} offer the possibility to develop an app that can be used within Facebook, for example for a game. So, it is not possible to give a \enquote{Like} for a post through this \ac{API}, which is part of the core functionality of a Facebook client. As discussed in Chapter \ref{ch:concept}, it is possible to access the data through crawling. However, the constant and rapid development would make this an arduous undertaking. Facebook writes in a blog post that the code changes every few hours \cite{facebook2017release}. Therefore it is almost impossible to adjust the crawler fast enough and roll out the updated code.
 
-Even the mixed version of displaying and manipulating the mobile website in a WebView in a container app does not seem to be an option due to the short release cycles and frequent changes. Apps like \enquote{Friendly for Facebook} do not manage to keep up with the changes as reported in various user ratings on the Google Play Store. The false representations and bugs worsen the user experience and result in the frustration of users.
+Even the mixed version of displaying and manipulating the mobile website in a WebView in a container app does not seem to be an option due to the short release cycles and frequent changes. Apps like \enquote{Friendly for Facebook} do not manage to keep up with the changes as reported in various user ratings on the Google Play Store. The false representations and bugs worsen the user experience and result in the frustration of the users.
 
 For this number of reasons, Facebook dropped out as an \ac{OSN} candidate for the prototype despite the particular interest. As a further candidate, the \ac{OSN} Google Plus was dropped, as Google announced in October 2018 that it would discontinue its \ac{OSN} \cite{google-plus2018shutdown}.
 
-In the end, Twitter was chosen for the prototype. With 321 million active users per month (average Q4 2018), it is one of the largest social networks \cite{twitter2019reportq4}. It is particularly well suited for the development of a hybrid client for two reasons: on the one hand, it has a comprehensive \ac{API} that provides almost full functionality free of charge, and on the other hand, compared to Facebook, it offers only a few simple functions. These are the ideal prerequisites for the first proof of concept.
+Finally, Twitter was chosen for the prototype. With 321 million active users per month (average Q4 2018), it is one of the largest social networks \cite{twitter2019reportq4}. It is particularly well suited for the development of a hybrid client for two reasons: first, it has a comprehensive \ac{API} that provides almost full functionality free of charge, and second, compared to Facebook, it offers only a few simple functions. These are the ideal prerequisites for the first proof of concept.
 
-Twitter offers different \acp{API} for developers that serve different purposes. The current \acp{API} are:
+Twitter offers several \acp{API} for developers that serve different purposes. The current \acp{API} are \cite{twitterXXXXdev-getting-started}:
 \begin{itemize}
 	\item \textbf{Standard \ac{API}}: the free and public \ac{API} offering basic query functionality and foundational access to Twitter data.
 	\item \textbf{Premium \ac{API}}: introduced in November 2017 to close the gap between Standard and Entrprise \ac{API}. Improvements over the Standard \ac{API}: \enquote{more Tweets per request, higher rate limits, a counts endpoint that returns time-series counts of Tweets, more complex queries and metadata enrichments, such as expanded URLs and improved profile geo information}\footnote{https://blog.twitter.com/developer/en\_us/topics/tools/2017/introducing-twitter-premium-apis.html}. Prices to use this \ac{API} start at 149\$/month.
 	\item \textbf{Enterprise \ac{API}}: tailored packages with annual contracts for those who depend on Twitter data.
 	\item \textbf{Ads \ac{API}}: this \ac{API} is only of interest for creating and managing ad campaigns.
-	\item \textbf{Twitter for websites}: this is more a suite of tools than an \ac{API}. It's free to use and enables people to embed tweets and tweet buttons on their website.
+	%\item \textbf{Twitter for websites}: this is more a suite of tools than an \ac{API}. It's free to use and enables people to embed tweets and tweet buttons on their website.
 \end{itemize}
 
-In the case of the hybrid client, the standard \ac{API} is the right one. For using the \ac{API}, first, the registration of a \enquote{Twitter App} is necessary to receive a consumer key and access token. These two authentication tokens are required to log in users via the hybrid app and successfully communicate with the \ac{API}.
+In the case of the hybrid client, the standard \ac{API} can be used. In this process, the registration of a \enquote{Twitter App} is necessary to receive a consumer key and access token. These two authentication tokens are required to log in users via the hybrid app and successfully communicate with the \ac{API}.
 
-Twitter offers almost the entire range of functions via the \ac{API}. The missing functionality (e.g., the targeted retrieval of replies to a tweet) is not so critical for building a client app. A significant limitation is a restriction on the number of requests. Twitter argues that this restriction is necessary to avoid the exposure of the system to too much load. It also aims to prevent bots from abusing Twitter. The exact limits can be found on a help page\footnote{https://developer.twitter.com/en/docs/basics/rate-limits}. In the app stores of Google and Apple, there are a number of alternative Twitter clients (Twitterific\footnote{https://itunes.apple.com/de/app/twitterrific-5-for-twitter/id580311103?mt=8}, Talon for Twitter\footnote{https://play.google.com/store/apps/details?id=com.klinker.android.twitter\_l}, Fenix 2 for Twitter\footnote{https://play.google.com/store/apps/details?id=it.mvilla.android.fenix2}), which are also subject to these restrictions in terms of functionality and request restrictions.
+Twitter offers almost the entire range of functions via the \ac{API}. The missing functionality (e.g., the targeted retrieval of replies to a tweet) is not so critical for building a client app. A significant limitation is a restriction on the number of requests. Twitter argues that this restriction is necessary to avoid the exposure of the system to too much load. It also aims to prevent bots from abusing Twitter. The exact limits can be found on a help page\footnote{https://developer.twitter.com/en/docs/basics/rate-limits}. In the app stores of Google and Apple, there are a number of alternative Twitter clients (Twitterific\footnote{https://itunes.apple.com/de/app/twitterrific-5-for-twitter/id580311103?mt=8}, Talon for Twitter\footnote{https://play.google.com/store/apps/details?id=com.klinker.android.twitter\_l}, Fenix 2 for Twitter\footnote{https://play.google.com/store/apps/details?id=it.mvilla.android.fenix2}), which are also subject to these restrictions in terms of functionality and requests.
 
-The \ac{API} can be accessed using \ac{HTTP} requests. The data exchanged are in \ac{JSON} format. Furthermore, there are also various libraries (e.g., Twit\footnote{https://github.com/ttezel/twit}), some of which are developed directly by Twitter (see Twitter Kit for Android\footnote{https://github.com/twitter/twitter-kit-android} or iOS\footnote{https://github.com/twitter/twitter-kit-ios}) and simplify the use of the \ac{API}.
+The \ac{API} can be accessed using \ac{HTTP} requests. The data exchanged are in \ac{JSON} format. Furthermore, there are also various libraries (e.g., Twit\footnote{https://github.com/ttezel/twit}), some even are developed directly by Twitter (see Twitter Kit for Android\footnote{https://github.com/twitter/twitter-kit-android} or iOS\footnote{https://github.com/twitter/twitter-kit-ios}) and simplify the use of the \ac{API}.

+ 3 - 3
thesis/content/05-proof-of-concept/runtime-view.tex

@@ -1,6 +1,6 @@
 This section describes particular processes and relationships between building blocks for two selected scenarios. The first is to write and post a tweet and the second is to display the home timeline. In addition to the description, the two scenarios are also documented by flowcharts.
 
-The goal is to make clear how the building blocks of the system perform their respective tasks and communicate with each other at runtime. The two scenarios were therefore deliberately selected because they are of particular importance and require special documentation due to their complexity.
+The goal is to make clear how the building blocks of the system perform their respective tasks and communicate with each other at runtime. The two scenarios were therefore deliberately selected because of their particular importance and require special documentation due to their complexity.
 
 \subsection{Post a Tweet}
 \label{sec:post-a-tweet}
@@ -29,7 +29,7 @@ Beside the message (\texttt{full\_text}) the Twitter user id (\texttt{user\_id})
 
 \lstinputlisting[label=listing:private-tweet, caption=Private Tweet in \ac{JSON} format]{listings/private-tweet.json}
 
-The crypto provider performs the encryption of the private tweet data. For asymmetrical encryption, the RSA algorithm is used. The \ac{P2P} storage provider sends the encrypted data via an \ac{HTTP} POST request to Infura for storage in \ac{IPFS}. The response contains the hash which addresses the data in \ac{IPFS}. This hash is stored in Gun together with the timestamp and the author's Twitter user id. For saving to Gun, the \ac{P2P} DB provider is used. Besides, the previously extracted hashtags with the timestamp are also stored in Gun with the same provider so that the data in the dashboard is accessible to the service provider without having to conclude individual users.
+The crypto provider performs the encryption of the private tweet data. For asymmetrical encryption, the RSA algorithm is used. The \ac{P2P} storage provider sends the encrypted data via an \ac{HTTP} POST request to Infura for storage in \ac{IPFS}. The response contains the hash which addresses the data in \ac{IPFS}. This hash is stored in GUN together with the timestamp and the author's Twitter user id. For saving to GUN, the \ac{P2P} DB provider is used. Besides, the previously extracted hashtags with the timestamp are also stored in GUN with the same provider so that the data in the dashboard is accessible to the service provider without having to conclude individual users.
 
 \subsection{Load the Home Timeline}
 \label{sec:load-home-timeline}
@@ -51,6 +51,6 @@ When opening the home page, the logged in user gets the latest tweets of the acc
 
 The starting point is the home page, which is accessed by the user. Several components display the data obtained from the feed provider. Using the Twitter \ac{API} provider, the feed provider loads the latest 20 timeline tweets via the corresponding interface (\texttt{statuses/home\_timeline}\footnote{https://developer.twitter.com/en/docs/tweets/timelines/yapi-reference/get-statuses-home\_timeline.html}) via an \ac{HTTP} GET request.
 
-The next step is to load the private tweets that match the period marked by the current timestamp and timestamp of the 20th (the oldest) tweet. Furthermore, the user ids of the users the user follows (so-called friends) are required. These must initially be requested from the Twitter \ac{API} (\texttt{friends/list}\footnote{https://developer.twitter.com/en/docs/accounts-and-users/follow-search-get-users/api-reference/get-friends-list}) via the Twitter Feed provider using an \ac{HTTP} GET request. The loaded user ids are cached in order to keep the number of requests to the Twitter \ac{API} to a minimum for later loading processes. For each user id, a lookup for private tweets in the given period is performed. The \ac{P2P} \ac{DB} provider queries Gun. If there are private tweets, the hashes for \ac{IPFS} are returned together with the \texttt{created\_at} timestamp. If no private tweets are available for the period, the feed provider returns the data of the public tweets to the home page. Otherwise, next, the private tweets are loaded and decrypted. First, the \ac{P2P} storage provider is used to load the data behind the hash addresses from \ac{IPFS} via Infura. For this purpose, the hash is transferred to Infura with an \ac{HTTP} GET request, and the data is received from \ac{IPFS} as the response. The author's public key, which can be obtained from the user's public key history, is needed for decryption. The public key history is loaded and decrypted via the crypto provider, which in turn uses the Twitter \ac{API} provider. Afterward, the private tweet is decrypted.
+The next step is to load the private tweets that match the period marked by the current timestamp and timestamp of the 20th (the oldest) tweet. Furthermore, the ids of the accounts the user follows (so-called friends) are required. These must initially be requested from the Twitter \ac{API} (\texttt{friends/list}\footnote{https://developer.twitter.com/en/docs/accounts-and-users/follow-search-get-users/api-reference/get-friends-list}) via the Twitter Feed provider using an \ac{HTTP} GET request. The loaded user ids are cached in order to keep the number of requests to the Twitter \ac{API} to a minimum for later loading processes. For each user id, a lookup for private tweets in the given period is performed. The \ac{P2P} \ac{DB} provider queries GUN. If there are private tweets, the hashes for \ac{IPFS} are returned together with the \texttt{created\_at} timestamp. If no private tweets are available for the period, the feed provider returns the data of the public tweets to the home page. Otherwise, the private tweets are loaded and decrypted. First, the \ac{P2P} storage provider is used to load the data behind the hash addresses from \ac{IPFS} via Infura. For this purpose, the hash is transferred to Infura with an \ac{HTTP} GET request, and the data is received from \ac{IPFS} as the response. The author's public key, which can be obtained from the user's public key history, is needed for decryption. The public key history is loaded and decrypted via the crypto provider, which in turn uses the Twitter \ac{API} provider. Afterwards, the private tweet is decrypted.
 
 Finally, the private and public tweets are merged and sorted according to their \texttt{created\_at} timestamp in descending order. This data is returned to the home page. If the user triggers a reload by reaching the end of the feed or by \enquote{pull to refresh}, the previously described process starts again.

+ 2 - 2
thesis/content/05-proof-of-concept/security.tex

@@ -1,4 +1,4 @@
-Usually, asymmetric or a combination of asymmetric and symmetric encryption methods are used for secure message exchange. The advantage of asymmetric encryption methods is that messages can be encrypted with the known public key and then only the owner of the private key can decrypt them. It is not possible to determine the private key from the public key within a reasonable time. However, asymmetric encryption methods are more computationally intensive and therefore more time-consuming than symmetric encryption methods. For this reason, a combination of both methods can be used first to exchange a symmetric key using asymmetric encryption. The asymmetric encryption ensures that only the two parties are aware of the symmetric key, which can then be used for symmetric encryption of the communication.
+Usually, asymmetric or a combination of asymmetric and symmetric encryption methods are used for secure message exchange. The advantage of asymmetric encryption methods is that messages can be encrypted with the known public key and then only the owner of the private key can decrypt them. It is not possible to determine the private key from the public key within a reasonable time. However, asymmetric encryption methods are more computationally intensive and therefore more time-consuming than symmetric encryption methods. For this reason, a combination of both methods can be used to exchange a symmetric key using asymmetric encryption. The asymmetric encryption ensures that only the two parties are aware of the symmetric key, which can then be used for symmetric encryption of the communication.
 
 Tweets are usually posted publicly on Twitter. Only those who explicitly set their profile to \enquote{private} can decide whom they allow as followers and thus recipients of their tweets. This type of publication and visibility should also apply to private networks. Since it is unclear who is the recipient of a private tweet, it is not possible to encrypt the message with the recipient's public keys.
 
@@ -12,7 +12,7 @@ The following three requirements apply to encryption:
 Concrete actions can be concluded to meet these requirements:
 \begin{enumerate}
 	\item Private tweets must be signed or asymmetrically encrypted so that the author is identifiable.
-	\item Distribution of the public key for decryption must take place via the user's profile. The profile is the only place that guarantees that only authorized users can access the key and that the public key belongs to a specific user without any doubt.
+	\item Distribution of the public key for decryption must take place via the user's profile. The profile is the only place guaranteeing that only authorized users can access the key and that the public key belongs to a specific user without any doubt.
 	\item The Hybrid \ac{OSN} application must encrypt the public keys so that Twitter cannot read them and therefore cannot decrypt the private tweets.
 \end{enumerate}
 

+ 7 - 7
thesis/content/05-proof-of-concept/technology-decisions.tex

@@ -7,7 +7,7 @@ In order to meet the requirements of the concept best, a detailed consideration
 
 \subsection{Creation of a \ac{P2P} Network}
 \label{sec:create-p2p-network}
-The advantage of having an extra \ac{P2P} network is that it is completely under control. Accordingly, it can be designed to fit exactly to the use case and require little or no compromise. However, setting up a \ac{P2P} network is a big challenge and some hurdles must be overcome. These challenges include peer discovery (how peers find each other), global data exchange over the Internet and data storage, and availability of the stored data. And of course, all these requirements must scale. It should work for \ac{P2P} networks with only a few peers and also for a few thousand or even more peers. In the following, we discuss two options to create the P2P network:
+The advantage of having an extra \ac{P2P} network is that it is completely under control. Accordingly, it can be designed to fit exactly to the use case and require little or no compromise. However, setting up a \ac{P2P} network is a big challenge and some hurdles must be overcome. These challenges include peer discovery (how peers find each other), global data exchange over the Internet and data storage, and availability of the stored data. In addition, all these requirements must scale. It should work for \ac{P2P} networks with only a few peers and also for a few thousand or even more peers. In the following, we discuss two options to create the P2P network:
 
 \begin{itemize}
 	\item The use of an established standard such as Wi-Fi Dircet and \ac{WebRTC}
@@ -16,19 +16,19 @@ The advantage of having an extra \ac{P2P} network is that it is completely under
 
 \subsubsection{Wi-Fi Direct}
 \label{sec:wifi-direct}
-Wi-Fi Direct is a standard (IEEE 802.11) for data transmission between two WLAN terminals. There is no need for an access point between the two devices. However, the distance that may lie between the two peers is thus limited. Without obstacles, which contribute to the attenuation of the signal, a distance of up to 200\,m is possible \cite{wifiXXXXdistance}. However, the requirement for the \ac{P2P} network to expand Twitter is different. Users can be scattered around the world and may be online through the mobile network. There is no \ac{P2P} connection via Wi-Fi Dircet in this case.
+Wi-Fi Direct is a standard (IEEE 802.11) for data transmission between two WLAN terminals. There is no need for an access point between the two devices. However, the distance that may lie between the two peers is thus limited. Without obstacles, which contribute to the attenuation of the signal, a distance of up to 200\,m is possible \cite{wifiXXXXdistance}. However, the requirement for the \ac{P2P} network to expand Twitter is different. Users can be scattered around the world and may be online through the mobile network. There is no \ac{P2P} connection via Wi-Fi Dircet possible in this case.
 
 \subsubsection{\ac{WebRTC}}
 \label{sec:webrtc}
-\ac{WebRTC} is an open standard\footnote{https://www.w3.org/TR/webrtc/} that provides various communication protocols for real-time communication between two or more peers. Above all, \ac{WebRTC} is popular for its ability to easily perform video calls, as known from Skype, in the browser without a server. But also the file transfer between peers is possible. In a separate \ac{P2P} network, data could be exchanged between the clients. However, the connection between the clients is complex, since in addition to the two peers also a \ac{STUN} server and optionally a \ac{TURN} server is involved. Furthermore, it is unclear whether the system scales.
+\ac{WebRTC} is an open standard\footnote{https://www.w3.org/TR/webrtc/} that provides various communication protocols for real-time communication between two or more peers. Above all, \ac{WebRTC} is popular for its ability to easily perform video calls, as known from Skype, in the browser without a server. Additionally it allows file transfer between peers. In a separate \ac{P2P} network, data could be exchanged between the clients. However, the connection between the clients is complex, beside two peers also a \ac{STUN} server and optionally a \ac{TURN} server is involved. Furthermore, it is unclear whether the system scales.
 
 \subsubsection{Yjs}
 \label{sec:yjs}
-The JavaScript library Yjs\footnote{https://github.com/y-js/yjs} describes itself as \enquote{a framework for offline-first \ac{P2P} shared editing on structured data-like text, richtext, \ac{JSON}, or \ac{XML}}\cite{yjsXXXXrepo}. The library takes care of solving synchronization conflicts when editing distributed files. By choosing a connector, you can set the protocol for the communication between the peers.There is the possibility to use \ac{WebRTC}, \ac{XMPP} or websockets, but with some connectors running a server is a prerequisite. Further extensions can be used to supplement a database and data types, but the focus here is on the joint editing of data by multiple peers. For all connectors, the authors of the library recommend using an own server. Yjs is released under the MIT license.
+The JavaScript library Yjs\footnote{https://github.com/y-js/yjs} describes itself as \enquote{a framework for offline-first \ac{P2P} shared editing on structured data-like text, richtext, \ac{JSON}, or \ac{XML}}\cite{yjsXXXXrepo}. The library takes care of solving synchronization conflicts when editing distributed files. By choosing a connector, you can set the protocol for the communication between the peers. There is the possibility to use \ac{WebRTC}, \ac{XMPP} or websockets, but with some connectors running a server is a prerequisite. Further extensions can be used to supplement a database and data types, but the focus here is on the joint editing of data by multiple peers. For all connectors, the authors of the library recommend using an own server. Yjs is released under the MIT license.
 
 \subsubsection{Hive2Hive}
 \label{sec:hive2hive}
-Hive2Hive\footnote{https://github.com/Hive2Hive/Hive2Hive} is a Java library for \enquote{secure, distributed, \ac{P2P}-based file synchronization and sharing}\cite{hive2hiveXXXXrepo}. There is no less promise than \enquote{a free and open-sourced, distributed and scalable solution that focuses on maximum security and privacy of both users and data}\cite{hive2hiveXXXXrepo}. In order to be able to use Hive2Hive globally via the Internet, it is necessary to operate at least one relay peer - five are recommended for sufficient data replication \cite{hive2hiveXXXXguide}. Since a permanent \ac{TCP} connection between peer and relay peer is maintained, the power consumption is quite high. Constant \ac{TCP} connection can be avoided by using Google Cloud Messaging. However, Google has already discontinued this service. And since the development of Hive2Hive was discontinued in March 2015 too, there is currently no solution to this problem. Hive2Hive is released under the MIT license.
+Hive2Hive\footnote{https://github.com/Hive2Hive/Hive2Hive} is a Java library for \enquote{secure, distributed, \ac{P2P}-based file synchronization and sharing}\cite{hive2hiveXXXXrepo}. There is no less promise than \enquote{a free and open-sourced, distributed and scalable solution that focuses on maximum security and privacy of both users and data}\cite{hive2hiveXXXXrepo}. In order to be able to use Hive2Hive globally via the Internet, it is necessary to operate at least one relay peer - five are recommended for sufficient data replication \cite{hive2hiveXXXXguide}. Since a permanent \ac{TCP} connection between peer and relay peer is maintained, the power consumption is quite high. Constant \ac{TCP} connection can be avoided by using Google Cloud Messaging. However, Google has already discontinued this service. Moreover, the development of Hive2Hive was stopped in March 2015 too, there is currently no solution to this problem. Hive2Hive is released under the MIT license.
 
 \subsubsection{GUN}
 \label{sec:gun}
@@ -67,10 +67,10 @@ Due to its characteristics, \ac{IPFS} is an ideal complement to the blockchain a
 
 \subsection{Application Framework}
 \label{sec:application-framework}
-With the Android \ac{SDK} apps for Android can be written in Java, Kotlin, and C++. Tools of the Android \ac{SDK} compile code, data, and resource files to an executable \ac{APK}. This way, only device-specific applications for the Android operating system can be created.
+With the Android \ac{SDK} apps for Android can be written in Java, Kotlin, and C++. Tools of the Android \ac{SDK} compile code, data, and resource files to an executable \ac{APK}. This way, only device-specific applications for the Android operating system can be created. \cite{androidXXXXfundamentals}
 
 The open source framework Ionic\footnote{https://ionicframework.com/} is used to create hybrid apps and \acp{PWA}. A hybrid app combines the advantages of a native app with those of web applications. With \ac{HTML}, \ac{CSS}, and JavaScript, this framework can be used to design platform-independent applications (including Android and iOS). The core of Ionic is based on the JavaScript Framework Angular and Apache Cordova, which serves as a bridge to access sensors and functions of the device. Ionic can be used free of charge and is published under the MIT license, so private and commercial use is permitted.
 
-Compared to the standard way of programming an Android app to the use of Ionic, the platform independence and the JavaScript language are the two main advantages. With Ionic, the same code can be used to create apps for the majority of mobile operating systems. Additionally, as \ac{PWA} the app runs also in every modern web browser. The previously defined requirements of a hybrid solution demanded this independence, so Ionic is a good match. Regarding the programming language JavaScript, many projects in the field of \acp{dApp} and decentralization in general provide only libraries for JavaScript (e.g., GUN). Besides, JavaScript is also the language to write add-ons for browsers. Even though Ionic cannot be used to create browser add-ons, the used JavaScript libraries can. So, the same technology could be used to deliver clients to all popular environments.
+Comparing the standard way of programming an Android app to the use of Ionic, the platform independence and the JavaScript language are the two main advantages. With Ionic, the same code can be used to create apps for the majority of mobile operating systems. Additionally, as \ac{PWA} the app runs in every modern web browser. The previously defined requirements of a hybrid solution demanded this independence, thus Ionic is a good match. Regarding the programming language JavaScript, many projects in the field of \acp{dApp} and decentralization in general provide only libraries for JavaScript (e.g., GUN). Besides, JavaScript is the language to write add-ons for browsers. Even though Ionic cannot be used to create browser add-ons, the used JavaScript libraries are able to do so. Hence, the same technology could be used to deliver clients to all popular environments.
 
 With React Native\footnote{https://facebook.github.io/react-native/} and NativeScript\footnote{https://www.nativescript.org/} there are comparable frameworks to Ionic. They also use JavaScript and are used to create hybrid apps for several environments. But the provided components to create the user interface are most promising with Ionic and the initial learning barrier is low compared to the other two. Because of these advantages, Ionic was finally chosen for programming the Hybrid \ac{OSN} client app.

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

@@ -1,4 +1,4 @@
-In the threat model of Hybrid \ac{OSN} the potential threats for different sub-areas are shown, and the particular risk discussed. The worst would be if private data could be decrypted and assigned to a user or if identity abuse were possible. However, other dangers such as identification by the service provider or manipulation of data must also be analyzed.
+In the threat model of Hybrid \ac{OSN} the potential threats for different sub-areas are shown, and the particular risk discussed. The worst would be if private data could be decrypted and assigned to a user or if identity abuse were possible. However, other dangers such as identification by the service provider or manipulation of data must be analyzed.
 
 \subsection{Service Provider – Twitter}
 \label{sec:threat-model-service-provider}
@@ -32,7 +32,7 @@ Due to the decentralization of the system, the availability of \ac{IPFS} is alwa
 
 \subsection{Encryption – Leakage of Keys}
 \label{sec:threat-model-encryption}
-On the one hand, the public key history is symmetrically encrypted; on the other hand, the private tweets are asymmetrically encrypted. The keys for asymmetric encryption are generated independently by each user and are therefore individual for each user. With symmetric encryption, only one key is used, which is stored in the source code of Hybrid \ac{OSN}. In this way, only the Hybrid \ac{OSN} app can decrypt the public key history of a user and therefore decrypt its private tweets.
+On the one hand, the public key history is symmetrically encrypted; on the other hand, the private tweets are asymmetrically encrypted. The keys for asymmetric encryption are generated independently by each user and are therefore individual for each user. With symmetric encryption, just one key is used, which is stored in the source code of Hybrid \ac{OSN}. In this way, only the Hybrid \ac{OSN} app can decrypt the public key history of a user and therefore decrypt its private tweets.
 
 Disclosure of the source code would reveal the symmetric key. The service provider would then have all the necessary information and access to all data to read private tweets and assign them to users.
 
@@ -42,4 +42,4 @@ A user's private tweets should be readable by all users who can also read the pu
 
 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. Only accepted followers should then be able to read public and private tweets. A non-approved twitter 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.
+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 twitter 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.