replace misused verb <develop>

thesis/content/00-abstract-en.tex

@@ -1,5 +1,5 @@
 Despite numerous scandals about data protection in established social networks (Facebook, Google+), the platforms still enjoy great popularity. Alternative social networks, which have focused on protecting the data of their users, lack attractiveness, so they regularly fail. If users remain loyal to social networks despite poor data protection, ways must be found to protect their data. A hybrid approach enables the natural use of the platform and uses another communication channel to exchange sensitive data.
 
-The goal of this work was to develop a concept for a hybrid social network and to validate it with a prototype. Within the scope of the concept, the interests of the stakeholders were identified, and requirements for the hybrid solution were defined. For the implementation, we mentioned concrete solution strategies for architecture and client. The prototype was created as an Android app for Twitter. The IPFS protocol for decentralized data storage in combination with the distributed GUN database was used for secure data exchange.
+The goal of this work was to work out a concept for a hybrid social network and to validate it with a prototype. Within the scope of the concept, the interests of the stakeholders were identified, and requirements for the hybrid solution were defined. For the implementation, we mentioned concrete solution strategies for architecture and client. The prototype was created as an Android app for Twitter. The IPFS protocol for decentralized data storage in combination with the distributed GUN database was used for secure data exchange.
 
 The result shows that the concept is implementable and that the defined goals lead to a high-quality solution. The Hybrid OSN prototype meets the previously defined requirements almost entirely. For Likes and Tweets, the user can decide which network should be used for data exchange with other users. The solution is user-friendly and requires minimal configuration effort.

thesis/content/02-background/dapps.tex

@@ -33,4 +33,4 @@ Examples of \acp{dApp} that use the Ethereum - \ac{IPFS} combination are the soc
 
 Among the disadvantages of \acp{dApp} are the costs associated with actions and the handling of tokens. The tokens are stored in a wallet, and this wallet has to be accessible by the \ac{dApp}. Therefore, a special web browser or an extra browser add-on is required. Before the first usage, the user has to obtain the token somehow. The acquisition is usually complex and therefore represents a barrier for some users to use the application. Because of this, unfortunately, only experienced users can fulfill the prerequisites to use a \ac{dApp}.
 
-The advantages of a \ac{dApp} include not only reliability but also the avoidance of censorship and manipulation by design. Furthermore, there are no dependencies towards a service provider. However, the development of a \ac{dApp} is complex and it is difficult to install updates and bugfixes. Currently, there are still very few \acp{dApp}, so interactions between different \acp{dApp} are not able to create synergy effects.
+The advantages of a \ac{dApp} include not only reliability but also the avoidance of censorship and manipulation by design. Furthermore, there are no dependencies towards a service provider. However, the creation of a \ac{dApp} is complex and it is difficult to install updates and bugfixes. Currently, there are still very few \acp{dApp}, so interactions between different \acp{dApp} are not able to create synergy effects.

thesis/content/03-related-work/akasha.tex

