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

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. 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 individual user should not be identifiable within a set of users (anonymity set).
\end{itemize}

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 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}

\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: 
\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.

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.

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.

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}}
	\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.

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.

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 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.

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.