fix data = plural

thesis/content/02-background/dapps.tex

@@ -12,7 +12,7 @@ Johnston et al. and Siraj Raval name the following four criteria for a \ac{dApp}
 
 \begin{itemize}
 	\item \textbf{Open Source}: Trust and transparency are created by the disclosure of the source code. This also enables improvement through contributions from other developers.
-	\item \textbf{Blockchain based}: The data of the application is stored cryptographically in a public, decentralized blockchain. The immutability of the blockchain can be used in conjunction with smart contracts to build consensus and trust.
+	\item \textbf{Blockchain based}: The data of the application are stored cryptographically in a public, decentralized blockchain. The immutability of the blockchain can be used in conjunction with smart contracts to build consensus and trust.
 	\item \textbf{Cryptographic token}: Certain actions in the network can only be performed by paying with a token. This token can either be purchased or given to the user in exchange for data, storage space or similar. Especially as a reward for positive actions, users should be rewarded with tokens. However, no entity should have control over the majority of the tokens.
 	\item \textbf{Token generation}: The application must generate tokens according to a standard cryptographic algorithm (e.g., Proof of Work and Proof of Stake Algorithm) or distribute them among the users at the beginning of its operation.
 \end{itemize}
@@ -27,7 +27,7 @@ In addition to the criteria of a \ac{dApp}, Johnston et al. also describe a clas
 
 Over 1900 dApps use the Ethereum platform \cite{dappsXXXXstats} and in terms of market capitalization, 94 of the top 100 tokens base on Ethereum \cite{dappsXXXXtokens}. Ethereum is a public, decentralized blockchain and at the same time a system for the execution of smart contracts. The associated token is called \ac{ETH} and is required to execute the smart contracts on the \ac{EVM}.
 
-Since the storage of large amounts of data in the blockchain is expensive, the data is often stored elsewhere, and only one reference is written into the blockchain. \ac{IPFS} has become the preferred decentralized storage location.
+Since the storage of large amounts of data in the blockchain is expensive, the data are often stored elsewhere, and only one reference is written into the blockchain. \ac{IPFS} has become the preferred decentralized storage location.
 
 Examples of \acp{dApp} that use the Ethereum - \ac{IPFS} combination are the social networks Peepeth and AKASHA, which are introduced in the following chapter.
 

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

@@ -21,11 +21,11 @@ The biggest disadvantage with this architecture is that failure or the blockade
 
 \subsection{Decentralized Applications}
 \label{sec:decentralized-applications}
-What are the advantages and disadvantages of centralized applications, is largely reversed in decentralized systems. Unlike centralized applications, decentralized applications do not have a single point of failure. But there is no node in the system that has all the data which makes accessing information sometimes hard. There are any number of nodes that perform the tasks of a server and by exchanging with other servers in total form a complete system.
+What are the advantages and disadvantages of centralized applications, is mostly reversed in decentralized systems. Unlike centralized applications, decentralized applications do not have a single point of failure. However, there is no node in the system that has all the data which makes accessing information sometimes hard. There is any number of nodes that perform the tasks of a server and by exchanging with other servers in total form a complete system.
 
 Another advantage is that each server only handles the number of users covered by its resources. New servers contribute additional resources to the overall system. Distributed applications cannot be disabled easily because a new server can be started at any time that does not fall under a lock. Because the data are not centrally available, they cannot be processed, so that user data are better protected. Also, there is no longer a prominent attack target. So, hacking a single server loses lucrativeness.
 
-The drawbacks include the difficulty of finding data because they are spread across multiple servers. Search functionalities are thus difficult to implement. If a server is taken offline, the data is no longer available, even if the system itself remains functional. Since there is no longer a central point that is managed by an operator, rolling out updates is difficult. This raises the challenge that server nodes of different versions of the same application can still work together.
+The drawbacks include the difficulty of finding data because they are spread across multiple servers. Search functionalities are thus difficult to implement. If a server is taken offline, the data are no longer available, even if the system itself remains functional. Since there is no longer a central point that is managed by an operator, rolling out updates is difficult. This raises the challenge that server nodes of different versions of the same application can still work together.
 
 Examples of decentralized applications are the social networks diaspora* and Mastodon. In these networks, each user can operate a server on his own. Unlike Facebook, the decision on the existence of the service is therefore not in the control of the operator, but the user. Bitcoin is also a decentralized application architecture. In doing so, transactions are carried out in a decentralized database (blockchain).
 

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

