Rewriting of chapter 4

thesis/content/04-concept.tex

@@ -1,44 +1,31 @@
-\chapter{Concept}
+\chapter{Concept of a Hybrid Online Social Network}
 \label{ch:concept}
+\input{content/04-concept/introduction}
 
-The last few years have shown that the private data of users in social networks is not secure. On the one hand, social networks are popular targets for hackers and on the other hand, the collected personal data is processed and used, for example, for targeted advertising. For the users of the network it is easy to share personal information, messages and pictures with other users. While the circle of users who can see this data can usually be determined by the author himself, the social network inevitably has access to this data because it is stored on the operator's servers. What happens to the data is not transparent to the user. But there are also social networks like Ello\footnote{https://ello.co/} or Vero\footnote{https://www.vero.co/} that make it their business to protect users' data in a special way and promise to take care. Unfortunately, such networks fail regularly because the users of the large social networks are trapped on these platforms by a lock-in effect. Since the majority of contacts on the large networks are already linked, it is unattractive to switch to a smaller, new social network where the contacts are missing.
+\section{Requirements to the Hybrid OSN}
+\label{sec:requirements}
+\input{content/04-concept/requirements}
 
-Users are faced with the dilemma that switching to another social network entails the loss of contacts they have collected over years. But staying with the large network entails uncertainty about their own data. So, the question is how to share fewer sensitive data with the provider, despite the usual use of a social network. In the context of this master thesis, this question was dealt with intensively and a solution of a hybrid social network was worked out. The idea of a hybrid OSN was initially proposed by researchers of the Researcher Training Group (RTG) \enquote{2050 - Privacy and Trust for Mobile Users}\footnote{https://www.informatik.tu-darmstadt.de/privacy-trust/privacy\_and\_trust/index.en.jsp}.
+\section{Stakeholders}
+\label{sec:stakeholders}
+\input{content/04-concept/stakeholders}
 
-\enquote{Hybrid} in this case means that an existing (social) network is extended by another network for data exchange. This is a P2P network among the users of the social network, which allows data to be exchanged directly so that the operator of the social network is not aware of it. When using the social network, the P2P network is to be superimposed like a privacy layer. During the actions carried out, the user can then decide for himself via which network the data should be exchanged. In order to exchange data via a P2P network, the usual client must be extended or manipulated for the respective social network or a separate client must be developed for use. Using a P2P network would also have the advantage that the data could not be censored by the operator of the OSN.
+\section{Restrictions}
+\label{sec:restrictions}
+\input{content/04-concept/restrictions}
 
-The following sections describe the requirements for the respective components OSN, P2P network and client.
+\section{Quality Goals}
+\label{sec:quality-goals}
+\input{content/04-concept/quality-goals}
 
-\section{Requirements to the OSN}
-\label{sec:requirements-osn}
+\section{Solution Strategy - Architecture}
+\label{sec:solution-strategy-architecture}
+\input{content/04-concept/solution-strategy-architecture}
 
-Social networks are usually used via a web frontend or associated apps. While there is no way to influence the content and extend the functionality of apps, web pages can be manipulated by browser add-ons to add the desired functionality. Another possibility is to display the contents of the social network in a separate, self-developed application. In this case one would have complete control and could adapt the functionalities accordingly. There are two possible ways to access the original content of the social network. First, the websites could be crawled and the content extracted. Second, some social networks provide interfaces that allow developers to communicate directly with the servers and thus exchange data easily. These interfaces are called API.
-
-Most of the social networks offer an sort of API. But in most cases, the APIs provide only a very limited scope of functionality of the network. Often it is only possible to include public content into a website, like Tweets are often embedded on news websites. Not only the amount of functionality is limited, the number of requests per time interval is often limited, too. Crawling in contrast does not rely on the service provider. A clear advantage is that this way always works. However, much more effort is needed to extract the desired data from the website. The data is expected in a certain structure in order to be extracted. If this structure is changed by the operator of the social network, the crawling fails and the data can no longer be extracted. In addition, social networks today are complicated web applications. The content is dynamically reloaded and the page changes dynamically depending on the action. This is difficult to capture with crawlers. Furthermore, networks protect themselves from crawlers and try to prevent them from crawling content. In the best case, the network operator does not notice that his page is being crawled because ideally the crawler behaves like a normal user and can therefore not be distinguished. To publish content in the social network, the requests sent to the network would have to look as if they had been created by the forms in the web frontend. Here, too, various security mechanisms attempt to identify and block such \enquote{faked} requests, as this could also be used to load malicious code onto the servers. All in all, it is very difficult nowadays to communicate with the servers of a social network via crawling and fake requests.
-
-It is much easier if an interface is provided and clearly documented how data can be retrieved or added. It is important that the essential functions are provided via the API, so that a client application can be developed that is not inferior to the original website in terms of functionality. Otherwise the users won’t switch to the alternative client. By using an API, one enters into a certain dependency on the network. There is no guarantee that the provider will keep up the API and offer all the functionality. Since they are the provider, they decide what happens to the API and the developers using the API and build their applications are completely dependent on them. 
-
-To use an API, usually a previous registration is necessary. After registration, the developer receives an API key, which is sent with every request to the API and checked for validity. The number of negative incidents with different social networks has led to providers gradually restricting their APIs more and more. One is the removal of endpoints for certain actions, the other is the introduction of limits. By sending the API key, it is possible to see which developer or which application communicates with the API. Limits can then be used to determine how many requests are processed in a certain time interval or how many users can use the network via this application. It is also possible that the developer has to pay for the API key.
-
-Regardless of the method chosen to exchange data with the social network, a unique content identifier is required. This is necessary so that interactions with it can be related. By knowing the ID of a post, associated comments can be loaded - both from the provider's server and from the private P2P network.
-
-\section{Requirements to the Hybrid Client}
-\label{sec:requirements-client}
-
-In order for users to be ready to use an alternative hybrid client for social networking, this client must meet a number of requirements. First, all the functionality that the user knows from the official app/website must be available. If this is not the case, they will always be forced to go back to the original application. Using more than one app for a network is not user friendly and should be avoided. Basically, great importance should be given to user-friendliness. Complicated procedures should be avoided as best as possible or simplified in such a way that really every user is able to understand and use them correctly. This also means that great importance must be attached to a good user experience, so that content is presented in an appealing way and operation is intuitive.
-
-The hybrid client must also meet a number of technical requirements in order to be accepted by the user and contribute to a good user experience. This includes, among other things, the availability for common operating systems. It is necessary that the hybrid client can be used wherever the social network can otherwise be used. If messages are exchanged via the P2P network, but there is no client for Apple’s iOs, for example, users with an iPhone cannot retrieve this message on the move. This would result in the message being exchanged via the OSN's server despite the sensitive content that is to be protected from the OSN's operator, since only in this case can the recipient receive the message. It is also important that the hybrid client uses resources such as memory, battery and data volume sparingly. Since client devices (peers) play a special role in a P2P network, the careful use of resources is particularly challenging. This is because the data must be stored on the peers and ideally made available to other peers at any time. It should also be possible for a user to log on to several devices with his account and still benefit from all the advantages. This parallel use and the synchronicity of the data must be guaranteed.
-
-Finally, the security of the data exchanged between the hybrid clients must be guaranteed. The OSN must not be able to use these data and even less not be able to assign these data to a certain user. It must also be ensured that the data can only be read by those users who are authorized to do so. These security aspects must have the highest priority when designing the system.
-
-Most social networks can be used free of charge. Ideally, the use of the hybrid client is also free. Otherwise it could be the first argument against using this client.
-
-\section{Requirements from the OSN}
-\label{sec:requirements-from-osn}
-
-Basically it can be assumed that the operator of an OSN does not like the idea of a P2P extension of his network. Therefore, information from the P2P network should be offered to the operator without establishing a reference to a user. With this anonymous data, the operator still has important information at his disposal, for example for the recognition of trends.
+\section{Solution Strategy - Client}
+\label{sec:solution-strategy-client}
+\input{content/04-concept/solution-strategy-client}
 
 \section{Summary}
 \label{sec:concept-summary}
-
-\textit{todo...}
+\input{content/04-concept/summary}

thesis/content/04-concept/introduction.tex

@@ -0,0 +1,10 @@
+The criticism of the protection of privacy on the Internet, especially in social networks, is not new. As early as 2010, the founders of diaspora* discovered that there was no social network that sufficiently protected the privacy of users\cite{diaspora2010kickstarter-pitch}. Their idea of a decentralized network that protected user data by design convinced so many people that even before the start of the development people donated \$200,000 instead of the required \$10,000 to a kickstarter campaign.
+
+The reason for the poor protection of personal data lies in the centralized system structure used by all leading social platforms. With this structure, the data is stored centrally and largely unencrypted. The service provider therefore inevitably has access to this data. Which data is collected during use and what happens to the data is not transparent to the user.
+On the one hand, the user data is evaluated in order to improve the user experience (suggestions for content matching the user’s preferences using recommender systems), but on the other hand also in order to make a profit. Revenues can be generated through personalized advertising or, in the worst case, through the sale of data. Furthermore, the protection of data against access by third parties via official interfaces (harvesting) or unauthorized hacking cannot be ruled out. And last but not least, due to applicable law, it may be necessary for data to be transferred to secret services or government agency.
+
+Although the problems and dangers have been known for a long time and new scandals regularly become known to the public, the users remain largely loyal to the respective social networks. Alternative social networks, which focus on privacy protection, lack attractiveness, so that they gain only a few users and often fail after a short time. Obviously, the connection to the respective social network is so strong that the barrier to switching to another, more secure social network is not overcome. The amount of content already created, the network built, and the large number of contacts using the same platform all create this so-called lock-in effect.
+
+If switching to another platform is not an alternative, it is necessary to look for ways to better protect users and their data on existing platforms. The Researcher Training Group (RTG) \enquote{Privacy and Trust for Mobile Users}\footnote{https://www.informatik.tu-darmstadt.de/privacy-trust/privacy\_and\_trust/index.en.jsp} in research area B \enquote{Privacy and Trust in Social Networks} is dealing with problems like this. Subarea B.2 deals specifically with the protection of privacy in hybrid social networks.
+
+In the following, a concept for a hybrid social network will be developed that tries to take into account the interests of the different stakeholders. In addition, functionality requirements and potential limitations are listed. Finally, a solution strategy is shown and a possible architecture is presented. The concept should be applicable to all social networks. A specific implementation will be presented in the next chapter for Twitter.

thesis/content/04-concept/quality-goals.tex

@@ -0,0 +1,15 @@
+The following quality objectives (Table \ref{tab:quality-goals}) have been defined to ensure that the quality of implementation is as high as possible. By adhering to the quality targets, errors and problems are to be avoided, the application is to remain maintainable and new developers are to be enabled to get started quickly.
+
+\begin{table}[h!]
+	\centering
+	\begin{tabular}{|l|l|}
+		\hline
+		\textbf{Quality Goal} & \textbf{Motivation}                                                                                                                                                                   \\ \hline
+		Analyzability         & \begin{tabular}[c]{@{}l@{}}- Module, class and method names in English\\ - Detailed documentation of the public interfaces\\ - Compliance with the Clean Code principles\end{tabular} \\ \hline
+		Changeability         & \begin{tabular}[c]{@{}l@{}}- Common programming language\\ - Program modules against interfaces to keep them interchangeable\end{tabular}                                             \\ \hline
+		Testability           & - The architecture should allow easy testing of all building blocks                                                                                                                   \\ \hline
+		Transparency          & - The application should be Open Source                                                                                                                                               \\ \hline
+	\end{tabular}
+	\caption{The quality goals are the relevant requirements and the driving forces that software architects and developers should consider.}
+	\label{tab:quality-goals}
+\end{table}

thesis/content/04-concept/requirements.tex

@@ -0,0 +1,23 @@
+In order for users of an OSN to be willing to use another client for or an additional extension when using the OSN, the solution should meet certain functional and non-functional requirements.
+
+\textbf{Functional requirements}:
+\begin{itemize}
+	\item The standard functionality of the OSN can be used without restrictions.
+	\item The user can clearly see which way (private or OSN) the data goes and where it comes from.
+	\item Data access should only be possible for authorized users.
+	\item The data exchange should be automatically encrypted, so that the data is worthless for third parties.
+	\item The data format is flexible in order to map changes and new OSN functionalities.
+	\item Platform independence
+	\item The solution is client-side, since the OSN Server cannot be influenced
+	\item The OSN Service Provider can retrieve anonymized data relevant to him.
+\end{itemize}
+
+\textbf{Non-functional requirements}:
+\begin{itemize}
+	\item Data exchange over the private network is fast and secure.
+	\item Simple, understandable user interface
+	\item Attractive, modern design
+	\item No violation of the guidelines and terms of use of the OSN
+	\item No restrictions for classic users who do not use the hybrid solution
+	\item The additional effort for the user when using the hybrid solution should be minimal.
+\end{itemize}

thesis/content/04-concept/restrictions.tex

@@ -0,0 +1,12 @@
+When designing the hybrid OSN, there are a few limitations that need to be considered, for which appropriate solutions can be found. These restrictions include:
+
+\begin{itemize}
+	\item \textbf{Interfaces of the OSN}: Ideally the OSN offers a public API with the full functionality. Since the user's data should be protected as best as possible, access via the API is normally restricted. This may be due to a limited number of requests per time interval or a limited range of offered functions.
+	\item \textbf{Crawling the OSN web pages}: If there is no official API or if it is strongly restricted, the contents can theoretically also be extracted by crawling. However, this brings with it several challenges. Modern web pages load many contents asynchronously, so that the initial HTML does not yet contain these contents. Furthermore, there are sophisticated mechanisms that notice crawling and lock out crawlers. Likewise, it may be difficult to add data to the OSN. For security reasons, in most cases, special tokens are sent along with each request to detect and prevent abuse and fake requests.
+	\item \textbf{Development, operation and licensing costs}: Costs for the development, operation and licensing of third-party software may incurred. At best, the costs can be avoided by conscious decisions.
+	\item \textbf{Operating system or runtime environment}: Nowadays OSNs can be used on almost all devices; independent of their operating system. In order to achieve the same user experience, the hybrid OSN should be usable on the same platforms. Any restrictions imposed by the operating system (user and application rights, connectivity, etc.) must be taken into account during development.
+	\item \textbf{Resources}: The devices running the hybrid OSN may have limited resources (storage space, processing power, Internet connection/data volume, battery). When making design decisions, it is important to plan as resource-conserving as possible and to find scalable solutions. Overall, the overhead for the hybrid extension should be as low as possible compared to the original application.
+	\item \textbf{Availability of data}: The data that is exchanged securely and not via the OSN's servers must always be available. Whether a user is offline or how old the data is must not affect its availability.
+\end{itemize}
+
+While the restrictions on the hybrid client itself can be actively influenced and resolved, the restrictions on the OSN cannot be controlled. If the OSN does not provide any interfaces and the hurdle of data exchange with the servers is insurmountable, this can completely prevent the development of a hybrid client.

thesis/content/04-concept/solution-strategy-architecture.tex

@@ -0,0 +1,81 @@
+Various models can be used to implement secure data exchange between the users of an OSN via an add-on. The solution strategies shown below differ essentially in the question of where data is stored and how it can be found.
+
+\begin{figure}[h!]
+	\centering
+	\includegraphics[width=1.0\textwidth]{solution-strategy-architecture}
+	\caption{Different architectures: a) Use of a central server to which all hybrid OSN users connect to, b) Creation of a P2P network among the users for data exchange.}
+	\label{fig:solution-strategy-architecture}
+\end{figure}
+
+One possibility is to use an extra infrastructure to store the data, as shown in Figure \ref{fig:solution-strategy-architecture}.a. Additional servers are used to store and distribute the private data to be protected. This has the advantage that the data is always available and there are no dependencies to other hybrid OSN users. Furthermore, resources must only be available centrally and not locally for every user. At the central location the data can be indexed and specifically queried. However, it is problematic that one or more such servers must be operated and maintained. In principle, the question of the operators must be clarified, because the infrastructure must function reliably. An architecture based on this proposal was used by FaceCloak.
+
+In contrast, a decentralized or distributed solution strategy would create a network among users of the hybrid application. This strategy is depicted in Figure \ref{fig:solution-strategy-architecture}.b. No extra infrastructure would have to be operated. The users would then have a classic peer role. With this model, solutions must be found for how data is always available and can be found, even if a user is temporarily or permanently offline. Furthermore, the resources on the end devices are limited, so that effective, economical solutions are needed. Another challenge is the addressing of peers. Since they typically do not have a static IP address, but the IP address changes frequently, solutions must be found for accessibility. Since there is no central, global index, finding data is even more difficult.
+
+An interim solution is also conceivable, in which an existing infrastructure, e.g. an already existing P2P network or the block chain, is used for storing and exchanging data. Since no influence can be exerted on an existing infrastructure, its use entails further restrictions and potential risks.
+
+The advantages and disadvantages of the different strategies are listed in Table \ref{tab:solution-strategy-architecture-comparison} below.
+
+% Own infrastructure
+\newcommand{\advantageoi}{\begin{minipage} [t] {0.3\textwidth} 
+		\begin{itemize}
+			\item Availability of data
+			\item Finding the data
+			\item Resources only have to be available centrally
+			\item No dependencies among hybrid OSN users
+		\end{itemize}
+		\hspace{1mm}
+\end{minipage}}
+
+\newcommand{\disadvantageoi}{\begin{minipage} [t] {0.3\textwidth} 
+		\begin{itemize}
+			\item expenses
+			\item Who operates the infrastructure?
+		\end{itemize}
+\end{minipage}}
+
+% Own network
+\newcommand{\advantageon}{\begin{minipage} [t] {0.3\textwidth} 
+		\begin{itemize}
+			\item Resources scale with increasing number of users
+		\end{itemize}
+\end{minipage}}
+
+\newcommand{\disadvantageon}{\begin{minipage} [t] {0.3\textwidth} 
+		\begin{itemize}
+			\item Availability of data
+			\item Finding the data
+			\item Addressing the peers
+			\item Local resources limited
+		\end{itemize}
+		\hspace{1mm}
+\end{minipage}}
+
+% External infrastructure
+\newcommand{\advantageei}{\begin{minipage} [t] {0.3\textwidth} 
+		\begin{itemize}
+			\item Ideally no costs
+			\item Resources are provided by the external infrastructure
+		\end{itemize} 
+\end{minipage}}
+
+\newcommand{\disadvantageei}{\begin{minipage} [t] {0.3\textwidth} 
+		\begin{itemize}
+			\item No influence on future development
+			\item Dependence on infrastructure entails risks
+		\end{itemize}
+		\hspace{1mm}
+\end{minipage}}
+
+
+\begin{table}[h!]
+	\centering
+	\begin{tabular}{l|l|l|}
+		\cline{2-3}
+		& \textbf{Advantages} & \textbf{Disadvantages} \\ \hline
+		\multicolumn{1}{|l|}{\textbf{\begin{tabular}[c]{@{}l@{}}Own infrastructure\\ (centralized)\end{tabular}}}        & \advantageoi                    & \disadvantageoi                       \\ \hline
+		\multicolumn{1}{|l|}{\textbf{\begin{tabular}[c]{@{}l@{}}Own network\\ (decentralized/distributed)\end{tabular}}} & \advantageon                    & \disadvantageon                       \\ \hline
+		\multicolumn{1}{|l|}{\textbf{External infrastructure}}                                                           & \advantageei                    & \disadvantageei                       \\ \hline
+	\end{tabular}
+	\caption{Advantages and disadvantages of the different solution strategies for the hybrid OSN architecture.}
+	\label{tab:solution-strategy-architecture-comparison}
+\end{table}

