solution-strategy-architecture.tex 4.8 KB

1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283
  1. Various models can be used to implement a secure data exchange between the users of an \ac{OSN} via an add-on. The solution strategies shown below differ primarily in the question of where data is stored and how it can be found.
  2. \begin{figure}[h!]
  3. \centering
  4. \includegraphics[width=1.0\textwidth]{solution-strategy-architecture}
  5. \caption{Different architectures: a) Use of a central server to which all hybrid \ac{OSN} users connect to, b) Creation of a P2P network among the users for data exchange.}
  6. \label{fig:solution-strategy-architecture}
  7. \end{figure}
  8. 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. Using additional servers has the advantage that the data is always available and there are no dependencies to other hybrid \ac{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 explicitly queried. However, the operation and maintenance of one or more such servers are problematic. 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.
  9. 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 typical 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.
  10. 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 \ac{IP} address, but the \ac{IP} address changes frequently, solutions must be found for accessibility. Since there is no central, global index, finding data is even more difficult.
  11. An interim solution is also conceivable, in which an existing infrastructure, e.g., an already existing \ac{P2P} network or the blockchain, is used for storing and exchanging data. Since no influence can be exerted on existing infrastructure, its use entails further restrictions and potential risks.
  12. Table \ref{tab:solution-strategy-architecture-comparison} lists the advantages and disadvantages of the different strategies.
  13. % Own infrastructure
  14. \newcommand{\advantageoi}{\begin{minipage} [t] {0.3\textwidth}
  15. \begin{itemize}
  16. \item Availability of data
  17. \item Finding the data
  18. \item Resources only have to be available centrally
  19. \item No dependencies among hybrid \ac{OSN} users
  20. \end{itemize}
  21. \hspace{1mm}
  22. \end{minipage}}
  23. \newcommand{\disadvantageoi}{\begin{minipage} [t] {0.3\textwidth}
  24. \begin{itemize}
  25. \item Expenses
  26. \item Who operates the infrastructure?
  27. \item Compliance with legal requirements
  28. \end{itemize}
  29. \end{minipage}}
  30. % Own network
  31. \newcommand{\advantageon}{\begin{minipage} [t] {0.3\textwidth}
  32. \begin{itemize}
  33. \item Resources scale with increasing number of users
  34. \end{itemize}
  35. \end{minipage}}
  36. \newcommand{\disadvantageon}{\begin{minipage} [t] {0.3\textwidth}
  37. \begin{itemize}
  38. \item Availability of data
  39. \item Finding the data
  40. \item Addressing the peers
  41. \item Local resources limited
  42. \end{itemize}
  43. \hspace{1mm}
  44. \end{minipage}}
  45. % External infrastructure
  46. \newcommand{\advantageei}{\begin{minipage} [t] {0.3\textwidth}
  47. \begin{itemize}
  48. \item Ideally no costs
  49. \item Resources are provided by the external infrastructure
  50. \end{itemize}
  51. \end{minipage}}
  52. \newcommand{\disadvantageei}{\begin{minipage} [t] {0.3\textwidth}
  53. \begin{itemize}
  54. \item No influence on future development
  55. \item Dependence on infrastructure entails risks
  56. \end{itemize}
  57. \hspace{1mm}
  58. \end{minipage}}
  59. \begin{table}[h!]
  60. \centering
  61. \begin{tabular}{l|l|l|}
  62. \cline{2-3}
  63. & \textbf{Advantages} & \textbf{Disadvantages} \\ \hline
  64. \multicolumn{1}{|l|}{\textbf{\begin{tabular}[c]{@{}l@{}}Own infrastructure\\ (centralized)\end{tabular}}} & \advantageoi & \disadvantageoi \\ \hline
  65. \multicolumn{1}{|l|}{\textbf{\begin{tabular}[c]{@{}l@{}}Own network\\ (decentralized/distributed)\end{tabular}}} & \advantageon & \disadvantageon \\ \hline
  66. \multicolumn{1}{|l|}{\textbf{External infrastructure}} & \advantageei & \disadvantageei \\ \hline
  67. \end{tabular}
  68. \caption{Advantages and disadvantages of the different solution strategies for the hybrid \ac{OSN} architecture.}
  69. \label{tab:solution-strategy-architecture-comparison}
  70. \end{table}