Feedback Aidmar

thesis/bib/bibliography.bib

@@ -461,4 +461,12 @@
   year    = {2014},
 }
 
+@Misc{google2017twitter-mobile,
+  title        = {{Twitter Lite PWA Significantly Increases Engagement and Reduces Data Usage}},
+  howpublished = {\url{https://developers.google.com/web/showcase/2017/twitter}},
+  month        = may,
+  year         = {2017},
+  note         = {Online, accessed 22.03.2019},
+}
+
 @Comment{jabref-meta: databaseType:bibtex;}

thesis/content/04-concept/restrictions.tex

@@ -1,11 +1,11 @@
 When designing the hybrid \ac{OSN}, there are a few limitations that need to be considered, for which appropriate solutions have to be found. These restrictions include:
 
 \begin{itemize}
-	\item \textbf{Interfaces of the \ac{OSN}}: Ideally the \ac{OSN} offers a public \ac{API} with full functionality. Since the user's data should be protected as best as possible, access via the \ac{API} is usually restricted. The restriction may be due to a limited number of requests per time interval or a limited range of offered functions.
+	\item \textbf{\ac{API} of the \ac{OSN}}: Ideally the \ac{OSN} offers a public \ac{API} with full functionality. An API consists of multiple endpoints that can be used to retrieve, add, or modify specific data. Since the user's data should be protected as best as possible, access via the \ac{API} is usually restricted. The restriction may be due to a limited number of requests per time interval or a limited range of offered functions.
 	\item \textbf{Crawling the \ac{OSN} web pages}: If there is no official \ac{API} or if it is sharply 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 \ac{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 \ac{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, conscious decisions lead to the avoidance of expenses.
-	\item \textbf{Operating system or runtime environment}: Nowadays \acp{OSN} can be used on almost all devices; independent of their operating system. In order to achieve the same user experience, the hybrid \ac{OSN} should be usable on the same platforms. Any restrictions imposed by the operating system (user and application rights, connectivity) must be taken into account during development.
-	\item \textbf{Resources}: The devices running the hybrid \ac{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{Operating system or runtime environment}: Nowadays \acp{OSN} can be used on almost all devices; independent of their operating system. In order to achieve the same user experience, the hybrid \ac{OSN} should be usable on the same variety of operating systems. Any restrictions imposed by the operating system (user and application rights, connectivity) must be taken into account during development.
+	\item \textbf{Resources}: The mostly mobile devices (Twittter is used by more than 80\% of users on mobile \cite{google2017twitter-mobile}) running the hybrid \ac{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 \ac{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}
 

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

@@ -2,6 +2,7 @@ Concerning the implementation of the hybrid approach, two possibilities are conc
 
 When an add-on extends the \ac{OSN}, there is no need to take care of the standard functionality of the \ac{OSN}. Therefore, the development can entirely focus on the add-on and the private extension. At crucial points, the add-on extends the interface 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 \ac{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 \acp{OSN} and the associated frequent changes to this \ac{DOM} structure make it difficult to keep up with the changes. When consuming the \ac{OSN} via the official apps on mobile devices, an extension or manipulation is not possible.
 
-The alternative to the extension approach described above is a new hybrid client app. The entire functional range of the \ac{OSN} must be implemented and kept up to date. As already mentioned with the restrictions (see \ref{sec:requirements}), the functions are usually not entirely provided via an \ac{API}, and the crawling of the content also brings with it some challenges. By having complete control over the development of the client, 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 \ac{OSN} app exists.
+The alternative to the extension approach described above is a new hybrid client app. The entire functional range of the \ac{OSN} must be implemented and kept up to date. As already mentioned with the restrictions (see Chapter \ref{sec:requirements}), the functions are usually not entirely provided via an \ac{API}, and the crawling of the content 
+confronts several challenges. By having complete control over the development of the client, 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 \ac{OSN} app exists.
 
 Both approaches can be combined by displaying the (mobile) web page of the \ac{OSN} in a WebView in a separate app and executing \ac{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/05-proof-of-concept/introduction.tex

@@ -1 +1 @@
-After working out the concept of a hybrid \ac{OSN} in the previous chapter \ref{ch:concept}, this chapter presents a proof of concept in the form of an individual Twitter client for Android. The previously described solution strategies, as well as functional and non-functional requirements, actively influenced the development of the client, and attention was also paid to compliance with the defined quality goals. In the following, the decisions made are explained, and the resulting architecture is presented.
+After working out the concept of a hybrid \ac{OSN} in the previous Chapter \ref{ch:concept}, this chapter presents a proof of concept in the form of an individual Twitter client for Android. The previously described solution strategies, as well as functional and non-functional requirements, actively influenced the development of the client. Attention was also spend on compliance with the defined quality goals. In the following, the decisions made are explained, and the resulting architecture is presented.

thesis/content/05-proof-of-concept/osn-selection.tex

@@ -1,4 +1,12 @@
-When selecting a suitable \ac{OSN} for the development of a hybrid client, Facebook was the obvious first choice due to the numerous negative headlines about data protection. With over 2.3 billion users per month (average Q4 2018), it is currently the most widely used social network in the world \cite{facebook2019reportq4}. In the recent past, it has often been criticized for its handling of its users' data. In particular, the scandal surrounding the data analysis company Cambridge Analytica, which had access to the data of up to 87 million users, hit Facebook hard \cite{facebook2018cambridge-analytica,facebook2018api-restriction}. As a result, CEO Mark Zuckerberg had to face the US Congress and the EU Parliament in question rounds and did not leave a good impression by avoiding many questions \cite{facebook2018us-congress,facebook2018eu-parliament}. As a result of this scandal, there were further restrictions to the Facebook \ac{API} \cite{facebook2018api-restriction}.
+To select a suitable \ac{OSN} for the development of a hybrid client, three factors were considered:
+
+\begin{enumerate}
+	\item the significance of the \ac{OSN},
+	\item the adequacy of data protection,
+	\item the \ac{API} functionality.
+\end{enumerate}
+
+Facebook was the obvious first choice due to the numerous negative headlines about data protection. With over 2.3 billion users per month (average Q4 2018), it is currently the most widely used social network in the world \cite{facebook2019reportq4}. In the recent past, it has often been criticized for its handling of its users' data. In particular, the scandal surrounding the data analysis company Cambridge Analytica, which had access to the data of up to 87 million users, hit Facebook hard \cite{facebook2018cambridge-analytica,facebook2018api-restriction}. As a result, CEO Mark Zuckerberg had to face the US Congress and the EU Parliament in question rounds and did not leave a good impression by avoiding many questions \cite{facebook2018us-congress,facebook2018eu-parliament}. As a result of this scandal, there were further restrictions to the Facebook \ac{API} \cite{facebook2018api-restriction}.
 
 However, the Facebook \ac{API} is not suitable for developing a new client. The functionalities provided by the \ac{API} offer the possibility to develop an app that can be used within Facebook, for example for a game. So, it is not possible to give a \enquote{Like} for a post through this \ac{API}, which is part of the core functionality of a Facebook client. As discussed in Chapter \ref{ch:concept}, it is possible to access the data through crawling. However, the constant and rapid development would make this an arduous undertaking. Facebook writes in a blog post that the code changes every few hours \cite{facebook2017release}. Therefore it is almost impossible to adjust the crawler fast enough and roll out the adjusted code.
 

thesis/content/05-proof-of-concept/technology-decisions.tex

@@ -7,7 +7,12 @@ In order to meet the requirements of the concept best, a detailed consideration
 
 \subsection{Creation of a \ac{P2P} Network}
 \label{sec:create-p2p-network}
-The advantage of having an extra \ac{P2P} network is that it is completely under control. Accordingly, it can be designed to fit exactly to the use case and require little or no compromise. However, setting up a \ac{P2P} network is a big challenge and some hurdles must be overcome. These challenges include peer discovery (how peers find each other), global data exchange over the Internet and data storage, and availability of the stored data. And of course, all these requirements must scale. It should work for \ac{P2P} networks with only a few peers and also for a few thousand or even more peers. Two approaches are conceivable here: the use of an established standard such as Wi-Fi Dircet and \ac{WebRTC} or the use of a library (e.g., Hive2Hive, Yjs) to create a dedicated \ac{P2P} network.
+The advantage of having an extra \ac{P2P} network is that it is completely under control. Accordingly, it can be designed to fit exactly to the use case and require little or no compromise. However, setting up a \ac{P2P} network is a big challenge and some hurdles must be overcome. These challenges include peer discovery (how peers find each other), global data exchange over the Internet and data storage, and availability of the stored data. And of course, all these requirements must scale. It should work for \ac{P2P} networks with only a few peers and also for a few thousand or even more peers. In the following, we discuss two options to create the P2P network:
+
+\begin{itemize}
+	\item The use of an established standard such as Wi-Fi Dircet and \ac{WebRTC}
+	\item The use of a library (e.g., Hive2Hive, Yjs) to create a dedicated \ac{P2P} network
+\end{itemize}
 
 \subsubsection{Wi-Fi Direct}
 \label{sec:wifi-direct}