tex: update bits of theor. part

tex/part-theoretical.tex

@@ -330,7 +330,9 @@ able to rewrite the HTML content. The results of XSS can range from account
 compromise to identity theft~\cite{owasptop10}.
 
 Solutions deployed against XSS vary. On the client side, it mainly comes down
-to good browser patching hygiene, browser features such as Site Isolation (see
+to good browser patching hygiene and, of course, avoiding sketchy websites is
+always a recommended practice. The security of the user is also to a degree
+reliant on browser features such as Site Isolation (see
 Section~\ref{sec:siteisolation}), and essentially browsers correctly parsing
 website directives such as the \texttt{X-Frame-Options},
 \texttt{X-Content-Type-Options}, \texttt{X-Xss-Protection} and
@@ -339,7 +341,8 @@ flat if the website operators do not correctly configure their websites.
 
 On the server side though, these options (indicating to the browsers \emph{how}
 the site should be parsed) can directly be manipulated and configured. They
-should be fine-tuned to fit the needs of each specific website.
+should be fine-tuned to fit the needs of each specific website, as there is no
+one-size-fits-all in this case.
 
 Furthermore, a new, powerful and comprehensive framework for controlling the
 admissibility of content has been devised more than 10 years ago now: Content
@@ -359,12 +362,12 @@ websites exactly where the websites are being parsed and displayed - in the
 As per Weichselbaum et al.\ CSP is a mechanism designed to mitigate
 XSS~\cite{longliveCSP}, a long-lived king of the vulnerability
 lists~\cite{reininginCSP}. It is a declarative policy mechanism that allows the
-website operator to decide what client-side resources can load on their website and what origins
-are permitted \emph{sources} of content.
+website operator to decide what client-side resources can load on their website
+and what origins are among the permitted \emph{sources} of content.
 
-For example, scripts can be restricted to only load from a list of trusted
-domains, and inline scripts can be blocked entirely, which is a huge win
-against popular XSS techniques.
+For example, dynamic content such as scripts can be restricted to only load
+from a list of trusted domains, and inline scripts can be blocked entirely,
+which is a huge win against popular XSS techniques.
 
 Not only that, scripts and stylesheets can also be allowed based on a
 cryptographic (SHA256, SHA384 or SHA512) hash of their content, which should be
@@ -395,18 +398,16 @@ be set to \texttt{'none'}. CSP can also aid with clickjacking protection using
 its \texttt{frame-ancestors} directive, which can limit origins that have the
 permission to embed the website. This prevents the attacker from embedding the
 website at random places, for example malicious websites that masquerade as
-being legitimate, e.g.\ utilising `Log in using xyz service' frame, that in
-actuality just pharms the credentials.
+being legitimate, e.g.\ utilising `Log in using service Xyz' frame, that in
+actuality just \emph{pharms} the credentials.
 
-Getting CSP right can be tricky at first but once grokked, it is relatively
-straight-forward and can increase the security of the site greatly.
-
-The recommended way to \emph{test} CSP is to enable it in the
+Getting CSP right can be tricky depending on the nature of the site, but once
+grokked, it is relatively straight-forward and can increase the security of the
+site greatly. The recommended way to \emph{test} CSP is to enable it in the
 \emph{report-only} mode before turning it on in production.
 
-There are many more directives and settings than mentioned in this section, the
-author encourages anybody interested to give it a read, e.g.\ at
-\url{https://web.dev/csp/}.
+CSP contains many more directives than could be mentioned in this section.
+Anybody interested is encouraged to have a read at \url{https://web.dev/csp/}.
 
 
 \n{1}{Configuration}