Carsten Porth před 5 roky
rodič
revize
f621cf49ab

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

@@ -26,11 +26,11 @@ In order to establish communication within a group, the three following phases m
 	\item Exchanging 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 hash tag is not revealed.
+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 is not revealed.
 
 In order 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, NFC, QR codes, etc. is conceivable.
 
-If the users of a group with a common hashtag are all aware of the key and the hash tag, the second phase of building an overlay network begins. Here the private flooding mechanism is used\cite{daubert2013distributed-anonymous-pubsub}. A publisher creates an advertisement tweet consisting of a pseudonym and the first element of a hash chain and posts it in the underlay network. This tweet appears in the timelines of his followers. If not already done, each follower distributes the advertisement tweet on his own timeline and thus reaches his own followers. However, this tweet differs from the original tweet by extending the hash chain. It generates a hash of the previous hash chain and thus receives the next element of the chain. According to this principle, the entire network is flooded and as a result, each user saves a triplet consisting of pseudonym, hash chain and the user before him in the chain in a database table.
+If the 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 own timeline and thus reaches his own followers. However, this tweet differs from the original tweet by extending the hash chain. It generates a hash of the previous hash chain and thus receives the next element of the chain. According to this principle, the entire network is flooded and as a result, each user saves a triplet consisting of pseudonym, hash chain and the user before him in the chain in a database table.
 
 If the advertisement tweet reaches a user who is aware of the hashtag and the associated key, the user (so called subscriber) responds with a subscription tweet. This message is addressed to the user from whom the advertisement tweet was received and contains the user name (@user) and the pseudonym. The user thus addressed in turn posts a message consisting of the user name of the user from whom he received the advertisement tweet and the pseudonym. This happens until the original publisher has been reached. In this process, another routing table is filled with pseudonym and sending user. The overlay network is thus formed. Since each user only has a local view of the message flow, no conclusions about sender and recipient can be drawn from the message flow.
 
@@ -44,12 +44,12 @@ In the third phase, users can exchange messages using the previously shared hash
 \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 normal home and user timelines, each hash tag gets its own 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 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 normal home and user timelines, each hashtag gets its own timeline. Each timeline is accessible via a tab.
 
 For encryption 128bit keys with AES CBC is used. The keys are exchanged between the users via NFC or QR codes. Since data structures, such as 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.
 
 The privacy requirements are met by the design of the Twitterize architecture. The other requirements for implementation were also well received during the development of the app. With the exchange of keys via 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 background every minute. CPU usage and power consumption were only slightly above the values of the original Twitter app. For the storage of the additional data only little space is necessary, since each hash tag occupies only 48 byte. 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 background every minute. CPU usage and power consumption were only slightly above the values of the original Twitter app. For the storage of the additional data only little space is necessary, since each hashtag occupies only 48 byte. 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 API and on the other hand due to the fact that the application must be always online to get the best user experience.

+ 1 - 1
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.
 
-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 hash tags 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 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.
 
 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}).
 

+ 1 - 1
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 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 hash tags 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 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.
 
 \subsection{Load the Home Timeline}
 \label{sec:load-home-timeline}

+ 7 - 0
thesis/content/06-discussion.tex

@@ -1,2 +1,9 @@
 \chapter{Evaluation}
 \label{ch:evaluation}
+I will discuss,
+\begin{itemize}
+	\item how the requirements defined in chapter 4 were met in the prototype,
+	\item limitations,
+	\item benefits in comparison with the projects mentioned in related work,
+	\item a threat model.
+\end{itemize}