thesis/content/04-concept/solution-strategy-client.tex

@@ -0,0 +1,7 @@
+With regard to the implementation of the hybrid approach, two possibilities are conceivable. On the one hand, the extension of the original OSN client (app or web front end) as an addon. On the other hand, the development of a completely new client.
+
+When the OSN is extended by an addon, the conventional functionality of the OSN does not have to be taken care of. Therefore, the development can be completely focused on the addon. At crucial points, the addon ensures that the interface is extended by additional elements that enable secure data exchange. The service providers usually do not offer developers an interface to extend the OSN with such own functionalities. With web front ends it is possible to manipulate the website content using browser add-ons. One example for doing so is FaceCloak. Since such browser extensions manipulate the Document Object Model (DOM), knowledge about the document structure is necessary for the successful function in order to make changes in the right places. The short release cycles of OSNs and the associated frequent changes to this DOM structure make it difficult to keep up with the changes. When consuming the OSN via the official apps on mobile devices, an extension or manipulation is not possible.
+
+The alternative to the extension approach described above is an extra hybrid client app. The entire functional range of the OSN must be implemented and kept up to date. As already mentioned with the restrictions, the functions are usually not provided completely via an API and the crawling of the content also brings with it some challenges. By having complete control over the development, the additional protected, secure communication can be added at the appropriate points. In the best-case scenario, at least one hybrid app is available for every operating system for which an official OSN app exists.
+
+Both approaches can be combined by displaying the (mobile) web page of the OSN in a WebView in a separate app and executing DOM manipulations via injected JavaScript code. For example, there are some alternative clients for Facebook (e.g. \enquote{Friendly for Facebook}\footnote{https://play.google.com/store/apps/details?id=io.friendly} \footnote{https://itunes.apple.com/de/app/friendly-for-facebook/id400169658}, \enquote{Metal Pro}\footnote{https://play.google.com/store/apps/details?id=com.nam.fbwrapper.pro}) that use this approach.

thesis/content/04-concept/stakeholders.tex

@@ -0,0 +1,127 @@
+Even if the stakeholders are not necessarily directly involved, it is still important to understand the views and interests of the various parties and take them into account in the design. Table \ref{tab:steakholders} shows the interests and points of view of the parties involved directly and indirectly.
+
+% Interests
+\newcommand{\interestsSP}{\begin{minipage} [t] {0.4\textwidth} 
+		\begin{itemize}
+			\item Collect as much user data as possible
+			\item Binding users to the platform
+			\item Profit maximization 
+		\end{itemize}
+\end{minipage}}
+
+\newcommand{\interestsOSN}{\begin{minipage} [t] {0.4\textwidth} 
+		\begin{itemize}
+			\item Unrestricted use of the OSN
+			\item No disadvantages due to hybrid OSN users 
+		\end{itemize}
+\end{minipage}}
+
+\newcommand{\interestsHOSN}{\begin{minipage} [t] {0.4\textwidth} 
+		\begin{itemize}
+			\item Unrestricted use of the OSN
+			\item Decision-making sovereignty over what happens with data 
+		\end{itemize}
+\end{minipage}}
+
+\newcommand{\interestsDevHOSN}{\begin{minipage} [t] {0.4\textwidth} 
+		\begin{itemize}
+			\item Scalable, secure, fast data exchange solution
+			\item No costs for infrastructure and development 
+		\end{itemize}
+\end{minipage}}
+
+\newcommand{\interestsGov}{\begin{minipage} [t] {0.4\textwidth} 
+		\begin{itemize}
+			\item Compliance with laws
+			\item Supervision
+			\item Censorship 
+		\end{itemize}
+\end{minipage}}
+
+
+% Attitude towards hybrid OSN
+\newcommand{\attitudeSP}{\begin{minipage} [t] {0.3\textwidth} 
+		\begin{itemize}
+			\item Negative, as undesirable
+		\end{itemize}
+\end{minipage}}
+
+\newcommand{\attitudeOSN}{\begin{minipage} [t] {0.3\textwidth} 
+		\begin{itemize}
+			\item Neutral
+		\end{itemize}
+\end{minipage}}
+
+\newcommand{\attitudeHOSN}{\begin{minipage} [t] {0.3\textwidth} 
+		\begin{itemize}
+			\item Positive, as desired
+		\end{itemize}
+\end{minipage}}
+
+\newcommand{\attitudeDevHOSN}{\begin{minipage} [t] {0.3\textwidth} 
+		\begin{itemize}
+			\item Positive
+		\end{itemize}
+\end{minipage}}
+
+\newcommand{\attitudeGov}{\begin{minipage} [t] {0.3\textwidth} 
+		\begin{itemize}
+			\item Depending on policy and legislation
+			\item At best, positive and supportive
+			\item In the worst case, negative and preventing
+		\end{itemize}
+\end{minipage}}
+
+%Influence on hybrid OSN
+\newcommand{\influenceSP}{\begin{minipage} [t] {0.4\textwidth} 
+		\begin{itemize}
+			\item No direct influence on the development of the hybrid solution
+			\item By identification of the hybrid OSN users their exclusion
+			\item Blocking the hybrid OSN
+			\item Great influence			
+		\end{itemize}
+\end{minipage}}
+
+\newcommand{\influenceOSN}{\begin{minipage} [t] {0.4\textwidth} 
+		\begin{itemize}
+			\item No influence
+		\end{itemize}
+\end{minipage}}
+
+\newcommand{\influenceHOSN}{\begin{minipage} [t] {0.4\textwidth} 
+		\begin{itemize}
+			\item Feedback for improvement
+			\item Low influence 
+		\end{itemize}
+\end{minipage}}
+
+\newcommand{\influenceDevHOSN}{\begin{minipage} [t] {0.4\textwidth} 
+		\begin{itemize}
+			\item Great influence, since decision-making sovereignty
+		\end{itemize}
+\end{minipage}}
+
+\newcommand{\influenceGov}{\begin{minipage} [t] {0.4\textwidth} 
+		\begin{itemize}
+			\item At best, promotion and financial support - great influence
+			\item In the worst case legal action - great influence
+			\item No other influence 
+		\end{itemize}
+\end{minipage}}
+
+\begin{landscape}
+	\begin{table}[h!]
+		\centering
+		\begin{tabular}{|l|l|l|l|}
+			\hline
+			\textbf{Steakholder}                                           & \textbf{Interests} & \textbf{Attitude towards hybrid OSN} & \textbf{Influence on hybrid OSN} \\ \hline
+			\begin{tabular}[c]{@{}l@{}}Service\\ Provider\end{tabular}     & \interestsSP       & \attitudeSP                          & \influenceSP                     \\ \hline
+			\begin{tabular}[c]{@{}l@{}}OSN\\ User\end{tabular}             & \interestsOSN      & \attitudeOSN                         & \influenceOSN                    \\ \hline
+			\begin{tabular}[c]{@{}l@{}}Hybrid\\ OSN User\end{tabular}      & \interestsHOSN     & \attitudeHOSN                        & \influenceHOSN                   \\ \hline
+			\begin{tabular}[c]{@{}l@{}}Developer\\ hybrid OSN\end{tabular} & \interestsDevHOSN  & \attitudeDevHOSN                     & \influenceDevHOSN                \\ \hline
+			Governments                                                    & \interestsGov      & \attitudeGov                         & \influenceGov                    \\ \hline
+		\end{tabular}
+		\caption{Interests, attitude towards a hybrid solution and influence on the hybrid solution of several stakeholders.}
+		\label{tab:steakholders}
+	\end{table}
+\end{landscape}

thesis/header.tex

@@ -28,6 +28,7 @@
 \usepackage{wrapfig}
 \usepackage{blindtext}
 \usepackage{csquotes}
+\usepackage{lscape}
 
 % llt: Define a global style for URLs, rather that the default one
 \makeatletter