Feedback Isabel

thesis/content/03-related-work.tex

@@ -1,6 +1,6 @@
 \chapter{Related Work}
 \label{ch:related-work}
-This chapter gives a comprehensive overview of different projects trying to protect the users' personal data in \acp{OSN}. Hereby, six different approaches are presented. First, extensions are considered that make the use of established social networks more secure. Then, alternative social networks will be presented that have placed the protection of personal data at the center. After that two next-generation social networks will be considered, which take advantage of the blockchain technology and belong to the group of dApps. Finally, the ActivityPub protocol is presented, which maps the communication in decentralized platforms. The chapter concludes with a summary of the related work.
+This chapter gives a comprehensive overview of different projects trying to protect the users' personal data in \acp{OSN}. Hereby, six different approaches are presented. First, extensions are considered which increase the security of established social networks. Then, alternative social networks will be presented that have placed the protection of personal data at the center. Furthermore, two next-generation social networks will be considered, which take advantage of the blockchain technology and belong to the group of dApps. Finally, the ActivityPub protocol is presented, which maps the communication in decentralized platforms. The chapter concludes with a summary of the related work.
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 % For each project, write about

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

@@ -1,7 +1,7 @@
-With Twitterize, Daubert et al. present an approach on how a particular overlay network can protect data and anonymously exchanged within a social network\cite{daubert2014twitterize}. The proposal refers to micro-blogging social networks such as Twitter. As proof of concept, they created an Android app.
+With Twitterize, Daubert et al. present an approach on how a particular overlay network can protect data and anonymously exchanged within a social network \cite{daubert2014twitterize}. The proposal refers to micro-blogging social networks like Twitter. As proof of concept, they created an Android app.
 
 \subsubsection{Design Principles}
-Daubert et al. made various demands on the proposed solution. Concerning the protection of privacy in general:
+Daubert et al. stated various demands on the proposed solution. Concerning the protection of privacy in general:
 
 \begin{itemize}
 	\item \textbf{Confidentiality}: Messages exchanged between sender and receiver should be transmitted secretly.
@@ -19,37 +19,35 @@ Also, concerning the design of the implementation:
 \subsubsection{Architecture}
 The basic idea behind Twitterize is the encrypted, anonymous exchange of messages within a group via an overlay network. There is a group-specific hashtag for this. The messages are forwarded in the underlay network by users until they reach the recipient.
 
-In order to establish communication within a group, the three following phases must be passed through one after the other: 
+In order to establish communication within a group, the three following phases have to be passed through one after the other: 
 \begin{enumerate}
 	\item Generation and exchange of the keys of a hashtag
 	\item Flooding and subscription to build an overlay network
 	\item Exchange of messages
 \end{enumerate}
 
-First, a user must define the hashtag and generate a key for symmetric encryption. This key is used later to encrypt the messages as well as the hashtag itself. From the encrypted hashtag, only a hash value is used (so-called pseudonym) so that the actual hashtag stays private.
+First, a user has to define the hashtag and generate a key for symmetric encryption. This key is used later to encrypt the messages as well as the hashtag itself. From the encrypted hashtag, only a hash value is used (so-called pseudonym) so that the actual hashtag stays private. In order to join the group, other users need the key and knowledge of the name of the hashtag. However, the key exchange should not be carried out via the social network. An exchange via e-mail, \ac{NFC} or QR codes is conceivable.
 
-In order to join the group, other users need the key and knowledge of the name of the hashtag. However, the key exchange should not be carried out via the social network used. An exchange via e-mail, \ac{NFC}, QR codes is conceivable.
+In second phase, the overlay network is constructed. Here, the private flooding mechanism is used \cite{daubert2013distributed-anonymous-pubsub}. A publisher creates an advertisement tweet consisting of a pseudonym and the first element of a hash chain and posts it in the underlay network. This tweet appears in the timelines of his followers. Then, each follower distributes the advertisement tweet on his timeline and thus reaches his followers. However, this tweet differs from the original tweet by extending the hash chain. It generates a hash of the previous hash chain and thus receives the next element of the chain. According to this principle, the entire network is flooded, and as a result, each user saves a triplet consisting of the pseudonym, the hash chain and the user previous to him in the chain in a database table.
 