@@ -4,7 +4,7 @@ Alisie sees AKASHA as \enquote{the missing puzzle piece that will enable us to t
 
 AKASHA offers the typical functionalities known from other social networks. These include creating a profile and connect with other profiles. Posting content and commenting on other entries. Furthermore, there is a message system and the possibility to tip other users. Instead of a central server, AKASHA uses the Ethereum testnet Rinkeby and \ac{IPFS} to store data, so AKASHA can be called a \ac{dApp}. The messaging system is implemented via Whisper. \ac{ETH} is required to execute all actions in order to write to the blockchain, but this can be easily requested in the test network.
 
-After a proof of concept had validated the idea, the technology stack mentioned above was defined, and development began at the beginning of 2016. The first goal was to develop a client based on Electron for Windows, Linux, and MacOS. In January 2017, the first functional alpha version was completed and tested with a closed circle of users. Over time, additional functions were added, bugs fixed, and performance optimized. In November 2017, a web version of AKASHA\footnote{https://beta.akasha.world/} was introduced. This was a big step towards a better user experience since the web client does not need to download the Ethereum Rinkeby blockchain which took around 30\,minutes on the first run. But, the web version only works in browsers running MetaMask and \ac{IPFS} Companion extensions. The public beta phase started in February 2018 with the primary goal to see how the application behaves under heavy load.
+After a proof of concept had validated the idea, the technology stack mentioned above was defined, and development began at the beginning of 2016. The first goal was to create a client based on Electron for Windows, Linux, and MacOS. In January 2017, the first functional alpha version was completed and tested with a closed circle of users. Over time, additional functions were added, bugs fixed, and performance optimized. In November 2017, a web version of AKASHA\footnote{https://beta.akasha.world/} was introduced. This was a big step towards a better user experience since the web client does not need to download the Ethereum Rinkeby blockchain which took around 30\,minutes on the first run. But, the web version only works in browsers running MetaMask and \ac{IPFS} Companion extensions. The public beta phase started in February 2018 with the primary goal to see how the application behaves under heavy load.
 
 With the announcement of the web version, the team behind AKASHA also introduced their own AETH token. This token has the unique feature that it can take different states. By locking AETH, the user receives \textit{Mana} which regenerates every day as long as the AETH remains locked. Performing interactions, for example liking, commenting or publishing posts, consumes \textit{Mana} and \ac{ETH}, but not AETH. When \textit{Mana} is used to vote for something, the content's author receives the same amount as \textit{Essence} which can be converted into new AETH tokens. The third state is called \textit{Karma} and functions as a all time score of received \textit{Essence} even though it has been used to mint AETH. \textit{Karma} is necessary to unlock new features inside AKASHA. \cite{akasha2017horizons}
 

thesis/content/03-related-work/diaspora.tex

@@ -6,7 +6,7 @@ Inspired by a lecture on surveillance in centralized social networks by Eben Mog
 	\item \textbf{Open Source}: The source code is disclosed and hosted on GitHub\footnote{https://github.com/diaspora/diaspora}. The transparency created in this way ensures trust in diaspora*.
 \end{itemize}
 
-For funding the development of diaspora*, \$ 10\,000 should be crowdfunded on Kickstarter\footnote{https://www.kickstarter.com/projects/mbs348/diaspora-the-personally-controlled-do-it-all-distr/description}. The project was very well received so that after 14 days the target was reached \cite{diaspora2010wemadeit} and in the end, a total of \$ 200\,641 was donated. In November 2010, the first alpha version of diaspora* was released. One year later there was a prominent feature update. In May 2012 it was announced that diaspora* should be further developed within the Y Combinator start-up program\cite{diaspora2012y-combinator}. Due to the commercial influence, there were fears that diaspora* could lose its independence. In August 2012, the developers announced that diaspora* is henceforth a community project \cite{diaspora2012community-announcement}.
+For funding the development of diaspora*, \$ 10\,000 should be crowdfunded on Kickstarter\footnote{https://www.kickstarter.com/projects/mbs348/diaspora-the-personally-controlled-do-it-all-distr/description}. The project was very well received so that after 14 days the target was reached \cite{diaspora2010wemadeit} and in the end, a total of \$ 200\,641 was donated. In November 2010, the first alpha version of diaspora* was released. One year later there was a prominent feature update. In May 2012 it was announced that the diaspora* development should be continued within the Y Combinator start-up program\cite{diaspora2012y-combinator}. Due to the commercial influence, there were fears that diaspora* could lose its independence. In August 2012, the developers announced that diaspora* is henceforth a community project \cite{diaspora2012community-announcement}.
 
 The diaspora* back end is written in Ruby, the front end to the user is a website. A server running diaspora* is called pod. Each pod has its own domain, so users of a pod have a username similar to an e-mail address (for example, username@podname.org). Diaspora* has the typical functionalities of a social network (hashtags, @ mentions, likes, comments, private messages). What marked a peculiarity at the time of diaspora*'s appearance are so-called aspects. Aspects are groupings of contacts that can be specified as a target audience when posting content. Only the contacts associated with the aspect can see the post.
 

thesis/content/03-related-work/facecloak.tex

@@ -1,4 +1,4 @@
-Researchers Luo, Xiu, and Hengartner of the University of Waterloo in Ontario propose an architecture to protect personal information on social networking platforms \cite{luo2009facecloak}. Protection is achieved by transmitting fake data to the social network server and storing the correct data encrypted on a third party server. Authorized users can then replace the fake data with the correct data when they visit the site containing protected data. The prerequisite is that all users use a specific browser extension that communicates with the third party server and replaces content. In concrete terms, this was implemented for Facebook and both a server and an extension for the Firefox browser were developed and successfully tested.
+Researchers Luo, Xiu, and Hengartner of the University of Waterloo in Ontario propose an architecture to protect personal information on social networking platforms \cite{luo2009facecloak}. Protection is achieved by transmitting fake data to the social network server and storing the correct data encrypted on a third party server. Authorized users can then replace the fake data with the correct data when they visit the site containing protected data. The prerequisite is that all users use a specific browser extension that communicates with the third party server and replaces content. In concrete terms, this was implemented for Facebook and both a server and an extension for the Firefox browser were created and successfully tested.
 
 \subsubsection{Design Principles}
 FaceCloak's design is based on the following four principles:
@@ -31,7 +31,7 @@ In addition to adhering to the above design principles, the proposed architectur
 \end{itemize}
 
 \subsubsection{FaceCloak for Facebook}
-To protect the privacy of Facebook users, Luo, Xiu, and Hengartner have developed a Firefox browser extension according to the previously described architecture, as well as a server application for storing encrypted real data \cite{facecloakXXXXdownload}.
+To protect the privacy of Facebook users, Luo, Xiu, and Hengartner have created a Firefox browser extension according to the previously described architecture, as well as a server application for storing encrypted real data \cite{facecloakXXXXdownload}.
 
 The extension uses \ac{AES} and a key length of 128 bits to encrypt the data. The indices for the encrypted data are calculated using SHA-1. The authors propose an e-mail for the key exchange. For this purpose, the browser extension automatically generates e-mail texts and recipient lists and forwards them to the standard e-mail program. The recipients then have to store the received keys in the extension manually.
 

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

@@ -46,7 +46,7 @@ As proof of concept, Daubert et al. implemented Twitterize as an app for Android
 
 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 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 are enough to form a group.
+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.
 

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

@@ -1,4 +1,4 @@
-Concerning the implementation of the hybrid approach, two possibilities are conceivable. On the one hand, the extension of the original \ac{OSN} client (app or web front end) as an add-on. On the other hand, the development of an entirely new client.
+Concerning the implementation of the hybrid approach, two possibilities are conceivable. On the one hand, the extension of the original \ac{OSN} client (app or web front end) as an add-on. On the other hand, the creation of an entirely new client.
 
 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 \ac{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.
 

thesis/content/06-discussion/achievement.tex

@@ -31,7 +31,7 @@ An alternative to the implementation in Hybrid \ac{OSN} would be to encrypt data
 The flexibility of GUN and the \ac{JSON} data format allow effective data storage. The established structures can also be easily adapted for future requirements. Due to the immutability of the data stored in \ac{IPFS}, it is not possible to retroactively change the data structure. Should this nevertheless be necessary, the changes would have to be implemented in the program logic. However, the requirement must be regarded as fulfilled.
 
 \subsubsection{Platform Independence}
-The requirement for a platform-independent solution contradicts the actual requirement to develop an Android client. Nevertheless, the requirement was taken into account in the decisions made. The targeted selection of the Ionic framework laid the basis for platform independence. Even though Ionic was primarily used to create an Android application within the scope of this work, it should be possible to use the same code with some effort to create an app for iOS or a \ac{PWA}. Since Twitter can be used on almost all platforms up to the feature phone, the idealistic goal of creating a similar client variety is almost utopian. Taking all that into account, the requirement is therefore only partially fulfilled.
+The requirement for a platform-independent solution contradicts the actual requirement to create an Android client. Nevertheless, the requirement was taken into account in the decisions made. The targeted selection of the Ionic framework laid the basis for platform independence. Even though Ionic was primarily used to create an Android application within the scope of this work, it should be possible to use the same code with some effort to create an app for iOS or a \ac{PWA}. Since Twitter can be used on almost all platforms up to the feature phone, the idealistic goal of creating a similar client variety is almost utopian. Taking all that into account, the requirement is therefore only partially fulfilled.
 
 \subsubsection{Anonymized Data for the Service Provider}
 Anonymous data from the private network should be shared with Twitter to prevent the service provider's business model from failing. Approximately 87\% (\$\,791 million) of Twitter's revenues in the fourth quarter 2018 were generated by advertisements \cite{twitter2019reportq4}. Thus, the central pillar of Twitter's business model is personalized advertising. Accordingly, data should be of particular interest for Twitter if it is related to a person. Only if Twitter gains knowledge about a user, this knowledge can be used to place targeted advertisements. However, it is precisely this connection between data and user that should be avoided by using Hybrid \ac{OSN}.