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 like Twitter. As proof of concept, they created an Android app.

\subsubsection{Design Principles}
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.
	\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 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 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 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 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 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 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 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 achieved during the creation 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 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 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.