Fix typos, add captions

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

@@ -1,4 +1,4 @@
-The software system architecture describes the relationships and properties of individual software components. It is a model that describes a software on a high-level design. The structure of an architecture can be represented mathematically as a graph, with the nodes representing the individual software components and the edges their relationships to each other. Although the individual components can be executed on the same computer, they are usually interconnected via networks. In general, a distinction is made between the architectures shown in Figure \ref{fig:software-system-architecture}.
+The software system architecture describes the relationships and properties of individual software components. It is a model that describes a software on a high-level design. The structure of an architecture can be represented mathematically as a graph, with the nodes representing the individual software components and the edges their relationships to each other. Although the individual components can be executed on the same computer, they are usually interconnected via networks. In general, a distinction is made between centralized, decentralized and distributed architectures as shown in Figure \ref{fig:software-system-architecture}.
 
 \begin{figure}[h!]
 	\centering
@@ -21,7 +21,7 @@ In a centralized application, the software essentially runs on a central node wi
 
 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.
 
-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 not only need to have low resources.
+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 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.
 
@@ -29,7 +29,7 @@ The biggest disadvantage with this architecture is that with the failure or the
 \label{sec:decentralized-applications}
 What are 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 amount of users covered by its resources. New servers contribute new resources to the overall system. Distributed applications can not 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 can not be evaluated, so that user data are better protected. Also, there is no longer an attack target whereby hacking a single server loses lucrativeness.
+Thus, the advantages of decentralized applications include, in addition to the already mentioned increased reliability, even further advantages. Each server only records the amount of users covered by its resources. New servers contribute new resources to the overall system. Distributed applications can not 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 can not 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.
 
@@ -58,6 +58,6 @@ The following table \ref{tab:comparison-architectures} compares the main feature
 		\multicolumn{1}{|l|}{Performance}                                                  & ++                                       & +                                          &                                          \\ \hline
 		\multicolumn{1}{|l|}{\begin{tabular}[c]{@{}l@{}}Data \\ Availability\end{tabular}} & ++                                       & +                                          &                                          \\ \hline
 	\end{tabular}
-	\caption{Comparison of different software system architectures on scalability, maintenance, system stability, performance and data availability.}
+	\caption{Comparison of different software system architectures on scalability, maintenance, system stability, performance and data availability. The pluses indicate how positive something is relatively to the other systems.}
 	\label{tab:comparison-architectures}
 \end{table}

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 behind ActivityPub}
+	\caption{Concept behind ActivityPub \cite{w3c2018activity-pub}}
 	\label{fig:activitypub-communication}
 \end{figure}
 
@@ -23,7 +23,7 @@ Each actor has some so called collections. To these collections, objects can be
 	\item \textbf{Liked Collection}: List of all objects the actor has liked
 \end{itemize}
 
-The following interactions are defined between the client and the server, but some of them are optional to implement: Create, Update, Delete, Follow, Add (add objct to collection), Remove (remove object from collection), Like, Block, Undo. To address the activities, \textit{to}, \textit{bto}, \textit{cc}, \textit{bcc} provide the same possibilities as are known from e-mail. The server then has to ensure that the activity also reaches the addressed actors.
+The following interactions are defined between the client and the server, but some of them are optional to implement: Create, Update, Delete, Follow, Add (add object to collection), Remove (remove object from collection), Like, Block, Undo. To address the activities, \textit{to}, \textit{bto}, \textit{cc}, \textit{bcc} provide the same possibilities as are known from e-mail. The server then has to ensure that the activity also reaches the addressed actors.
 
 \subsubsection{Server to Server (Federation Protocol)}
 \label{sec:federation-protocol}

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