-If the users of a group with a common hashtag are all aware of the key and the hashtag, the second phase of building an overlay network begins. Here the private flooding mechanism is used \cite{daubert2013distributed-anonymous-pubsub}. A publisher creates an advertisement tweet consisting of a pseudonym and the first element of a hash chain and posts it in the underlay network. This tweet appears in the timelines of his followers. If not already done, each follower distributes the advertisement tweet on his timeline and thus reaches his followers. However, this tweet differs from the original tweet by extending the hash chain. It generates a hash of the previous hash chain and thus receives the next element of the chain. According to this principle, the entire network is flooded, and as a result, each user saves a triplet consisting of the pseudonym, the hash chain and the user previous to him in the chain in a database table.
-
-If the advertisement tweet reaches a user who is aware of the hashtag and the associated key, the user (so-called subscriber) responds with a subscription tweet. This subscription message is addressed to the user from whom the advertisement tweet was received and contains the user name (@user) and the pseudonym. The user thus addressed in turn posts a message consisting of the user name of the user from whom he received the advertisement tweet and the pseudonym. This happens until the subscription message reaches the original publisher. In this process, the pseudonym and the sending user are stored in another routing table. The overlay network is thus formed. Since each user only has a local view of the message flow, no conclusions about the sender and recipient can be drawn from the message flow.
+If the advertisement tweet reaches a user, who is aware of the hashtag and the associated key, the user (so-called subscriber) responds with a subscription tweet. This subscription message is addressed to the user from whom the advertisement tweet was received and contains the user name (@user) and the pseudonym. The user thus addressed in turn posts a message consisting of the user name of the user from whom he received the advertisement tweet and the pseudonym. This happens until the subscription message reaches the original publisher. In this process, the pseudonym and the sending user are stored in another routing table. In this way, the overlay network is formed. Since each user only has a local view of the message flow, no conclusions about the sender and recipient are possible.
 
 In the third phase, users can exchange messages using the previously shared hashtag. The messages are encrypted with the key belonging to the hashtag and then posted together with the hashtag to the timeline. By posting the message again, forwarders ensure that the message is forwarded to the recipient. The exact procedure is shown schematically in Figure \ref{fig:twitterize-information-flow}.
 
 \begin{figure}[h!]
 	\centering
 	\includegraphics[width=1.0\textwidth]{twitterize-information-flow}
-	\caption{Information flow of a notification. The notification is created, encrypted and posted to the publisher's timeline. The notification is then picked up by a forwarder who follows the publisher. Next, the status update is being processed and finally posted on the forwarder's timeline. Lastly, the subscriber who follows the forwarder receives the notification. \cite{daubert2014twitterize}}
+	\caption{Information flow of a notification in Twitterize. The notification is created, encrypted and posted to the publisher's timeline. The notification is then picked up by a forwarder who follows the publisher. Next, the status update is being processed and finally posted on the forwarder's timeline. Lastly, the subscriber who follows the forwarder receives the notification. \cite{daubert2014twitterize}}
 	\label{fig:twitterize-information-flow}
 \end{figure}
 
 \subsubsection{Proof of Concept}
-As proof of concept, Daubert et al. implemented Twitterize as an app for Android. The app was written in Java, the code remained closed source, and the app is not available from the Google Play Store. The representation of the data in the app takes place on different timelines. In addition to the standard home and user timelines, each hashtag gets its timeline. Each timeline is accessible via a tab.
+As proof of concept, Daubert et al. implemented Twitterize as an app for Android. The app was programmed in Java, the code remained closed source, and the app is not available from the Google Play Store. The representation of the data in the app takes place on different timelines. In addition to the standard home and user timelines, each hashtag gets its timeline which is accessible via a tab.
 
-For encryption 128bit keys with \ac{AES} \ac{CBC} is used. The keys are exchanged between the users via \ac{NFC} or QR codes. Since data structures, such as \ac{JSON}, are too verbose, the tweets are encoded using Base64. To make message types distinguishable, rarely used UTF-8 symbols are used to give the messages a rough structure. The formation of the overlay network and the exchange of messages then works as described above.
+For encryption 128bit keys with \ac{AES} \ac{CBC} is used. The keys are exchanged between the users via \ac{NFC} or QR codes. Since data structures, such as \ac{JSON}, are too verbose, the tweets are encoded using the Base64 algorithm. To distinguish between message types, rarely used UTF-8 symbols are utilized to give the messages a rough structure. The formation of the overlay network and the exchange of messages then works as described above.
 
