tex: reword, rm bits in pract.

tex/part-practical.tex

@@ -185,9 +185,9 @@ kernel version 6.\{2,3,4\}.x.
 \n{2}{Source code repositories}\label{sec:repos}
 
 The git repository containing source code of the \texttt{pcmt} project:\\
-\url{https://git.dotya.ml/mirre-mt/pcmt.git}.
+\url{https://git.dotya.ml/mirre-mt/pcmt.git}.\\
 The git repository hosting the \texttt{pcmt} configuration schema:\\
-\url{https://git.dotya.ml/mirre-mt/pcmt-config-schema.git}.
+\url{https://git.dotya.ml/mirre-mt/pcmt-config-schema.git}.\\
 The repository containing the \LaTeX{} source code of this thesis:\\
 \url{https://git.dotya.ml/mirre-mt/masters-thesis.git}.
 
@@ -558,9 +558,10 @@ sorts, as there would be nothing preventing the newly-\emph{admined} user from
 disabling the accounts of all other administrators.
 
 
-\n{2}{Zero trust principle}
+\n{2}{Zero trust principle and confidentiality}
 
-\textit{Confidentiality, i.e.\ not trusting the provider}
+The program only sets generic titles (Settings, Home, Search) and thus foregoes
+disclosing information that would make it to browsers history.
 
 There is no way for the application (and consequently, the in-application
 administrator) to read user's data (such as saved search queries). This is
@@ -570,7 +571,7 @@ X25519)~\cite{age},~\cite{x25519rfc7748}. The \texttt{age} \emph{identity}
 itself is in turn encrypted by a passphrase that only the user controls. Of
 course, the user-supplied password is run by a password based key derivation
 function (\texttt{argon2}, version \emph{id} with the officially {recommended}
-configuration parameters) before letting it encrypt the \emph{age} key.
+configuration parameters) before letting it encrypt \emph{anything}.
 
 The \texttt{age} identity is only generated once the user changes their
 password for the first time, in an attempt to prevent scenarios like the
@@ -586,19 +587,23 @@ Of course, the supposed evil administrator could simply perform the password
 change themselves! However, the user would at least be able to find those
 changes in the activity logs and know to \emph{not} use the application under
 such circumstances. But given the scenario of a total database compromise, the
-author finds that all hope is \emph{already} lost at that point. At least when
-the database is dumped, it should only contain non-sensitive, functional
-information in plain text, everything else should be encrypted.
+author finds that all hope is \emph{already} lost at that point (similar to
+physical access to a computer). At least when the database is dumped, it should
+only contain non-sensitive, functional information in plain text, everything
+else should be encrypted.
 
 Consequently, both the application operators and the in-application
-administrators should ideally never be able to learn the details of what the
-user is tracking/searching for, the same being by extension applicable even to
-potential attackers with direct access to the database. Thus, the author
-maintains that every scenario that could potentially lead to a data breach
-(apart from a compromised actual user password) would have to entail some form
-of operating memory acquisition on the machine hosting the application, for
-instance using \texttt{LiME}~\cite{lime}, or perhaps directly the
-\emph{hypervisor}, if considering a virtualised (``cloud'') environments.
+administrators should never be able to learn the details of what the user is
+searching for, the same being by extension partly applicable even to potential
+attackers with direct access to the database. Thus, the author maintains that a
+scenario, which could potentially lead to a breach (apart from a compromised
+actual password) would have to entail some form of operating memory acquisition
+on the machine hosting the application, for instance using
+\texttt{LiME}~\cite{lime}, or perhaps directly the \emph{hypervisor}, if
+considering a virtualised (``cloud'') environments. Alternatively, all but one
+(memory acquisition) of the above issues could perhaps be remedied by simply
+not storing any user queries, turning off informative logging, and only letting
+the program be mediate the data sources.
 
 
 \n{1}{Implementation}
@@ -893,11 +898,11 @@ label=entQuery,
 backgroundcolor=\color{lstbg},
 language=Go,
 ]
-one, err := users.Query.
-	Where(
-		LocalBreach.
-		Has(Field_xyz)
-	).
+descr, err := users.Query().
+	Where().
+	LocalBreach.
+	Has(BreachDetailXyz).
+	Has(Description).
 	Only(ctx)
 \end{lstlisting}
 
@@ -905,10 +910,11 @@ one, err := users.Query.
 
 \n{1}{Deployment}
 
-A deployment setup as suggested in Section~\ref{sec:deploymentRecommendations}
-is already \emph{partially} covered by the multi-stage \texttt{Containerfile}
-that is available in the main sources. Once built, the resulting container
-image only contains a handful of things it absolutely needs:
+A deployment set-up, as suggested in
+Section~\ref{sec:deploymentRecommendations}, is already \emph{partially}
+covered by the multi-stage \texttt{Containerfile} that is available in the main
+sources. Once built, the resulting container image only contains a handful of
+things it absolutely needs:
 
 \begin{itemize}
   \item a self-contained statically linked copy of the program
@@ -1403,14 +1409,6 @@ for the main domain (\texttt{dotya.ml}) including the subdomains quite some
 time ago (consult the preload lists in Firefox/Chrome), which mandates that
 clients speaking HTTP only ever connect to it (and the subdomains) using TLS.
 
-The whole deployment has been orchestrated using an Ansible\footnotemark{}
-playbook created for this occasion, focusing on idempotence with the aim of
-reliably automating the deployment process. At the same time, it is now
-described reasonably well in the code. Its code is available at
-\url{https://git.dotya.ml/mirre-mt/ansible-pcmt.git}.
-
-\footnotetext{A Nix-ops approach was considered, however, Ansible was deemed
-more suitable since the existing host runs Arch.}
 
 
 \n{3}{Deployment validation}