swap out the word development

thesis/content/04-concept/introduction.tex

@@ -7,4 +7,4 @@ Although the problems and dangers are known for a long time and new scandals reg
 
 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 \ac{OSN} will be developed that takes 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.
+In the following, a concept for a hybrid \ac{OSN} will be worked out that takes 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.

thesis/content/04-concept/restrictions.tex

@@ -3,10 +3,10 @@ When designing the hybrid \ac{OSN}, there are a few limitations that need to be
 \begin{itemize}
 	\item \textbf{\ac{API} of the \ac{OSN}}: Ideally the \ac{OSN} offers a public \ac{API} with full functionality. An API consists of multiple endpoints that can be used to retrieve, add, or modify specific data. Since the user's data should be protected as best as possible, access via the \ac{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 \ac{OSN} web pages}: If there is no official \ac{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 \ac{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 \ac{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 \acp{OSN} can be used on almost all devices; independent of their operating system. In order to achieve the same user experience, the hybrid \ac{OSN} should be usable on the same variety of operating systems. Any restrictions imposed by the operating system (user and application rights, connectivity) must be taken into account during development.
+	\item \textbf{Creation, operation and licensing costs}: Costs for the creation, 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 \acp{OSN} can be used on almost all devices; independent of their operating system. In order to achieve the same user experience, the hybrid \ac{OSN} should be usable on the same variety of operating systems. Any restrictions imposed by the operating system (user and application rights, connectivity) must be taken into account during creation.
 	\item \textbf{Resources}: The mostly mobile devices (Twittter is used by more than 80\% of users on mobile \cite{google2017twitter-mobile}) running the hybrid \ac{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 \ac{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}
 
-While the restrictions on the hybrid client itself can be actively influenced and resolved, the restrictions on the \ac{OSN} cannot be controlled. If the \ac{OSN} does not provide any interfaces and the hurdle of data exchange with the servers is insurmountable, this can completely prevent the development of a hybrid client.
+While the restrictions on the hybrid client itself can be actively influenced and resolved, the restrictions on the \ac{OSN} cannot be controlled. If the \ac{OSN} does not provide any interfaces and the hurdle of data exchange with the servers is insurmountable, this can completely prevent the creation of a hybrid client.

thesis/content/04-concept/stakeholders.tex

@@ -77,7 +77,7 @@ Even if the stakeholders are not necessarily directly involved in the developmen
 %Influence on hybrid OSN
 \newcommand{\influenceSP}{\begin{minipage} [t] {0.4\textwidth} 
 		\begin{itemize}
-			\item No direct influence on the development of the hybrid solution
+			\item No direct influence on the hybrid solution
 			\item By identification of the hybrid OSN users their exclusion
 			\item Blocking the hybrid OSN
 			\item Great influence			

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

@@ -11,7 +11,7 @@ Figure \ref{fig:building-block-view} shows a black box view of which other syste
 	\item User 
 \end{itemize}
 
-Infura\footnote{https://infura.io/} is a service that provides access to Ethereum and \ac{IPFS} via a simple interface. Communication with the \ac{API} happens using \ac{HTTP} requests. The connection of \ac{IPFS} in Hybrid \ac{OSN} can thus be carried out in a simple way. The use of an additional system entails an extra risk typically. However, there is a JavaScript client for \ac{IPFS}, which can be integrated into Hybrid \ac{OSN} and thus the dependency on Infura would be omitted. For the development of the prototype, the decision was made to use Infura for reasons of simplicity. Infura can be used for \ac{IPFS} free of charge and without registration.
+Infura\footnote{https://infura.io/} is a service that provides access to Ethereum and \ac{IPFS} via a simple interface. Communication with the \ac{API} happens using \ac{HTTP} requests. The connection of \ac{IPFS} in Hybrid \ac{OSN} can thus be carried out in a simple way. The use of an additional system entails an extra risk typically. However, there is a JavaScript client for \ac{IPFS}, which can be integrated into Hybrid \ac{OSN} and thus the dependency on Infura would be omitted. For the creation of the prototype, the decision was made to use Infura for reasons of simplicity. Infura can be used for \ac{IPFS} free of charge and without registration.
 
 \begin{figure}[h!]
 	\centering

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

@@ -1,4 +1,4 @@
-With the proof of concept, the basic feasibility of the idea of an extension of an established \ac{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 \ac{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 \ac{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 \ac{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 \ac{P2P} solution, which is why a solution with its additional servers was not pursued further in the creation of the prototype. Furthermore, an interface should be available for the service provider of the \ac{OSN}, through which anonymized information can be obtained from the privately exchanged data.
 
 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.
 

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

@@ -1,4 +1,4 @@
-To select a suitable \ac{OSN} for the development of a hybrid client, three factors were considered:
+To select a suitable \ac{OSN} for the creation of a hybrid client, three factors were considered:
 
 \begin{enumerate}
 	\item the significance of the \ac{OSN},
@@ -8,13 +8,13 @@ To select a suitable \ac{OSN} for the development of a hybrid client, three fact
 
 Facebook was the obvious first choice due to the numerous negative headlines about data protection. With over 2.3 billion users per month (average Q4 2018), it is currently the most widely used social network in the world \cite{facebook2019reportq4}. In the recent past, it has often been criticized for its handling of its users' data. In particular, the scandal surrounding the data analysis company Cambridge Analytica, which had access to the data of up to 87 million users, hit Facebook hard \cite{facebook2018cambridge-analytica,facebook2018api-restriction}. As a result, CEO Mark Zuckerberg had to face the US Congress and the EU Parliament in question rounds and did not leave a good impression by avoiding many questions \cite{facebook2018us-congress,facebook2018eu-parliament}. As a result of this scandal, there were further restrictions to the Facebook \ac{API} \cite{facebook2018api-restriction}.
 
-However, the Facebook \ac{API} is not suitable for developing a new client. The functionalities provided by the \ac{API} offer the possibility to develop an app that can be used within Facebook, for example for a game. So, it is not possible to give a \enquote{Like} for a post through this \ac{API}, which is part of the core functionality of a Facebook client. As discussed in Chapter \ref{ch:concept}, it is possible to access the data through crawling. However, the constant and rapid development would make this an arduous undertaking. Facebook writes in a blog post that the code changes every few hours \cite{facebook2017release}. Therefore it is almost impossible to adjust the crawler fast enough and roll out the updated code.
+However, the Facebook \ac{API} is not suitable for creating a new client. The functionalities provided by the \ac{API} offer the possibility to build an app that can be used within Facebook, for example for a game. So, it is not possible to give a \enquote{Like} for a post through this \ac{API}, which is part of the core functionality of a Facebook client. As discussed in Chapter \ref{ch:concept}, it is possible to access the data through crawling. However, the rapid changes to the page structure would make this an arduous undertaking. Facebook writes in a blog post that the code changes every few hours \cite{facebook2017release}. Therefore it is almost impossible to adjust the crawler fast enough and roll out the updated code.
 
 Even the mixed version of displaying and manipulating the mobile website in a WebView in a container app does not seem to be an option due to the short release cycles and frequent changes. Apps like \enquote{Friendly for Facebook} do not manage to keep up with the changes as reported in various user ratings on the Google Play Store. The false representations and bugs worsen the user experience and result in the frustration of the users.
 
 For this number of reasons, Facebook dropped out as an \ac{OSN} candidate for the prototype despite the particular interest. As a further candidate, the \ac{OSN} Google Plus was dropped, as Google announced in October 2018 that it would discontinue its \ac{OSN} \cite{google-plus2018shutdown}.
 
-Finally, Twitter was chosen for the prototype. With 321 million active users per month (average Q4 2018), it is one of the largest social networks \cite{twitter2019reportq4}. It is particularly well suited for the development of a hybrid client for two reasons: first, it has a comprehensive \ac{API} that provides almost full functionality free of charge, and second, compared to Facebook, it offers only a few simple functions. These are the ideal prerequisites for the first proof of concept.
+Finally, Twitter was chosen for the prototype. With 321 million active users per month (average Q4 2018), it is one of the largest social networks \cite{twitter2019reportq4}. It is particularly well suited for the creation of a hybrid client for two reasons: first, it has a comprehensive \ac{API} that provides almost full functionality free of charge, and second, compared to Facebook, it offers only a few simple functions. These are the ideal prerequisites for the first proof of concept.
 
 Twitter offers several \acp{API} for developers that serve different purposes. The current \acp{API} are \cite{twitterXXXXdev-getting-started}:
 \begin{itemize}
@@ -29,4 +29,4 @@ In the case of the hybrid client, the standard \ac{API} can be used. In this pro
 
 Twitter offers almost the entire range of functions via the \ac{API}. The missing functionality (e.g., the targeted retrieval of replies to a tweet) is not so critical for building a client app. A significant limitation is a restriction on the number of requests. Twitter argues that this restriction is necessary to avoid the exposure of the system to too much load. It also aims to prevent bots from abusing Twitter. The exact limits can be found on a help page\footnote{https://developer.twitter.com/en/docs/basics/rate-limits}. In the app stores of Google and Apple, there are a number of alternative Twitter clients (Twitterific\footnote{https://itunes.apple.com/de/app/twitterrific-5-for-twitter/id580311103?mt=8}, Talon for Twitter\footnote{https://play.google.com/store/apps/details?id=com.klinker.android.twitter\_l}, Fenix 2 for Twitter\footnote{https://play.google.com/store/apps/details?id=it.mvilla.android.fenix2}), which are also subject to these restrictions in terms of functionality and requests. Their success indicates that the restrictions do not affect the common usage seriously.
 
-The \ac{API} can be accessed using \ac{HTTP} requests. The data exchanged are in \ac{JSON} format. Furthermore, there are also various libraries (e.g., Twit\footnote{https://github.com/ttezel/twit}), some even are developed directly by Twitter (see Twitter Kit for Android\footnote{https://github.com/twitter/twitter-kit-android} or iOS\footnote{https://github.com/twitter/twitter-kit-ios}) and simplify the use of the \ac{API}.
+The \ac{API} can be accessed using \ac{HTTP} requests. The data exchanged are in \ac{JSON} format. Furthermore, there are also various libraries (e.g., Twit\footnote{https://github.com/ttezel/twit}), some even are offered directly by Twitter (see Twitter Kit for Android\footnote{https://github.com/twitter/twitter-kit-android} or iOS\footnote{https://github.com/twitter/twitter-kit-ios}) and simplify the use of the \ac{API}.

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

@@ -32,7 +32,7 @@ Hive2Hive\footnote{https://github.com/Hive2Hive/Hive2Hive} is a Java library for
 
 \subsubsection{GUN}
 \label{sec:gun}
-In 2014, Mark Nadal began developing a decentralized database called GUN. GUN\footnote{https://gun.eco} is written in JavaScript and will be further developed by the community as an open source\footnote{https://github.com/amark/gun} project. It is licensed under the Apache License 2.0, so free use is allowed. The \ac{P2P} database exists only within a browser and synchronizes itself with other peers over the Internet. It has offline support, so changes are automatically synchronized and merged as soon as a connection is established. The data is stored in a graph structure in the local storage of the browser. For connecting peers among each other, at least one relay server is required.
+In 2014, Mark Nadal began working on a decentralized database called GUN. GUN\footnote{https://gun.eco} is written in JavaScript and will be further developed by the community as an open source\footnote{https://github.com/amark/gun} project. It is licensed under the Apache License 2.0, so free use is allowed. The \ac{P2P} database exists only within a browser and synchronizes itself with other peers over the Internet. It has offline support, so changes are automatically synchronized and merged as soon as a connection is established. The data is stored in a graph structure in the local storage of the browser. For connecting peers among each other, at least one relay server is required.
 
 \subsubsection{OrbitDB}
 \label{sec:orbitdb}
@@ -59,7 +59,7 @@ A solution based on a blockchain increases complexity for the user. Since the hy
 
 The goal of \ac{IPFS} is to connect all computing devices to the same file system. The basis for this is a \ac{P2P} network where the data is distributed and stored. Instead of a location-oriented approach as used in \ac{HTTP}, \ac{IPFS} uses a content-oriented protocol. A cryptographic hash function generates a hash (content identifier) for each file, which can be used to find the file on the \ac{P2P} network using a \ac{DHT}. Unnecessary redundancies are avoided in this way, as the content is only stored once and purposefully replicated. However, deleting data is impossible in IPFS. Only if all peers who have stored copies of the file leave, the file can no longer be recovered. Decentralization allows a file to be retrieved from several peers in parallel, thus making the download faster. Besides,
 
-Due to its characteristics, \ac{IPFS} is an ideal complement to the blockchain and the development of \acp{dApp}. Large amounts of data can be stored out of \ac{IPFS}, and the address hash can be written into the blockchain. This principle is used for example by AKASHA and Peepeth.
+Due to its characteristics, \ac{IPFS} is an ideal complement to the blockchain and the creation of \acp{dApp}. Large amounts of data can be stored out of \ac{IPFS}, and the address hash can be written into the blockchain. This principle is used for example by AKASHA and Peepeth.
 
 \ac{IPFS} clients are available for Max OS X, Linux and Windows. Besides, there are client implementations in JavaScript and Go to include in other applications.