diff --git a/tex/references.bib b/tex/references.bib
index 41f7a7f..38f81b3 100644
--- a/tex/references.bib
+++ b/tex/references.bib
@@ -343,4 +343,13 @@ institution = {International Organization for Standardization}
 	isbn = {978-1593278267},
 }
 
+@inproceedings{longliveCSP,
+	title = {{CSP Is Dead, Long Live CSP! On the Insecurity of Whitelists and the Future of Content Security Policy}},
+	author = {Lukas Weichselbaum and Michele Spagnuolo and Artur Janc and Sebastian Lekies},
+	booktitle = {Proceedings of the 5th ACM SIGSAC Conference on Computer and Communications Security (CCS '16)},
+	address = {New York, NY, USA},
+	doi = {10.1145/297674},
+	year = 2016,
+}
+
 % =========================================================================== %
diff --git a/tex/text.tex b/tex/text.tex
index 109f06f..0932f45 100644
--- a/tex/text.tex
+++ b/tex/text.tex
@@ -469,49 +469,33 @@ A header is additional information sent by both the server and the client.
 
 \n{2}{Content Security Policy}\label{sec:csp}
 
-Content Security Policy has been an important addition to the arsenal of
+Content Security Policy (CSP) has been an important addition to the arsenal of
 website operators, even though not everybody has necessarily been utilising it
 properly or even taken notice. To understand what guarantees it provides and
 what kind of protections it employs, it is first necessary to grok how websites
 are parsed and displayed, which has been discussed in depth in previous
 sections.
 
+As per Weichselbaum et al.\ CSP is a mechanism designed to mitigate
+XSS~\cite{longliveCSP}. It is a declarative policy mechanism that allows the
+website operator to decide what client-side resources can load and what origins
+are permitted. Scripts can be restricted to only load from a list of trusted
+domains and inline scripts can be blocked completely. The scripts can also be
+allowed based on a cryptographic hash based on their content, which should be a
+known information to website operators prior to or at the time scripts are
+served.
 
-\n{1}{Sandboxing}\label{sec:sandboxing}
-\n{2}{User isolation}
-Admin vs regular user, privilege escalation, least-privilege principle,
-zero-trust principle.
-\n{2}{Process isolation}
-Sandbox escape.
-\n{2}{Namespaced isolation}
-Sandbox escape.
-
-
-\n{1}{Data storage}
-Among the key aspects of any security-minded system (application), the
-following are certain to make the count:
-\begin{enumerate}
-  \item data integrity
-  \item data authenticity
-  \item data confidentiality
-\end{enumerate}
-
-\n{2}{Integrity}
-
-\n{2}{Authenticity}
-
-\n{2}{Confidentiality}
-
-\n{2}{Encryption-at-rest}
-
-
-\n{1}{Compromise checking and prevention}
-
-\n{2}{HIBP and similar tools}
-
-\n{2}{OWASP Top 10 for the implementers}
-
-\n{2}{Password best practices}
+CSP3, which is the current version, can be served either as a header or inside
+website's \texttt{<meta>} tag. Directives are generally named after a topic
+keyword and suffixed `-src', such as \texttt{script-src}, \texttt{img-src} or
+\texttt{style-src}, although some directives don't follow this pattern,
+\texttt{form-action}, \texttt{upgrade-insecure-requests} and \texttt{sandbox}
+representing this group nicely. Sections are delimited using semicolons and
+each section can only appear once. Special values exist for the origin itself
+(\texttt{'self'}) and disallowing any source (\texttt{'none'}). A good CSP is
+targeted and not overly broad. For instance, a website that loads no JavaScript
+at all does not need to allow a popular CDN (Content Delivery Network) origin
+in its \texttt{script-src}, instead it can be set to \texttt{'none'}.
 
 
 % =========================================================================== %