|
|
@@ -1,17 +1,17 @@
|
|
|
-With Twitterize, Daubert et al. present an approach on how data can be protected by a special overlay network and anonymously exchanged within a social network\cite{daubert2014twitterize}. The proposal refers to micro-blogging social networks such as Twitter. For this, a proof of concept in the form of an Android app was developed.
|
|
|
+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.
|
|
|
|
|
|
\subsubsection{Design Principles}
|
|
|
-Daubert et al. made various demands on the proposed solution. With regard to the protection of privacy in general:
|
|
|
+Daubert et al. made 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.
|
|
|
- \item \textbf{Anonymity}: A certain user should not be identifiable within a set of users (anonymity set).
|
|
|
+ \item \textbf{Anonymity}: A individual user should not be identifiable within a set of users (anonymity set).
|
|
|
\end{itemize}
|
|
|
|
|
|
-And with regard to the design of the implementation:
|
|
|
+Also, concerning the design of the implementation:
|
|
|
|
|
|
\begin{itemize}
|
|
|
- \item \textbf{Understandable privacy}: The user should decide for himself which level of privacy protection he chooses for his messages. The system should communicate this in an understandable way.
|
|
|
+ \item \textbf{Understandable privacy}: The user should decide for himself which level of privacy protection he chooses for his messages. The system should reasonably communicate this.
|
|
|
\item \textbf{Simple group management}: Group memberships should be managed quickly and easily.
|
|
|
\item \textbf{Low overhead}: The client should have the full functionality of the original client and have as little overhead as possible for the extended functionality.
|
|
|
\end{itemize}
|
|
|
@@ -21,18 +21,18 @@ The basic idea behind Twitterize is the encrypted, anonymous exchange of message
|
|
|
|
|
|
In order to establish communication within a group, the three following phases must be passed through one after the other:
|
|
|
\begin{enumerate}
|
|
|
- \item Generating and exchanging the keys of a hashtag
|
|
|
- \item Flooding and subscribing to build an overlay network
|
|
|
- \item Exchanging of messages
|
|
|
+ \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 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 stays private.
|
|
|
|
|
|
-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.
|
|
|
+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, Near Field Communication (NFC), QR codes is conceivable.
|
|
|
|
|
|
-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 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 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.
|
|
|
+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.
|
|
|
|
|
|
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}.
|
|
|
|
|
|
@@ -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 hashtag 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 standard home and user timelines, each hashtag gets its 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 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 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 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.
|
|
|
+The avoidance of overheads was also successful, although the timeline is updated in the 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 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.
|
|
|
|
|
|
-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.
|
|
|
+Restrictions arise on the one hand due to limits on the use of the Twitter API and on the other hand because the application must always be online to get the best user experience.
|
