tex: add stuff on data integrity and authenticity

tex/text.tex

@@ -566,14 +566,46 @@ possible besides what the application absolutely requires.
 
 \n{1}{Application architecture}
 
-\n{2}{Data integrity}
-TODO.
+\n{2}{Data integrity and authenticity}
 
-\n{2}{Data authenticity}
-TODO.
+The user can interact with the application via a web client, such as a browser,
+and is required to authenticate for all sensitive operations. To not only know
+\emph{who} the user is but also make sure they are \emph{permitted} to perform
+the action they are attempting, the program employs an \emph{authorisation}
+mechanism in the form of sessions. These are on the client side represented by
+cryptographically signed and encrypted (using 256 bit AES) cookies. That lays
+foundations for a few things: the data saved into the cookies can be regarded
+as private because short of future \emph{quantum computers} only the program
+itself can decrypt and access the data, and the data can be trusted since it is
+both signed using the key that only the program controls and \emph{encrypted}
+with \emph{another} key that equally only the program holds.
+
+The cookie data is only ever written \emph{or} read at the server side,
+solidifying the authors decision to let it be encrypted, as there is not point
+in not encrypting it for some perceived client-side simplification. Users
+navigating the website send their session cookie in \textbf{every request} (if
+it exists) to the server, which then verifies the integrity of the data and in
+case its valid, determines the existence and potential amount of user privilege
+that should be granted. Public endpoints do not mandate the presence of a valid
+session by definition, while at protected endpoints the user is authenticated
+at every request. When a session expires or if there is no session to begin
+with, the user is either shown a \emph{Not found} error message, the
+\emph{Unauthorised} error message or redirected to \texttt{/signin}.
+
+Another aspect that contributes to data integrity from another point of view is
+utilising database \emph{transactions} for bundling together multiple database
+operations that collectively change the \emph{state}. Using the transactional
+jargon, the data is only \emph{committed} if each individual change was
+successful. In case of any errors, the database is instructed to perform an
+atomic \emph{rollback}, which brings it back to a state before the changes were
+ever attempted.
+
+The author has additionally considered the thought of utilising an embedded
+immutable database like immudb (\url{https://immudb.io}) for record keeping
+(verifiably storing data change history) and additional data integrity checks,
+e.g.\ for tamper protection purposes and similar, however, that work remains
+yet to be materialised.
 
-\n{2}{Data confidentiality}
-At rest, only decrypted in memory when correct app key provided.
 
 \n{2}{Transport security}
 User connecting to the application should rightfully expect for their data to