Improve gramar and fix typos

thesis/content/04-concept/introduction.tex

@@ -1,10 +1,10 @@
-The criticism of the protection of privacy on the Internet, especially in social networks, is not new. As early as 2010, the founders of diaspora* discovered that there was no social network that sufficiently protected the privacy of users\cite{diaspora2010kickstarter-pitch}. Their idea of a decentralized network that protected user data by design convinced so many people that even before the start of the development people donated \$200,000 instead of the required \$10,000 to a kickstarter campaign.
+The criticism of the protection of privacy on the Internet, especially in social networks, is not new. As early as 2010, the founders of diaspora* discovered that there was no social network that sufficiently protected the privacy of users\cite{diaspora2010kickstarter-pitch}. Their idea of a decentralized network that protected user data by design convinced so many people that even before the start of the development people donated \$200,000 instead of the required \$10,000 to a Kickstarter campaign.
 
-The reason for the poor protection of personal data lies in the centralized system structure used by all leading social platforms. With this structure, the data is stored centrally and largely unencrypted. The service provider therefore inevitably has access to this data. Which data is collected during use and what happens to the data is not transparent to the user.
-On the one hand, the user data is evaluated in order to improve the user experience (suggestions for content matching the user’s preferences using recommender systems), but on the other hand also in order to make a profit. Revenues can be generated through personalized advertising or, in the worst case, through the sale of data. Furthermore, the protection of data against access by third parties via official interfaces (harvesting) or unauthorized hacking cannot be ruled out. And last but not least, due to applicable law, it may be necessary for data to be transferred to secret services or government agency.
+The reason for the inadequate protection of personal data lies in the centralized system structure used by all leading social platforms. With this structure, the data is stored centrally and mostly unencrypted. The service provider therefore inevitably has access to this data. Which data is collected during use and what happens to the data is not transparent to the user.
+On the one hand, the user data is evaluated in order to improve the user experience (suggestions for content matching the user’s preferences using recommender systems), but on the other hand also in order to make a profit. Revenues can be generated through personalized advertising or, in the worst case, through the sale of data. Furthermore, the protection of data against access by third parties via official interfaces (harvesting) or unauthorized hacking cannot be ruled out. Last but not least, due to applicable law, it may be necessary for data to be transferred to secret services or government agencies.
 