-The design of the Twitterize architecture meets the privacy requirements. The other requirements for implementation were also well received during the development of the app. With the exchange of keys via \ac{NFC} or QR codes an easy way for key management was found and implemented. Just a few seconds of physical proximity is enough to form a group.
+The design of the Twitterize architecture meets the privacy requirements. The other requirements for implementation were also achieved during the development of the app. With the exchange of keys via \ac{NFC} or QR codes an easy way for key management was found and implemented. Just a few seconds of physical proximity are enough to form a group.
 
-The avoidance of overheads was also successful, although the timeline is updated in the background every minute. \ac{CPU} usage and power consumption were only slightly above the values of the original Twitter app. For the storage of the additional data, only a little space is necessary, since each hashtag occupies only 48 bytes. Assuming that in the Twitter Social Graph two arbitrary users are connected via 4.71 following users in between, an average delivery time of 142 seconds was calculated for a message.
+The avoidance of overheads was also successful, although the timeline is updated in the background every minute. \ac{CPU} usage and power consumption were slightly above the values of the original Twitter app. For the storage of the additional data, only a little space is necessary, since each hashtag occupies just 48 bytes. Assuming that in the Twitter Social Graph two arbitrary users are connected via 4.71 following users in between, an average delivery time of 142 seconds was calculated for a message.
 
-Restrictions arise on the one hand due to limits on the use of the Twitter \ac{API} and on the other hand because the application must always be online to get the best user experience.
+Restrictions arise due to limits on the use of the Twitter \ac{API} and because the application must always be online to get the best user experience.

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

@@ -18,6 +18,10 @@
 \label{sec:hybrid-osn-presentation}
 \input{content/05-proof-of-concept/hybrid-osn}
 
+\section{Providing Insights to the Service Provider}
+\label{sec:insights}
+\input{content/05-proof-of-concept/insights}
+
 \section{Building Block View}
 \label{sec:building-block-view}
 \input{content/05-proof-of-concept/building-block-view}
@@ -30,10 +34,6 @@
 \label{sec:security}
 \input{content/05-proof-of-concept/security}
 
-\section{Providing Insights to the Service Provider}
-\label{sec:insights}
-\input{content/05-proof-of-concept/insights}
-
 \section{Summary}
 \label{sec:proof-of-concept-summary}
 \input{content/05-proof-of-concept/summary}

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

@@ -1,4 +1,4 @@
-The requirements mentioned in \ref{sec:requirements} also include the provision of anonymized data for the \ac{OSN} service provider. Since the business model of Twitter is based on personal data, and therefore the interests of hybrid \ac{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 \ac{OSN} service provider. Since the business model of Twitter is based on personal data, and therefore the interests of Hybrid \ac{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 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.
 
@@ -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 and then 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 is loaded, aggregated and displayed.

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 \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.
+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. For this reason, a solution with additional servers was not pursued further in the creation process 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.
+With the decision for a client app, the creation of an add-on, which was discussed in the previous chapter as a possible solution strategy, was thus fundamentally ruled out. Nevertheless, consideration always included how the architecture could be this open and flexible to enable all kinds of extensions and clients participating in the \ac{P2P} network.
 
-Since it is only a proof of concept, the mapping of the complete functionality of the \ac{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.
+Since it is only a proof of concept, the mapping of the complete functionality of the \ac{OSN} was not the highest priority. However, again, this was taken into account by considerations and decisions, for example how data formats can be arranged so flexible that every function can be mapped.
 
 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/06-discussion/threat-model.tex

@@ -2,7 +2,7 @@ In the threat model of Hybrid \ac{OSN} the potential threats for different sub-a
 
 \subsection{Service Provider – Twitter}
 \label{sec:threat-model-service-provider}
-Hybrid \ac{OSN} users can be easily identified by the service provider Twitter, even if they only use Hybrid \ac{OSN} passively to read private tweets of other users and do not write private tweets themselves.
+Hybrid \ac{OSN} users can be easily identified by the service provider Twitter, even if they only use the app passively to read private tweets of other users and do not write private tweets themselves.
 
 For using the Twitter \ac{API}, it is essential to register an app to get an app token. This app token is attached to all requests sent to the Twitter \ac{API}. When logging in on Hybrid \ac{OSN} for the first time, the user accepts to use the app to access Twitter.