@@ -20,7 +20,7 @@ After validating several available solutions for personal data protection, the r
 	\label{fig:facecloak-architecture}
 \end{figure}
 
-During the setup phase, the browser extension is installed, and the encryption keys are generated. Afterwards, the keys for decryption are shared with the trusted contacts. In phase two, when data worthy of protection is stored, it is transmitted in encrypted form to a third party server and stored there. Only fake data is transmitted to the social network server. In phase three, whenever an authorized contact calls up a profile page and fake data is transmitted by the social network, the extension takes care of the replacement with the real data.
+During the setup phase, the browser extension is installed, and the encryption keys are generated. Afterwards, the keys for decryption are shared with the trusted contacts. In phase two, when data worthy of protection is stored, it is transmitted in encrypted form to a third party server and stored there. Only fake data are transmitted to the social network server. In phase three, whenever an authorized contact calls up a profile page and fake data are transmitted by the social network, the extension takes care of the replacement with the real data.
 
 In addition to adhering to the above design principles, the proposed architecture makes the following contributions:
 
@@ -35,12 +35,12 @@ To protect the privacy of Facebook users, Luo, Xiu, and Hengartner have created
 
 The extension uses \ac{AES} and a key length of 128 bits to encrypt the data. The indices for the encrypted data are calculated using SHA-1. The authors propose an e-mail for the key exchange. For this purpose, the browser extension automatically generates e-mail texts and recipient lists and forwards them to the standard e-mail program. The recipients then have to store the received keys in the extension manually.
 
-In order to protect data with FaceCloak, the prefix @@ must be added to the information in a text field. For other form elements such as dropdowns, radio buttons or checkboxes, the extension creates additional options that also start with @@. When submitting the form, the extension intervenes and replaces the data marked with @@ with fake data. The data to be protected is encrypted with the stored keys and transferred as a key-value pair to the third party server where it is stored. FaceCloak can protect all profile information, but only for name, birthday, and gender algorithms for the meaningful creation of fake data are implemented.
+In order to protect data with FaceCloak, the prefix @@ must be added to the information in a text field. For other form elements such as dropdowns, radio buttons or checkboxes, the extension creates additional options that also start with @@. When submitting the form, the extension intervenes and replaces the data marked with @@ with fake data. The data to be protected are encrypted with the stored keys and transferred as a key-value pair to the third party server where it is stored. FaceCloak can protect all profile information, but only for name, birthday, and gender algorithms for the meaningful creation of fake data are implemented.
 
 In addition to profile information, the extension can also protect Facebook Wall and Facebook Notes data. The contents of arbitrary Wikipedia articles are transmitted as fake data to avoid attracting attention with random and unusual character strings.
 
-When loading a profile page that contains protected data, the extension with asynchronous \ac{HTTP} requests retrieves the information from the third party server, decrypts it, and replaces the fake data. A large part of the replacement can thus be performed during the load process so that the user does not see the fake data. However, since Facebook also loads content asynchronously, some replacements can only be performed with a time delay and the fake data is shortly visible.
+When loading a profile page that contains protected data, the extension with asynchronous \ac{HTTP} requests retrieves the information from the third party server, decrypts it, and replaces the fake data. A large part of the replacement can thus be performed during the load process so that the user does not see the fake data. However, since Facebook also loads content asynchronously, some replacements can only be performed with a time delay and the fake data are shortly visible.
 