-Although the problems and dangers have been known for a long time and new scandals regularly become known to the public, the users remain largely loyal to the respective social networks. Alternative social networks, which focus on privacy protection, lack attractiveness, so that they gain only a few users and often fail after a short time. Obviously, the connection to the respective social network is so strong that the barrier to switching to another, more secure social network is not overcome. The amount of content already created, the network built, and the large number of contacts using the same platform all create this so-called lock-in effect.
+Although the problems and dangers 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. Alternative social networks, which focus on privacy protection (e.g., Vero\footnote{https://www.vero.co}, Ello\footnote{https://ello.co}), lack attractiveness so that they gain only a few users and often fail after a short time. The connection to the respective social network is so strong that the barrier to 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 alternative, it is necessary to look for ways to better protect users and their data 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 research area B \enquote{Privacy and Trust in Social Networks} is dealing with problems like this. Subarea B.2 deals specifically with the protection of privacy in hybrid social networks.
 
-In the following, a concept for a hybrid social network will be developed that tries to take into account the interests of the different stakeholders. In addition, functionality requirements and potential limitations are listed. Finally, a solution strategy is shown and a possible architecture is presented. The concept should be applicable to all social networks. A specific implementation will be presented in the next chapter for Twitter.
+In the following, a concept for a hybrid social network will be developed that tries to take into account the interests of the different stakeholders. Besides, functionality requirements and potential limitations are listed. Finally, a solution strategy is shown, and a possible architecture is presented. The concept should apply to all social networks. A specific implementation will be presented in the next chapter for Twitter.

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

@@ -1,4 +1,4 @@
-The following quality objectives (Table \ref{tab:quality-goals}) have been defined to ensure that the quality of implementation is as high as possible. By adhering to the quality targets, errors and problems are to be avoided, the application is to remain maintainable and new developers are to be enabled to get started quickly.
+The following quality objectives (Table \ref{tab:quality-goals}) have been defined to ensure that the quality of implementation is as high as possible. By adhering to the quality goals, errors and problems should be avoided, the application should remain maintainable, and new developers should be enabled to get started quickly.
 
 \begin{table}[h!]
 	\centering

thesis/content/04-concept/requirements.tex

@@ -1,23 +1,23 @@
-In order for users of an OSN to be willing to use another client for or an additional extension when using the OSN, the solution should meet certain functional and non-functional requirements.
+The solution should meet specific functional and non-functional requirements so that users are willing to use another client.
 
 \textbf{Functional requirements}:
 \begin{itemize}
-	\item The standard functionality of the OSN can be used without restrictions.
-	\item The user can clearly see which way (private or OSN) the data goes and where it comes from.
+	\item The standard functionality of the OSN is usable without restrictions.
+	\item The user can see which way (private P2P or public OSN) the data comes from and where it goes.
 	\item Data access should only be possible for authorized users.
-	\item The data exchange should be automatically encrypted, so that the data is worthless for third parties.
+	\item The data exchange should be automatically encrypted so that the data is worthless for third parties.
 	\item The data format is flexible in order to map changes and new OSN functionalities.
-	\item Platform independence
-	\item The solution is client-side, since the OSN Server cannot be influenced
+	\item The solution is client-side since there is no control over the OSN server.
 	\item The OSN Service Provider can retrieve anonymized data relevant to him.
+	\item The solution is platform independent.
 \end{itemize}
 
 \textbf{Non-functional requirements}:
 \begin{itemize}
 	\item Data exchange over the private network is fast and secure.
-	\item Simple, understandable user interface
-	\item Attractive, modern design
-	\item No violation of the guidelines and terms of use of the OSN
-	\item No restrictions for classic users who do not use the hybrid solution
+	\item The user interface is simple and understandable.
+	\item The design of the app is modern and appealing.
+	\item No violation of the guidelines and terms of use/service of the OSN.
+	\item No restrictions for standard users who do not use the hybrid solution.
 	\item The additional effort for the user when using the hybrid solution should be minimal.
 \end{itemize}

thesis/content/04-concept/restrictions.tex

@@ -1,10 +1,10 @@
-When designing the hybrid OSN, there are a few limitations that need to be considered, for which appropriate solutions can be found. These restrictions include:
+When designing the hybrid OSN, there are a few limitations that need to be considered, for which appropriate solutions have to be found. These restrictions include:
 
 \begin{itemize}
-	\item \textbf{Interfaces of the OSN}: Ideally the OSN offers a public API with the full functionality. Since the user's data should be protected as best as possible, access via the API is normally restricted. This may be due to a limited number of requests per time interval or a limited range of offered functions.
-	\item \textbf{Crawling the OSN web pages}: If there is no official API or if it is strongly restricted, the contents can theoretically also be extracted by crawling. However, this brings with it several challenges. Modern web pages load many contents asynchronously, so that the initial HTML does not yet contain these contents. Furthermore, there are sophisticated mechanisms that notice crawling and lock out crawlers. Likewise, it may be difficult to add data to the OSN. For security reasons, in most cases, special tokens are sent along with each request to detect and prevent abuse and fake requests.
-	\item \textbf{Development, operation and licensing costs}: Costs for the development, operation and licensing of third-party software may incurred. At best, the costs can be avoided by conscious decisions.
-	\item \textbf{Operating system or runtime environment}: Nowadays OSNs can be used on almost all devices; independent of their operating system. In order to achieve the same user experience, the hybrid OSN should be usable on the same platforms. Any restrictions imposed by the operating system (user and application rights, connectivity, etc.) must be taken into account during development.
+	\item \textbf{Interfaces of the OSN}: Ideally the OSN offers a public API with full functionality. Since the user's data should be protected as best as possible, access via the API is usually restricted. The restriction may be due to a limited number of requests per time interval or a limited range of offered functions.
+	\item \textbf{Crawling the OSN web pages}: If there is no official API or if it is sharply restricted, the contents can theoretically also be extracted by crawling. However, this brings with it several challenges. Modern web pages load many contents asynchronously so that the initial HTML does not yet contain these contents. Furthermore, there are sophisticated mechanisms that notice crawling and lock out crawlers. Likewise, it may be difficult to add data to the OSN. For security reasons, in most cases, special tokens are sent along with each request to detect and prevent abuse and fake requests.
+	\item \textbf{Development, operation and licensing costs}: Costs for the development, operation and licensing of third-party software may incurred. At best, conscious decisions lead to the avoidance of expenses.
+	\item \textbf{Operating system or runtime environment}: Nowadays OSNs can be used on almost all devices; independent of their operating system. In order to achieve the same user experience, the hybrid OSN should be usable on the same platforms. Any restrictions imposed by the operating system (user and application rights, connectivity) must be taken into account during development.
 	\item \textbf{Resources}: The devices running the hybrid OSN may have limited resources (storage space, processing power, Internet connection/data volume, battery). When making design decisions, it is important to plan as resource-conserving as possible and to find scalable solutions. Overall, the overhead for the hybrid extension should be as low as possible compared to the original application.
 	\item \textbf{Availability of data}: The data that is exchanged securely and not via the OSN's servers must always be available. Whether a user is offline or how old the data is must not affect its availability.
 \end{itemize}

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

@@ -1,4 +1,4 @@
-Various models can be used to implement secure data exchange between the users of an OSN via an add-on. The solution strategies shown below differ essentially in the question of where data is stored and how it can be found.
+Various models can be used to implement a secure data exchange between the users of an OSN via an add-on. The solution strategies shown below differ primarily in the question of where data is stored and how it can be found.
 
 \begin{figure}[h!]
 	\centering
@@ -7,13 +7,14 @@ Various models can be used to implement secure data exchange between the users o
 	\label{fig:solution-strategy-architecture}
 \end{figure}
 
-One possibility is to use an extra infrastructure to store the data, as shown in Figure \ref{fig:solution-strategy-architecture}.a. Additional servers are used to store and distribute the private data to be protected. This has the advantage that the data is always available and there are no dependencies to other hybrid OSN users. Furthermore, resources must only be available centrally and not locally for every user. At the central location the data can be indexed and specifically queried. However, it is problematic that one or more such servers must be operated and maintained. In principle, the question of the operators must be clarified, because the infrastructure must function reliably. An architecture based on this proposal was used by FaceCloak.
+One possibility is to use an extra infrastructure to store the data, as shown in Figure \ref{fig:solution-strategy-architecture}.a. Additional servers are used to store and distribute the private data to be protected. Using additional servers has the advantage that the data is always available and there are no dependencies to other hybrid OSN users. Furthermore, resources must only be available centrally and not locally for every user. At the central location, the data can be indexed and explicitly queried. However, the operation and maintenance of one or more such servers are problematic. In principle, the question of the operators must be clarified, because the infrastructure must function reliably. An architecture based on this proposal was used by FaceCloak.
 
-In contrast, a decentralized or distributed solution strategy would create a network among users of the hybrid application. This strategy is depicted in Figure \ref{fig:solution-strategy-architecture}.b. No extra infrastructure would have to be operated. The users would then have a classic peer role. With this model, solutions must be found for how data is always available and can be found, even if a user is temporarily or permanently offline. Furthermore, the resources on the end devices are limited, so that effective, economical solutions are needed. Another challenge is the addressing of peers. Since they typically do not have a static IP address, but the IP address changes frequently, solutions must be found for accessibility. Since there is no central, global index, finding data is even more difficult.
+In contrast, a decentralized or distributed solution strategy would create a network among users of the hybrid application. This strategy is depicted in Figure \ref{fig:solution-strategy-architecture}.b. No extra infrastructure would have to be operated. The users would then have a typical peer role. With this model, solutions must be found for how data is always available and can be found, even if a user is temporarily or permanently offline.
+Furthermore, the resources on the end devices are limited, so that effective, economical solutions are needed. Another challenge is the addressing of peers. Since they typically do not have a static IP address, but the IP address changes frequently, solutions must be found for accessibility. Since there is no central, global index, finding data is even more difficult.
 
-An interim solution is also conceivable, in which an existing infrastructure, e.g. an already existing P2P network or the block chain, is used for storing and exchanging data. Since no influence can be exerted on an existing infrastructure, its use entails further restrictions and potential risks.
+An interim solution is also conceivable, in which an existing infrastructure, e.g., an already existing P2P network or the blockchain, is used for storing and exchanging data. Since no influence can be exerted on existing infrastructure, its use entails further restrictions and potential risks.
 
-The advantages and disadvantages of the different strategies are listed in Table \ref{tab:solution-strategy-architecture-comparison} below.
+Table \ref{tab:solution-strategy-architecture-comparison} lists the advantages and disadvantages of the different strategies.
 
 % Own infrastructure
 \newcommand{\advantageoi}{\begin{minipage} [t] {0.3\textwidth} 

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

@@ -1,7 +1,7 @@
-With regard to the implementation of the hybrid approach, two possibilities are conceivable. On the one hand, the extension of the original OSN client (app or web front end) as an addon. On the other hand, the development of a completely new client.
+Concerning the implementation of the hybrid approach, two possibilities are conceivable. On the one hand, the extension of the original OSN client (app or web front end) as an addon. On the other hand, the development of an entirely new client.
 
-When the OSN is extended by an addon, the conventional functionality of the OSN does not have to be taken care of. Therefore, the development can be completely focused on the addon. At crucial points, the addon ensures that the interface is extended by additional elements that enable secure data exchange. The service providers usually do not offer developers an interface to extend the OSN with such own functionalities. With web front ends it is possible to manipulate the website content using browser add-ons. One example for doing so is FaceCloak. Since such browser extensions manipulate the Document Object Model (DOM), knowledge about the document structure is necessary for the successful function in order to make changes in the right places. The short release cycles of OSNs and the associated frequent changes to this DOM structure make it difficult to keep up with the changes. When consuming the OSN via the official apps on mobile devices, an extension or manipulation is not possible.
+When an addon extends the OSN, there is no need to take care of the standard functionality of the OSN. Therefore, the development can entirely focus on the addon and the private extension. At crucial points, the add-on extends the interface by additional elements that enable secure data exchange. The service providers usually do not offer developers an interface to extend the OSN with such own functionalities. With web front ends it is possible to manipulate the website content using browser add-ons. One example for doing so is FaceCloak. Since such browser extensions manipulate the Document Object Model (DOM), knowledge about the document structure is necessary for the successful function in order to make changes in the right places. The short release cycles of OSNs and the associated frequent changes to this DOM structure make it difficult to keep up with the changes. When consuming the OSN via the official apps on mobile devices, an extension or manipulation is not possible.
 
-The alternative to the extension approach described above is an extra hybrid client app. The entire functional range of the OSN must be implemented and kept up to date. As already mentioned with the restrictions, the functions are usually not provided completely via an API and the crawling of the content also brings with it some challenges. By having complete control over the development, the additional protected, secure communication can be added at the appropriate points. In the best-case scenario, at least one hybrid app is available for every operating system for which an official OSN app exists.
+The alternative to the extension approach described above is a new hybrid client app. The entire functional range of the OSN must be implemented and kept up to date. As already mentioned with the restrictions (see \ref{sec:requirements}), the functions are usually not entirely provided via an API, and the crawling of the content also brings with it some challenges. By having complete control over the development of the client, the additional protected, secure communication can be added at the appropriate points. In the best-case scenario, at least one hybrid app is available for every operating system for which an official OSN app exists.
 
 Both approaches can be combined by displaying the (mobile) web page of the OSN in a WebView in a separate app and executing DOM manipulations via injected JavaScript code. For example, there are some alternative clients for Facebook (e.g. \enquote{Friendly for Facebook}\footnote{https://play.google.com/store/apps/details?id=io.friendly} \footnote{https://itunes.apple.com/de/app/friendly-for-facebook/id400169658}, \enquote{Metal Pro}\footnote{https://play.google.com/store/apps/details?id=com.nam.fbwrapper.pro}) that use this approach.

thesis/content/04-concept/stakeholders.tex

@@ -1,4 +1,4 @@
-Even if the stakeholders are not necessarily directly involved, it is still important to understand the views and interests of the various parties and take them into account in the design. Table \ref{tab:steakholders} shows the interests and points of view of the parties involved directly and indirectly.
+Even if the stakeholders are not necessarily directly involved, it is still essential to understand the views and interests of the various parties and take them into account in the design. Table \ref{tab:steakholders} shows the interests and points of view of the parties involved directly and indirectly.
 
 % Interests
 \newcommand{\interestsSP}{\begin{minipage} [t] {0.4\textwidth} 
@@ -121,7 +121,7 @@ Even if the stakeholders are not necessarily directly involved, it is still impo
 			\begin{tabular}[c]{@{}l@{}}Developer\\ hybrid OSN\end{tabular} & \interestsDevHOSN  & \attitudeDevHOSN                     & \influenceDevHOSN                \\ \hline
 			Governments                                                    & \interestsGov      & \attitudeGov                         & \influenceGov                    \\ \hline
 		\end{tabular}
-		\caption{Interests, attitude towards a hybrid solution and influence on the hybrid solution of several stakeholders.}
+		\caption{The table shows the interests, attitudes towards a hybrid solution and influence on the hybrid solution of several stakeholders.}
 		\label{tab:steakholders}
 	\end{table}
 \end{landscape}

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

@@ -1,4 +1,4 @@
-In this section, the context in which Hybrid 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 certain 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 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.
 
 \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 IPFS via a simple interface. Communication with the API happens using simple HTTP requests. The connection of IPFS in hybrid OSN can thus be carried out in an uncomplicated way. The use of an additional system entails typically an additional risk. However, there is a JavaScript client for IPFS, which can be integrated into hybrid OSN and thus the dependency on Infura would be omitted. At the present time and for the development of the prototype, the decision was made to use Infura for reasons of simplicity. Infura can be used for IPFS free of charge and without registration.
+Infura\footnote{https://infura.io/} is a service that provides access to Ethereum and IPFS via a simple interface. Communication with the API happens using HTTP requests. The connection of IPFS in Hybrid 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 IPFS, which can be integrated into Hybrid 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 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 OSN Angular 5.2 is used. Accordingly, the hybrid 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 OSN.
+The used Ionic framework uses Angular in the core, in the concrete case of Hybrid OSN Angular 5.2 is used. Accordingly, the Hybrid 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 OSN.
 
 \subsubsection{Providers}
 \label{providers}
-Data access is performed using providers (known as services in Angular). For the external services (Twitter API, P2P database, P2P storage), there is one provider each to handle the communication. In addition, providers are used as helper classes that provide a certain functionality that is used several times. This 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 API, P2P database, 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.
 
 \begin{table}[h!]
 	\begin{tabularx}{\textwidth}{|l|X|}
@@ -40,13 +40,13 @@ Data access is performed using providers (known as services in Angular). For the
 		P2P-Storage-IPFS  & Interface for data exchange with IPFS via Infura                                             \\ \hline
 		Twitter-API       & Interface to use the Twitter API using the Twit package                                      \\ \hline
 	\end{tabularx}
-	\caption{Providers used in the hybrid OSN app in alphabetical order with their purpose.}
+	\caption{Providers used in the Hybrid OSN app in alphabetical order with their purpose.}
 	\label{tab:providers}
 \end{table}
 
 \subsubsection{Components}
 \label{sec:components}
-Components are the basic building blocks of a user interface. Figure \ref{fig:component-example} shows an example for the representation of a tweet in hybrid OSN using various components. A component consists of an HTML template, CSS styling and JavaScript logic, whereby the logic is typically limited to a minimum. Components can be used as elements in other components or pages. A component is given the data it is supposed to visualize. Furthermore, components can process events or return them to parent components for handling.
+Components are the basic building blocks of a user interface. Figure \ref{fig:component-example} shows an example of the representation of a tweet in Hybrid OSN using various components. A component consists of an HTML template, CSS styling, and JavaScript logic, whereby the logic is typically limited to a minimum. Components can be used as elements in other components or pages. A component receives the data it is supposed to visualize. Furthermore, components can process events or return them to parent components for handling.
 
 \begin{figure}[h!]
 	\centering
@@ -57,7 +57,7 @@ Components are the basic building blocks of a user interface. Figure \ref{fig:co
 
 \subsubsection{Pages}
 \label{pages}
-Pages are special components that are used as a holistic view. A page is made up of several other components. The data to be displayed is loaded using providers. To be able to navigate between the individual pages within the app, the model of a stack is used (implemented by the NavController). The currently visible page is at the top of the stack. When another page is called, it is pushed onto the stack. Pressing \enquote{Back} removes the top page from the stack and displays the page below it.
+Pages are specialized components that are used as a holistic view. A page is made up of several other components. The data to be displayed is loaded using providers. To be able to navigate between the individual pages within the app, the model of a stack is used (implemented by the NavController). The currently visible page is at the top of the stack. When another page is called, it is pushed onto the stack. Pressing \enquote{Back} removes the top page from the stack and displays the page below it.
 
 Table \ref{tab:pages} lists all pages and their purpose. When the app is opened, it checks whether the user is already logged in. Depending on this, the user starts with the Login Page or the Home Page.
 
@@ -77,10 +77,10 @@ Table \ref{tab:pages} lists all pages and their purpose. When the app is opened,
 		Settings                      & Configuration of keywords that trigger the private mode and settings regarding encryption                                                \\ \hline
 		Write-Tweet                   & Form for writing a tweet                                                                                                                 \\ \hline
 	\end{tabularx}
-	\caption{Pages used in the hybrid OSN app in alphabetical order with their purpose.}
+	\caption{Pages used in the Hybrid OSN app in alphabetical order with their purpose.}
 	\label{tab:pages}
 \end{table}
 
 \subsubsection{Local Storage}
 \label{sec:local-storage}
-As the name suggests, this is a local storage that the app has access to. With hybrid OSN, this memory is used to store the essential information for usage. These include the Twitter user id, the two tokens for accessing the Twitter API, the keywords that trigger the private mode, and private and public keys for encryption. Logout completely deletes the local storage.
+As the name suggests, this is a local storage that is accessible by the app. With Hybrid OSN, this memory is used to store essential information for usage. These include the Twitter user id, the two tokens for accessing the Twitter API, the keywords that trigger the private mode, and private and public keys for encryption. Log out completely deletes the local storage.

thesis/content/05-proof-of-concept/insights.tex

@@ -1,6 +1,6 @@
-The requirements mentioned in \ref{sec:requirements} also include the provision of anonymized data for the OSN service provider. Since the business model of Twitter is based on personal data and therefore the interests of hybrid OSN are contrary to those of Twitter, the fulfillment of this requirement is extremely complex.
+The requirements mentioned in \ref{sec:requirements} also include the provision of anonymized data for the OSN service provider. Since the business model of Twitter is based on personal data, and therefore the interests of hybrid OSN are contrary to those of Twitter, the fulfillment of this requirement is extremely complex.
 
-A prominent feature of Twitter is the analysis and promotion of trends (see Figure \ref{fig:twitter-trends}). The trends are identified by means of frequently used hashtags and presented in a ranking. Such data can also be collected and evaluated in the private network without having to establish a connection to the users.
+A prominent feature of Twitter is the analysis and promotion of trends (see Figure \ref{fig:twitter-trends}). The trends are identified through frequently used hashtags and presented in a ranking. Such data can also be collected and evaluated in the private network without having to establish a connection to the users.
 
 To collect this information, when a new tweet is posted to the private network, the contained hashtags are extracted and stored separately (see flowchart Figure \ref{fig:post-tweet-flow-chart}). Similar to the presentation of trends on Twitter, the trends in the private network are also aggregated on a daily basis and presented on a website (see Figure \ref{fig:hybrid-osn-trends}).
 
@@ -19,4 +19,4 @@ To collect this information, when a new tweet is posted to the private network,
 	\caption{Trending hashtags in Twitter and the private network side by side}
 \end{figure}
 
-Due to the fact that Gun is JavaScript-based and therefore executable in the web browser, access to the data from a simple HTML web page can be performed using JavaScript code. The raw data is loaded and then aggregated and displayed.
+Because Gun is JavaScript-based and therefore executable in the web browser, access to the data from a simple HTML web page can be performed using JavaScript code. The raw data is loaded and then aggregated and displayed.

thesis/content/05-proof-of-concept/introduction.tex

@@ -1 +1 @@
-After working out the concept of a hybrid OSN in the previous chapter \ref{ch:concept}, this chapter presents a proof of concept in the form of a special Twitter client for Android. The previously described solution strategies as well as functional and non-functional requirements actively influenced the development of the client, and attention was also paid to compliance with the defined quality goals. In the following, the decisions made are explained and the resulting architecture is presented.
+After working out the concept of a hybrid OSN in the previous chapter \ref{ch:concept}, this chapter presents a proof of concept in the form of an individual Twitter client for Android. The previously described solution strategies, as well as functional and non-functional requirements, actively influenced the development of the client, and attention was also paid to compliance with the defined quality goals. In the following, the decisions made are explained, and the resulting architecture is presented.

thesis/content/05-proof-of-concept/objective.tex

@@ -1,7 +1,7 @@
-With the proof of concept, the basic feasibility of the idea of an extension of an established OSN by a secure data exchange should be proven. Within the framework of this thesis, the task was to provide the proof of concept as a native Android app. With regard to the architecture, the focus from the beginning was on a peer 2 peer solution, which is why a solution with its own additional servers was not pursued further in the development of the prototype. Furthermore, an interface should be available for the service provider of the OSN, through which anonymized information can be obtained from the privately exchanged data.
+With the proof of concept, the basic feasibility of the idea of an extension of an established OSN by a secure data exchange should be proven. Within the framework of this thesis, the task was to provide the proof of concept as a native Android app. Concerning the architecture, the focus from the beginning was on a P2P solution, which is why a solution with its additional servers was not pursued further in the development of the prototype. Furthermore, an interface should be available for the service provider of the OSN, through which anonymized information can be obtained from the privately exchanged data.
 
-Even though the implementation by add-on, as shown in the previous chapter as a possible solution strategy, was thus fundamentally ruled out, the decisions were nevertheless based on considerations as to how users of such an extension could also be part of the P2P network.
+Even though the implementation as an add-on, as shown in the previous chapter as a possible solution strategy, was thus fundamentally ruled out, it nevertheless influenced the made decisions. It was always considered how the architecture could be this open and flexible to enable all kinds of extensions and clients.
 
-Since it is only a proof of concept, the mapping of the complete functionality of the OSN was not in the foreground. But, again, this was taken into account by considerations and decisions, how for example data formats can be arranged so flexibly that every functionality can be mapped.
+Since it is only a proof of concept, the mapping of the complete functionality of the OSN was not the highest priority. However, again, this was taken into account by considerations and decisions, how for example data formats can be arranged so flexible that every function can be mapped.
 
-In addition, the focus was on compliance with the quality objectives and implementation of the functional and non-functional requirements as defined in the previous chapter. How well this has been achieved will be evaluated in the following chapters for evaluation and subsequent discussion.
+Also, the focus was on compliance with the quality goals and implementation of the functional and non-functional requirements as defined in the previous chapter. How well this has been achieved will be evaluated in the following chapter for evaluation and discussion.

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

@@ -1,24 +1,24 @@
-When selecting a suitable OSN for the development of a hybrid client, Facebook was the obvious choice due to the numerous negative headlines about data protection. With over 2 billion users per month, it is currently the most widely used social network in the world. 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. 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. As a result of this scandal, the Facebook API was further restricted.
+When selecting a suitable OSN for the development of a hybrid client, Facebook was the obvious first choice due to the numerous negative headlines about data protection. With over two billion users per month, it is currently the most widely used social network in the world. 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. 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. As a result of this scandal, there were further restrictions to the Facebook API.
 
-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 post\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.
+However, the Facebook API is not suitable for developing a new client. 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 \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\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 as reported in various user ratings on the Google Play Store. The erroneous 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 users.
 
-For this number of reasons, Facebook dropped out as an 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}.
+For this number of reasons, Facebook dropped out as an OSN candidate for the prototype despite the particular 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}.
 
-In the end, Twitter was chosen for the prototype. With 336 million active users per month, it is one of the largest social networks. It is particularly well suited for the development of a hybrid client for two reasons: on the one hand, it has a detailed 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 a first proof of concept.
+In the end, Twitter was chosen for the prototype. With 336 million active users per month, it is one of the largest social networks. It is particularly well suited for the development of a hybrid client for two reasons: on the one hand, it has a comprehensive 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.
 
 Twitter offers different APIs for developers that serve different purposes. The current APIs are:
 \begin{itemize}
 	\item \textbf{Standard API}: the free and public API offering basic query functionality and foundational access to Twitter data.
-	\item \textbf{Premium API}: introduced in November 2017 to close the gap between Standard and Entrprise API. Improvements over the standard 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 API start at 149\$/month.
+	\item \textbf{Premium API}: introduced in November 2017 to close the gap between Standard and Entrprise API. Improvements over the Standard 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 API start at 149\$/month.
 	\item \textbf{Enterprise API}: tailored packages with annual contracts for those who depend on Twitter data.
 	\item \textbf{Ads API}: this 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 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 API is the right one. In order to use this API you first have to create a \enquote{Twitter App}. After registering you will get a consumer key and access token. These two authentication tokens are required to log in users via their own app and successfully execute requests to the API.
+In the case of the hybrid client, the standard API is the right one. For using the 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 API.
 
-Twitter offers almost the entire range of functions via the API. The lack of functionalities (e.g. the targeted retrieval of replies to a tweet) is not so critical. A major limitation is the restriction on the number of requests. This is to prevent Twitter being exposed 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 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.
 
-The API can be accessed using HTTP requests. The data exchanged are in 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 API.
+The API can be accessed using HTTP requests. The data exchanged are in 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 API.

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

@@ -1,4 +1,4 @@
-This section describes concrete 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.
+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.
 
@@ -21,20 +21,19 @@ On the write-tweet page, new tweets can be written and posted using a form. In a
 	\label{fig:post-tweet-building-block-view}
 \end{figure}
 
-After entering the message in the input field, determining the destination network, and pressing the \enquote{TWEET!} button, processing starts in the WriteTweetPage class. If the message is destined for Twitter, the Twitter API provider sends a HTTP POST request with the data to the \texttt{statuses/update}\footnote{https://developer.twitter.com/en/docs/tweets/post-and-engage/api-reference/post-statuses-update} interface. In this case, nothing more needs to be done, as the Twitter API takes over the preparation of the data and extracts, for example, hashtags, mentions and URLs.
+After entering the message in the input field, determining the destination network, and pressing the \enquote{TWEET!} button, processing starts in the WriteTweetPage class. If the message is destined for Twitter, the Twitter API provider sends an HTTP POST request with the data to the \texttt{statuses/update}\footnote{https://developer.twitter.com/en/docs/tweets/post-and-engage/api-reference/post-statuses-update} interface. In this case, nothing more needs to be done, as the Twitter API takes over the preparation of the data and extracts, for example, hashtags, mentions, and URLs.
 
-When publishing in the private network, the system first checks whether the public key has already been published. The Crypto provider performs this check using the Twitter API provider (for further information about the handling of public keys see the section about security \ref{sec:security}). If the public key has not yet been published, the user receives a warning and the posting process is aborted. Otherwise the private tweet will be constructed. The entered text is converted into a simplified tweet object (see Twitter documentation for original tweet object\footnote{https://developer.twitter.com/en/docs/tweets/data-dictionary/overview/tweet-object.html}) that contains the essential information.
+When publishing in the private network, the system first checks whether the public key has already been published. The Crypto provider performs this check using the Twitter API provider (for further information about the handling of public keys see the section about security \ref{sec:security}). If the public key has not yet been published, the user receives a warning, and the posting process is aborted. Otherwise, the private tweet will be constructed. The entered text is converted into a simplified tweet object (see Twitter documentation for original tweet object\footnote{https://developer.twitter.com/en/docs/tweets/data-dictionary/overview/tweet-object.html}) that contains the essential information.
 
-Beside the message (\texttt{full\_text}) the Twitter user id (\texttt{user\_id}) and the timestamp (\texttt{created\_at}) are set. In addition, there is a flag (\texttt{private\_tweet: true}) to distinguish the private tweet, which later influences the design. The \texttt{display\_text\_range} indicates the beginning and end of the relevant part in \texttt{full\_text}. For private tweets this is always the entire text, for tweets from the Twitter API an additional URL may be appended, which is not necessary due to clipping. Furthermore, the tweet entities are extracted. This includes URLs, hashtags and user mentions. An example of a private tweet is shown in Listing \ref{listing:private-tweet}.
+Beside the message (\texttt{full\_text}) the Twitter user id (\texttt{user\_id}) and the timestamp (\texttt{created\_at}) are set. In addition, there is a flag (\texttt{private\_tweet: true}) to distinguish the private tweet, which later influences the design. The \texttt{display\_text\_range} indicates the beginning and end of the relevant part in \texttt{full\_text}. For private tweets, this is always the entire text, for tweets from the Twitter API an additional, not needed URL may be appended, which is cut off by clipping. Furthermore, the tweet entities are extracted. The extraction includes URLs, hashtags and user mentions. An example of a private tweet is shown in Listing \ref{listing:private-tweet}.
 
 \lstinputlisting[label=listing:private-tweet, caption=Private Tweet in JSON format]{listings/private-tweet.json}
 
-The encryption of the private tweet data is performed by the crypto provider. The RSA algorithm is used for asymmetrical encryption. The encrypted data is transmitted via the P2P storage provider via POST request to Infura for storage in IPFS. The response contains the hash under which the data can be found in IPFS. This hash is stored in Gun together with the time stamp and the author's Twitter user id. This is done through the P2P DB provider. In addition, the previously extracted hashtags with the time stamp 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 draw conclusions about individual users.
+The crypto provider performs the encryption of the private tweet data. For asymmetrical encryption, the RSA algorithm is used. The P2P storage provider sends the encrypted data via an HTTP POST request to Infura for storage in IPFS. The response contains the hash which addresses the data in IPFS. This hash is stored in Gun together with the timestamp and the author's Twitter user id. For saving to Gun, the 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}
-
-When opening the home page, the logged in user gets the latest tweets of the accounts he follows chronologically presented. The tweets are loaded in batches of 20 tweets from the Twitter API and enriched with the private tweets for this time period. If the user scrolls to the end of the feed, the reloading of the next batch is triggered and automatically inserted at the end. A pull to refresh can be triggered at the top of the feed. The process is shown in Figure \ref{fig:home-timeline-flow-chart} as a flow chart and in Figure \ref{fig:home-timeline-building-block-view} as a building block view of the interacting components.
+When opening the home page, the logged in user gets the latest tweets of the accounts he follows chronologically presented. The tweets are loaded in batches of 20 tweets from the Twitter API and enriched with the private tweets for this period. If the user scrolls to the end of the feed, the reloading of the next batch is triggered and automatically inserted at the end. At the top of the feed, a \enquote{pull to refresh} action intents the feed reloading. The loading process is shown in Figure \ref{fig:home-timeline-flow-chart} as a flow chart and in Figure \ref{fig:home-timeline-building-block-view} as a building block view of the interacting components.
 
 \begin{figure}[h!]
 	\centering
@@ -50,10 +49,8 @@ When opening the home page, the logged in user gets the latest tweets of the acc
 	\label{fig:home-timeline-building-block-view}
 \end{figure}
 
-Starting point is the home page, which is accessed by the user. Using several components, the data obtained from the feed provider is displayed. Using the Twitter 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/api-reference/get-statuses-home\_timeline.html}) via a HTTP GET request.
-
-The next step is to load the private tweets that match the time 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 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 a HTTP GET request. The loaded user ids are cached in order to keep the number of requests to the Twitter API to a minimum for later loading processes. For each user id a lookup for private tweets in the given time span is performed. This is done by the P2P DB provider who queries Gun. If there are private tweets, the hashs for 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.
+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 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 HTTP GET request.
 
-Otherwise, the private tweets must be loaded and decrypted. First, the P2P Storage provider is used to load the data behind the hash addresses from IPFS via Infura. For this purpose, the hash is transferred to Infura with a HTTP GET request and the data is received from IPFS as response. To decrypt the data, the author's public key is required. The public key is stored in the user's public key history. This is loaded and decrypted via the Crypto provider, which in turn uses the Twitter API provider. The private tweet is then decrypted with the appropriate public key.
+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 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 HTTP GET request. The loaded user ids are cached in order to keep the number of requests to the Twitter API to a minimum for later loading processes. For each user id, a lookup for private tweets in the given period is performed. The P2P DB provider queries Gun. If there are private tweets, the hashes for 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 P2P storage provider is used to load the data behind the hash addresses from IPFS via Infura. For this purpose, the hash is transferred to Infura with an HTTP GET request, and the data is received from 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 API provider. Afterward, 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 pull to refresh, the previously described process starts again.
+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.

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

@@ -1,30 +1,29 @@
-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 can then only be decrypted by the owner of the private key. The private key cannot be determined 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 first exchange a symmetric key using asymmetric encryption. This 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 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.
 
-Tweets are usually posted publicly on Twitter. Only those who explicitly set their profile to "private" can decide who 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.
+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.
 
 The following three requirements apply to encryption:
 \begin{enumerate}
-	\item The author can be verified. It is not possible to distribute tweets on behalf of another user on the P2P network.
+	\item The author is verifiable. It is not possible to distribute tweets on behalf of another user on the P2P network.
 	\item A private tweet should have the same visibility to other users as a standard tweet on Twitter.
-	\item The service provider (Twitter) must not be able to decrypt private tweets or associate them with a user. 
+	\item The service provider (Twitter) must not be able to decrypt private tweets or associate them with a user.
 \end{enumerate}
 
 Concrete actions can be concluded to meet these requirements:
 \begin{enumerate}
-	\item Private tweets must be signed or asymmetrically encrypted so that the author can be clearly identified.
-	\item The public key with which the tweets can be decrypted must be distributed over the user's profile. This is the only way to ensure that only authorized users can access the key and that the public key belongs to a specific user without any doubt.
-	\item The hybrid OSN application must encrypt the public keys so that Twitter cannot read them and therefore cannot decrypt the private tweets.
+	\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 The Hybrid OSN application must encrypt the public keys so that Twitter cannot read them and therefore cannot decrypt the private tweets.
 \end{enumerate}
 
 \subsection{Realization}
 \label{sec:security-relaization}
-
-In the settings, an (asymmetric) key pair can be stored or generated, which is used to encrypt the private tweets. The RSA-OAEP algorithm is used here. Furthermore, the public key can be published on the settings page by clicking on a particular button. The new key together with the current timestamp is recorded in the public key history of the user and stored in IPFS. Listing \ref{listing:public-key-history} shows an example for the public key history. In JSON format, public key and validity start are stored in an array. The address at which the public key history can be retrieved is posted as a normal tweet in the user's timeline during publication. So that this tweet can be found quickly and easily, the id of this tweet is entered in the profile description of the user.
+In the app settings, an asymmetric key pair can be stored or generated, which is used to encrypt the private tweets. The RSA-OAEP algorithm is used here. Furthermore, by clicking on a particular button, the public key is published. The new key together with the current timestamp is recorded in the public key history of the user and stored in IPFS. Listing \ref{listing:public-key-history} shows an example for the public key history. In JSON format, public key and validity start are stored in an array. The address at which the public key history can be retrieved is posted as a regular tweet in the user's timeline during publication. So that this tweet can be found quickly and easily; the id of this tweet is saved in the profile description of the user.
 
 \lstinputlisting[label=listing:public-key-history, caption=Public key history in JSON format. The file is symmetrically encrypted before storing on IPFS.]{listings/key-history.json}
 
-This ensures that only users who can read the user's normal tweets have access to the user's public keys. The history allows you to change the key pair and still ensure that older private tweets can be decrypted.
+By saving this information on the user's profile, it is ensured that only users who can read the user's regular tweets have access to the user's public keys and hence to his private tweets. The history allows the changing of the key pair and still ensure that older private tweets are still decryptable.
 
-Since Twitter has access to all the data stored on its servers, it can also find the link to the public key history. It must therefore be prevented that Twitter can decrypt the private tweets of the user by retrieving the public key history. For this reason, the public key history is additionally encrypted symmetrically with the AES-GCM algorithm. The key is stored in the hybrid OSN app and therefore unknown to Twitter.
+Since Twitter has access to all the data stored on its servers, it can also find the link to the public key history. Therefore, it is necessary to prevent Twitter from decrypting the private tweets of the user by retrieving the public key history. For this reason, the public key history is additionally encrypted symmetrically with the AES-GCM algorithm. The key is stored in the Hybrid OSN app and therefore unknown to Twitter.
 
-When writing a new, private tweet, the system checks whether the public key has been published before posting. Only if this is fulfilled will the private tweet be encrypted with the private key and posted.
+When writing a new, private tweet, the system checks whether the public key has been published before posting. Only if this is fulfilled, the private tweet will be encrypted with the private key and posted.