@@ -16,4 +16,4 @@ The data of the users are unencrypted on a pod, so that someone having access to
 
 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 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\footnote{https://the-federation.info/diaspora} on February 24, 2019, 679723 users were registered on a total of 251 pods. Over the last 12 months, 19591 new users have joined the network. Last month, only 4.4\% of all users were active with 30042 users. However, the numbers are incomplete, as some pods do not share information and there may be more than the 251 listed pods.
+According to the statistics of the-federation.info\footnote{https://the-federation.info/diaspora} on February 24, 2019, 679723 users were registered on a total of 251 pods. Over the last 12 months, 19591 new users have joined the network. In January 2019, only 4.4\% of all users were active with 30042 users. However, the numbers are incomplete, as some pods do not share information and there may be more than the 251 listed pods.

thesis/content/03-related-work/peepeth.tex

@@ -21,4 +21,4 @@ In addition to writing short messages, it is possible to like posts. However, po
 
 On 29th January 2019, Peepeth had 4055 users who posted a total of 66262 Peeps. For an account at Peepeth you first have to apply and after some time you will receive a link by email to join the platform. On invitation of an active user, new users can join directly without waiting time. Users can verify themselves with their existing Github and Twitter accounts. In the future, it will be possible to use further platforms for the verification of an account. In order to verify an account, the user must post a \enquote{special message}, which also contains his Ethereum address. The link to this post must then be handed over to a Smart Contract, which confirms the ownership of the account.
 
-Peepeth communicated the next milestones to increase the user experience as part of the crowdfunding campaign. The first milestone has already been reached. The fact that the possession of a cryptocurrency requirement for the use and procurement of such a currency is difficult was to be eliminated. PeepEht bears the costs for its users. The next steps are the use without special software requirements (renouncement of special browsers or MetaMask) and the development of an iOS app. However, only 140.56 ETH could be collected from the required 1000 ETH. It is unclear to what extent the desired goals will now be achieved.
+Peepeth communicated the next milestones to increase the user experience as part of the crowdfunding campaign. The first milestone has already been reached. The fact that the possession of a cryptocurrency requirement for the use and procurement of such a currency is difficult was to be eliminated. Peepeth bears the costs for its users. The next steps are the use without special software requirements (renouncement of special browsers or MetaMask) and the development of an iOS app. However, only 140.56 ETH could be collected from the required 1000 ETH. It is unclear to what extent the desired goals will now be achieved.

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

@@ -5,7 +5,7 @@ Daubert et al. made various demands on the proposed solution. With regard to the
 
 \begin{itemize}
 	\item \textbf{Confidentiality}: Messages exchanged between sender and receiver should be transmitted secretly.
-	\item \textbf{Anonymity}:
+	\item \textbf{Anonymity}: A certain user should not be identifiable within a set of users (anonymity set).
 \end{itemize}
 
 And with regard to the design of the implementation:
@@ -32,14 +32,14 @@ In order join the group, other users need the key and knowledge of the name of t
 
 If the users of a group with a common hashtag are all aware of the key and the hash tag, the second phase of building an overlay network begins. Here the private flooding mechanism is used\cite{daubert2013distributed-anonymous-pubsub}. A publisher creates an advertisement tweet consisting of a pseudonym and the first element of a hash chain and posts it in the underlay network. This tweet appears in the timelines of his followers. If not already done, each follower distributes the advertisement tweet on his own timeline and thus reaches his own followers. However, this tweet differs from the original tweet by extending the hash chain. It generates a hash of the previous hash chain and thus receives the next element of the chain. According to this principle, the entire network is flooded and as a result, each user saves a triplet consisting of pseudonym, hash chain and the user before him in the chain in a database table.
 
-If the advertisement tweet reaches a user who is aware of the hashtag and the associated key, the user responds with a subscription tweet. This message is addressed to the user from whom the advertisement tweet was received and contains the user name (@user) and the pseudonym. The user thus addressed in turn posts a message consisting of the user name of the user from whom he received the advertisement tweet and the pseudonym. This happens until the original publisher has been reached. In this process, another routing table is filled with pseudonym and sending user. The overlay network is thus formed. Since each user only has a local view of the message flow, no conclusions about sender and recipient can be drawn from the message flow.
+If the advertisement tweet reaches a user who is aware of the hashtag and the associated key, the user (so called subscriber) responds with a subscription tweet. This message is addressed to the user from whom the advertisement tweet was received and contains the user name (@user) and the pseudonym. The user thus addressed in turn posts a message consisting of the user name of the user from whom he received the advertisement tweet and the pseudonym. This happens until the original publisher has been reached. In this process, another routing table is filled with pseudonym and sending user. The overlay network is thus formed. Since each user only has a local view of the message flow, no conclusions about sender and recipient can be drawn from the message flow.
 
 In the third phase, users can exchange messages using the previously shared hashtag. The messages are encrypted with the key belonging to the hashtag and then posted together with the hashtag to the timeline. By posting the message again, forwarders ensure that the message is forwarded to the recipient. The exact procedure is shown schematically in Figure \ref{fig:twitterize-information-flow}.
 
 \begin{figure}[h!]
 	\centering
 	\includegraphics[width=1.0\textwidth]{twitterize-information-flow}
-	\caption{.\cite{daubert2014twitterize}}
+	\caption{Information flow of a notification. The notification is created, encrypted and posted to the publisher's timeline. The notification is then picked up by a forwarder who follows the publisher. Next, the status update is being processed and finally posted on the forwarder's timeline. Lastly, the subscriber who follows the forwarder receives the notification. \cite{daubert2014twitterize}}
 	\label{fig:twitterize-information-flow}
 \end{figure}
 

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

@@ -28,8 +28,9 @@ The advantages and disadvantages of the different strategies are listed in Table
 
 \newcommand{\disadvantageoi}{\begin{minipage} [t] {0.3\textwidth} 
 		\begin{itemize}
-			\item expenses
+			\item Expenses
 			\item Who operates the infrastructure?
+			\item Compliance with legal requirements
 		\end{itemize}
 \end{minipage}}
 

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

@@ -69,11 +69,11 @@ Table \ref{tab:pages} lists all pages and their purpose. When the app is opened,
 		Home                          & Chronological view of the latest tweets from Twitter and the private network                                                             \\ \hline
 		Login                         & Authentication against Twitter to use the Twitter API                                                                                    \\ \hline
 		Profile                       & Presentation of a user profile consisting of the user data (profile picture, brief description, location, website) and the user timeline \\ \hline
-		Search                        & Container page for searching for tweets and users, where tweets are also divided into popular and recent (see Search-Reuslts-Tweets-Tab) \\ \hline
-		Search-Reuslts-Tweets-Popular & Search results of currently popular tweets for a given keyword                                                                           \\ \hline
-		Search-Reuslts-Tweets-Recent  & Search results of recent tweets for a given keyword                                                                                      \\ \hline
-		Search-Reuslts-Tweets-Tab     & Container page for the search results for tweets (recent and popular) in tabs                                                            \\ \hline
-		Search-Reuslts-Users          & Search results of users for a given keyword                                                                                              \\ \hline
+		Search                        & Container page for searching for tweets and users, where tweets are also divided into popular and recent (see Search-Results-Tweets-Tab) \\ \hline
+		Search-Results-Tweets-Popular & Search results of currently popular tweets for a given keyword                                                                           \\ \hline
+		Search-Results-Tweets-Recent  & Search results of recent tweets for a given keyword                                                                                      \\ \hline
+		Search-Results-Tweets-Tab     & Container page for the search results for tweets (recent and popular) in tabs                                                            \\ \hline
+		Search-Results-Users          & Search results of users for a given keyword                                                                                              \\ \hline
 		Settings                      & Configuration of keywords that trigger the private mode and settings regarding encryption                                                \\ \hline
 		Write-Tweet                   & Form for writing a tweet                                                                                                                 \\ \hline
 	\end{tabularx}

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

@@ -2,7 +2,7 @@ When selecting a suitable OSN for the development of a hybrid client, Facebook w
 
 However, the Facebook API is not suitable for developing an own client anyway. The functionalities offered by the 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 make a like for a post through this API, which is part of the core functionality of a Facebook client. As discussed in Chapter 4, 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 entry\cite{facebook2017release} that the code changes every few hours. Therefore it is almost impossible to adjust the crawler fast enough and roll out the adjusted 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 "Friendly for Facebook" don't manage to keep up with the changes. The result is erroneous representations that worsen the user experience.
+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 "Friendly for Facebook" don't manage to keep up with the changes as reported in various user ratings on the Google Play Store. The erroneous representations and bugs worsen the user experience and result in frustration of users.
 
 For this number of reasons, Facebook dropped out as OSN candidate for the prototype despite the special interest. As a further candidate, the OSN Google Plus was dropped, as Google announced in October 2018 that it would discontinue its OSN\cite{google-plus2018shutdown}.