-The keys have to be transferred to all devices and stored in the extension to use the same account. It is not possible to use multiple accounts with the same Firefox profile, as all data is stored in the extension and these are always bound to exactly one Facebook account.
+The keys have to be transferred to all devices and stored in the extension to use the same account. It is not possible to use multiple accounts with the same Firefox profile, as all data are stored in the extension and these are always bound to exactly one Facebook account.
 
 The latest version 0.6 from August 2010 cannot be installed in the current Firefox (version 65). Furthermore, it is unknown if the server is still running. Therefore it is not possible to check if the extension still works. Due to the numerous updates and sometimes severe changes that Facebook has experienced in the last eight years, it is doubtful  that the extension will still function today. At that time, however, it was successfully applied and proved that the proposed architecture worked.

thesis/content/04-concept/introduction.tex

@@ -1,5 +1,5 @@
-The reason for the inadequate protection of personal data lies in the centralized system structure used by all leading social platforms (e.g., Facebook and Twitter). With this structure, the data is stored centrally and mostly unencrypted. The service provider therefore inevitably has access to this data. It is not transparent to users, which data the service provider record during the use and what happens to the data.
-On the one hand, the user data is evaluated to improve the user experience (suggestions for content matching the user’s preferences using recommender systems), but on the other hand also to make a profit. With personalized advertisement and, in the worst case, by selling the data, revenues are generated. Furthermore, the protection of data against access by third parties via official interfaces (harvesting) or unauthorized hacking cannot be ruled out (e.g., Facebook's incident with Cambridge Analytica in March 2018 \cite{facebook2018cambridge-analytica}). Last but not least, due to applicable law, it may be necessary for data to be transferred to secret services or government agencies (e.g., Facebook had more than 100\,000 requests from governments between January and July 2018 \cite{facebookXXXXtake-down}).
+The reason for the inadequate protection of personal data lies in the centralized system structure used by all leading social platforms (e.g., Facebook and Twitter). With this structure, the data are stored centrally and mostly unencrypted. The service provider therefore inevitably has access to this data. It is not transparent to users, which data the service provider record during the use and what happens to the data.
+On the one hand, the user data are evaluated to improve the user experience (suggestions for content matching the user’s preferences using recommender systems), but on the other hand also to make a profit. With personalized advertisement and, in the worst case, by selling the data, revenues are generated. Furthermore, the protection of data against access by third parties via official interfaces (harvesting) or unauthorized hacking cannot be ruled out (e.g., Facebook's incident with Cambridge Analytica in March 2018 \cite{facebook2018cambridge-analytica}). Last but not least, due to applicable law, it may be necessary for data to be transferred to secret services or government agencies (e.g., Facebook had more than 100\,000 requests from governments between January and July 2018 \cite{facebookXXXXtake-down}).
 
 The criticism of the protection of privacy on the Internet, especially in social networks, is not new. Already in 2010, the founders of diaspora* discovered that no social network sufficiently protects the privacy of users\cite{diaspora2010kickstarter-pitch}. Although the problems and dangers of centralized \acp{OSN} are known for a long time and new scandals regularly become known to the public, the users remain mostly loyal to the respective social networks. As a result of the Cambridge Analytica incident, Facebook lost only a few users in Europe but is in the meantime back on the previous level \cite{facebook2019reportq4}. Alternative social networks, which focus on privacy protection (e.g., Vero\footnote{https://www.vero.co}, Ello\footnote{https://ello.co}), lack attractiveness regarding their design, complexity, and functionality. As a consequence, they do not get enough users and often fail after a short time. The connection to the respective social network is so strong that the barrier for switching to another, more secure social network is not overcome. The amount of content already created, the social network built up, and a large number of contacts using the same platform all create this so-called lock-in effect.
 

thesis/content/04-concept/requirements.tex

@@ -4,7 +4,7 @@ The solution should meet specific functional and non-functional requirements so
 \begin{itemize}
 	\item \textbf{Standard functionality}: With the hybrid solution, all standard functionalities of the \ac{OSN} should be unrestrictedly usable. Otherwise, the user would be forced to continue using the original client. The parallel use of two clients for the same \ac{OSN} is not user-friendly and would be an argument against the use of the restricted hybrid client.
 	\item \textbf{Client-side solution}: Since there is no control over the \ac{OSN}'s servers and software, changes can only be implemented on the client side. The alternative Facebook client app \enquote{Friendly for Facebook} for example changes the design on the client side and removes advertisements.
-	\item \textbf{Data sovereignty}: The user can actively decide whether his data is stored on the \ac{OSN}'s servers or exchanged with other users via a private, secure channel. This implies that any functionality and the associated data exchange can also be carried out in a private, secure way. The user thus gains sovereignty over his data and can decide for himself whether to entrust it to the \ac{OSN}.
+	\item \textbf{Data sovereignty}: The user can actively decide whether his data are stored on the \ac{OSN}'s servers or exchanged with other users via a private, secure channel. This implies that any functionality and the associated data exchange can also be carried out in a private, secure way. The user thus gains sovereignty over his data and can decide for himself whether to entrust it to the \ac{OSN}.
 	\item \textbf{Authorized data access}: Especially the service provider of the \ac{OSN} should not have access to the private data of a user and should under no circumstances be able to relate them to him. As in the \ac{OSN}, the author himself should be able to determine with which users he shares his private data and grants them access.
 	\item \textbf{Encryption}: Private data are a sensitive commodity and should, therefore, be protected in the best possible way. In particular, encrypted transmission and encrypted data storage are necessary to protect it from unauthorized access by third parties. It should be ensured that the encryption guarantees sufficient protection and is difficult for attackers to crack.
 	\item \textbf{Flexible data format}: The future development of the \ac{OSN} is not foreseeable, and it is not able to take an influence on it. The data format for information exchange in the private network must therefore be able to react flexibly to possible changes. If, for example, dislikes can be assigned in addition to likes in the future or a new post type for videos is added, it should be possible to implement this quickly in the data structure of the hybrid solution.

thesis/content/04-concept/restrictions.tex

@@ -6,7 +6,7 @@ When designing the hybrid \ac{OSN}, there are some limitations that need to be c
 	\item \textbf{Creation, operation and licensing costs}: Costs for the creation, operation and licensing of third-party software may be 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 are, should have no effect its availability.
+	\item \textbf{Availability of data}: The data that are exchanged securely and not via the \ac{OSN}'s servers must always be available. Whether a user is offline or how old the data are, should have no effect 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 creation of a hybrid client.

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

@@ -1,4 +1,4 @@
-Various models can be used to implement a secure data exchange between the users of an \ac{OSN} via additional network. The solution strategies shown below differ primarily 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 \ac{OSN} via additional network. The solution strategies shown below differ primarily in the question of where data are stored and how it can be found.
 
 \begin{figure}[h!]
 	\centering

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

@@ -57,7 +57,7 @@ Components are the basic building blocks of a user interface. Figure \ref{fig:co
 
 \subsubsection{Pages}
 \label{pages}
-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.
+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 are 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.
 

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

@@ -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}
 
-Because GUN is JavaScript-based and therefore executable in the web browser, access to the data from a simple \ac{HTML} web page can be performed using JavaScript code. The raw data is loaded, aggregated and displayed.
+Because GUN is JavaScript-based and therefore executable in the web browser, access to the data from a simple \ac{HTML} web page can be performed using JavaScript code. The raw data are loaded, aggregated and displayed.

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

@@ -29,7 +29,7 @@ Beside the message (\texttt{full\_text}) the Twitter user id (\texttt{user\_id})
 
 \lstinputlisting[label=listing:private-tweet, caption=Private Tweet in \ac{JSON} format]{listings/private-tweet.json}
 
-The crypto provider performs the encryption of the private tweet data. For asymmetrical encryption, the RSA algorithm is used. The \ac{P2P} storage provider sends the encrypted data via an \ac{HTTP} POST request to Infura for storage in \ac{IPFS}. The response contains the hash which addresses the data in \ac{IPFS}. This hash is stored in GUN together with the timestamp and the author's Twitter user id. For saving to GUN, the \ac{P2P} DB provider is used. Besides, the previously extracted hashtags with the timestamp are also stored in GUN with the same provider so that the data in the dashboard is accessible to the service provider without having to conclude individual users.
+The crypto provider performs the encryption of the private tweet data. For asymmetrical encryption, the RSA algorithm is used. The \ac{P2P} storage provider sends the encrypted data via an \ac{HTTP} POST request to Infura for storage in \ac{IPFS}. The response contains the hash which addresses the data in \ac{IPFS}. This hash is stored in GUN together with the timestamp and the author's Twitter user id. For saving to GUN, the \ac{P2P} DB provider is used. Besides, the previously extracted hashtags with the timestamp are also stored in GUN with the same provider so that the data in the dashboard are accessible to the service provider without having to conclude individual users.
 
 \subsection{Load the Home Timeline}
 \label{sec:load-home-timeline}
@@ -51,6 +51,6 @@ When opening the home page, the logged in user gets the latest tweets of the acc
 
 The starting point is the home page, which is accessed by the user. Several components display the data obtained from the feed provider. Using the Twitter \ac{API} provider, the feed provider loads the latest 20 timeline tweets via the corresponding interface (\texttt{statuses/home\_timeline}\footnote{https://developer.twitter.com/en/docs/tweets/timelines/yapi-reference/get-statuses-home\_timeline.html}) via an \ac{HTTP} GET request.
 
-The next step is to load the private tweets that match the period marked by the current timestamp and timestamp of the 20th (the oldest) tweet. Furthermore, the ids of the accounts the user follows (so-called friends) are required. These must initially be requested from the Twitter \ac{API} (\texttt{friends/list}\footnote{https://developer.twitter.com/en/docs/accounts-and-users/follow-search-get-users/api-reference/get-friends-list}) via the Twitter Feed provider using an \ac{HTTP} GET request. The loaded user ids are cached in order to keep the number of requests to the Twitter \ac{API} to a minimum for later loading processes. For each user id, a lookup for private tweets in the given period is performed. The \ac{P2P} \ac{DB} provider queries GUN. If there are private tweets, the hashes for \ac{IPFS} are returned together with the \texttt{created\_at} timestamp. If no private tweets are available for the period, the feed provider returns the data of the public tweets to the home page. Otherwise, the private tweets are loaded and decrypted. First, the \ac{P2P} storage provider is used to load the data behind the hash addresses from \ac{IPFS} via Infura. For this purpose, the hash is transferred to Infura with an \ac{HTTP} GET request, and the data is received from \ac{IPFS} as the response. The author's public key, which can be obtained from the user's public key history, is needed for decryption. The public key history is loaded and decrypted via the crypto provider, which in turn uses the Twitter \ac{API} provider. Afterwards, the private tweet is decrypted.
+The next step is to load the private tweets that match the period marked by the current timestamp and timestamp of the 20th (the oldest) tweet. Furthermore, the ids of the accounts the user follows (so-called friends) are required. These must initially be requested from the Twitter \ac{API} (\texttt{friends/list}\footnote{https://developer.twitter.com/en/docs/accounts-and-users/follow-search-get-users/api-reference/get-friends-list}) via the Twitter Feed provider using an \ac{HTTP} GET request. The loaded user ids are cached in order to keep the number of requests to the Twitter \ac{API} to a minimum for later loading processes. For each user id, a lookup for private tweets in the given period is performed. The \ac{P2P} \ac{DB} provider queries GUN. If there are private tweets, the hashes for \ac{IPFS} are returned together with the \texttt{created\_at} timestamp. If no private tweets are available for the period, the feed provider returns the data of the public tweets to the home page. Otherwise, the private tweets are loaded and decrypted. First, the \ac{P2P} storage provider is used to load the data behind the hash addresses from \ac{IPFS} via Infura. For this purpose, the hash is transferred to Infura with an \ac{HTTP} GET request, and the data are received from \ac{IPFS} as the response. The author's public key, which can be obtained from the user's public key history, is needed for decryption. The public key history is loaded and decrypted via the crypto provider, which in turn uses the Twitter \ac{API} provider. Afterwards, the private tweet is decrypted.
 
-Finally, the private and public tweets are merged and sorted according to their \texttt{created\_at} timestamp in descending order. This data is returned to the home page. If the user triggers a reload by reaching the end of the feed or by \enquote{pull to refresh}, the previously described process starts again.
+Finally, the private and public tweets are merged and sorted according to their \texttt{created\_at} timestamp in descending order. This data are 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/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 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.
+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 are 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}
@@ -57,7 +57,7 @@ A solution based on a blockchain increases complexity for the user. Since the hy
 \label{sec:ipfs}
 \ac{IPFS}\footnote{https://ipfs.io/} is a distributed file system that brings together the ideas of other successful \ac{P2P} systems (DHTs, BitTorrent, Self-Certified Filesystems (SFS) and Git) \cite{benet2014ipfs}. The original idea for \ac{IPFS} came from Juan Benet in 2014. Protocol Labs\footnote{https://protocol.ai}, founded by Benet, now manages the open source project \cite{benetXXXXlinkedin}.
 
-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 \ac{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,
+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 are 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 \ac{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 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.
 

thesis/content/06-discussion/achievement.tex

@@ -14,7 +14,7 @@ Since it is not possible to execute code on the Twitter's servers, no other solu
 As described in Chapter \ref{sec:solution-strategy-architecture}, a solution architecture either contains or does not contain additional servers. In the objectives in Chapter \ref{sec:objective}, a solution without additional servers was preferred. However, since GUN requires a relay server to establish the connection between the peers, this self-imposed goal could not be achieved.
 
 \subsubsection{Data Sovereignty}
-The user can decide for himself whether the data is shared with other users via the private network or the Twitter servers when posting or liking a tweet. Since other functionalities that require data from the user (e.g., information in the profile, direct messages) have not been implemented, at least the prototype fulfills the requirement partly.
+The user can decide for himself whether the data are shared with other users via the private network or the Twitter servers when posting or liking a tweet. Since other functionalities that require data from the user (e.g., information in the profile, direct messages) have not been implemented, at least the prototype fulfills the requirement partly.
 
 However, data about user behavior can still be collected. The user is authenticated against the \ac{API} so that his requests can be unambiguously assigned. Using this usage data, Twitter can record which profiles are called up and what the user searches for. This data can also be used to conclude a user's preferences and interests. Hybrid \ac{OSN} offers no protection against this type of data collection.
 
@@ -23,7 +23,7 @@ Private data should be accessible only to those users for whom they are intended
 
 By distributing the public key to decrypt the data via the profile, the same user group is granted access to a user's private tweets, which can also see the official Twitter tweets. The additional symmetric encryption of the public key history by the Hybrid \ac{OSN} app ensures that Twitter cannot decrypt the public key history and thus also the private tweets. Therefore, the requirement can be evaluated as fulfilled.
 
-The implementation differs from the standard solution for this problem. Typically, data is encrypted with the recipient's public key to ensure that only the recipient can decrypt it with their private key. However, in the case of Twitter and the public profiles, the recipient circle of a tweet is not known. Accordingly, it is not possible to explicitly encrypt data for a specific recipient.
+The implementation differs from the standard solution for this problem. Typically, data are encrypted with the recipient's public key to ensure that only the recipient can decrypt it with their private key. However, in the case of Twitter and the public profiles, the recipient circle of a tweet is not known. Accordingly, it is not possible to explicitly encrypt data for a specific recipient.
 
 An alternative to the implementation in Hybrid \ac{OSN} would be to encrypt data with the symmetrical Hybrid \ac{OSN} key for public profiles and to encrypt data asymmetrically with the public keys of the recipient for private profiles. The advantage would be that users with a public profile would not have to generate keys and the configuration effort would be reduced. A simpler configuration would have a positive effect on the requirement for minimal configuration effort. The disadvantage would be that a user with a private profile and a large number of approved followers would have to calculate the encryption and upload the data for each. This would be in contrast to the requirement to conserve resources.
 

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

@@ -12,9 +12,9 @@ Active use requires a public tweet and a reference in the profile description fo
 
 \subsection{GUN}
 \label{sec:threat-model-gun}
-In Hybrid \ac{OSN}, GUN takes the role of a database shared by the peers. The dashboard also establishes a direct connection. The data is publicly accessible and editable.
+In Hybrid \ac{OSN}, GUN takes the role of a database shared by the peers. The dashboard also establishes a direct connection. The data are publicly accessible and editable.
 
-The stored data is a combination of hashtag and timestamp, which serve as information for the trends in the Hybrid \ac{OSN} dashboard. For every private tweet of a user, there is an entry consisting of Twitter user id, \ac{IPFS} address hash, and timestamp. Also, there are the private likes, for which there is a counter to the tweet id.
+The stored data are a combination of hashtag and timestamp, which serve as information for the trends in the Hybrid \ac{OSN} dashboard. For every private tweet of a user, there is an entry consisting of Twitter user id, \ac{IPFS} address hash, and timestamp. Also, there are the private likes, for which there is a counter to the tweet id.
 
 For preventing the hashtag and private tweet timestamps from connecting, the time of the hashtag timestamp is set to 00:01. The trends in the dashboard are aggregated by the day, so the exact time is not essential.
 
@@ -26,9 +26,9 @@ Creating entries for private tweets does not have a significant effect because t
 \label{sec:threat-model-ipfs}
 Since \ac{IPFS} is publicly accessible, anyone can add and retrieve data. However, it is not possible to change or delete data. A hash of the content addresses the data stored in \ac{IPFS}. Since the content is entirely unknown (especially by encrypting the plaintext content), it is not possible to conclude the hash. A targeted search for private data in \ac{IPFS} is therefore impossible. The encrypted data also does not contain any clues that allow conclusions to be drawn about Hybrid \ac{OSN}.
 
-In combination with the publicly available information from GUN, all private tweet data could be found in \ac{IPFS}. However, because of the encryption of the content, the data is worthless.
+In combination with the publicly available information from GUN, all private tweet data could be found in \ac{IPFS}. However, because of the encryption of the content, the data are worthless.
 
-Due to the decentralization of the system, the availability of \ac{IPFS} is always guaranteed. However, only as long as there are peers who make the service possible. If a peer leaves the network, its data is also lost if not reproduced beforehand. Therefore, there is no guarantee for the permanent availability of data.
+Due to the decentralization of the system, the availability of \ac{IPFS} is always guaranteed. However, only as long as there are peers who make the service possible. If a peer leaves the network, its data are also lost if not reproduced beforehand. Therefore, there is no guarantee for the permanent availability of data.
 
 \subsection{Encryption – Leakage of Keys}
 \label{sec:threat-model-encryption}

thesis/content/07-conclusion.tex

@@ -22,7 +22,7 @@ While GUN solves the problem of a distributed database, it has various limitatio
 
 Field studies of users using the Hybrid \ac{OSN} app could be made as for future work to validate user acceptance of the solution. By learning from the usage behavior, the app could be further optimized to encourage the use of the Hybrid \ac{OSN} app and also improve the concept of a hybrid solution.
 
-Another possible area for future work can be carried out on the anonymized data sharing with the service provider. In-depth analysis of the service provider's demands and the available private date need to be carried out. It has to be evaluated which kind of anonymized data is worthy for the service provider.
+Another possible area for future work can be carried out on the anonymized data sharing with the service provider. In-depth analysis of the service provider's demands and the available private date need to be carried out. It has to be evaluated which kind of anonymized data are worthy for the service provider.
 
 The worked out concept was validated primarily for Twitter. Therefore, an exciting area for future work could be the precise validation for other \acp{OSN}, like Facebook, Instagram or Snapchat. By applying the concept to other \acp{OSN}, the stated requirements could be further refined and thus the overall concept further improved.