Fix some of the footnotes

content/a_tour_of_tfw.tex

@@ -200,7 +200,7 @@ Developers have to \emph{explicitly} allow directories one by one to be listed b
 editor. This is done to avoid access control issues in case the editor is
 running with more permissions than the user should have%
 \footnote{Actually this involves extra caution, such as dealing with
-symlinks in an allowed directory which could point to other, non-allowed locations}.
+symlinks in an allowed directory which could point to other, non-allowed locations.}.
 It is also possible to blacklist file patterns (so that binary files can be
 excluded for example, as a text editor is not suitable to deal with these).
 
@@ -251,7 +251,7 @@ monitoring solution such as Sysdig%
 I deemed most simiar systems a huge overkill to implement this functionality, and their
 memory footprints are not something we could afford here%
 \footnote{These containers will be spawned on a per-user basis, so we must be as
-conservative with memory as possible}.
+conservative with memory as possible.}.
 Another way would be to use \code{pam_tty_audit.so} in the PAM%
 \footnote{Linux Pluggable Authentication Modules:
 \href{http://man7.org/linux/man-pages/man3/pam.3.html}
@@ -262,13 +262,13 @@ It is possible to set up the user's environment in
 such a way during the build of the image, that I can enforce and determine the
 location of the bash \code{HISTFILE}%
 \footnote{This environment variable contains the path to the file bash writes command
-history to}
+history to.}
 of the user.
 By combining this with the inotify system built into TFW, 
 the framework can monitor changes made to this file and read the commands executed
 by the user from it.
 It is important to keep in mind that the user is able to ``sabotage'' this method%
-\footnote{By unsetting the \code{HISTFILE} envvar for example},
+\footnote{By unsetting the \code{HISTFILE} envvar for example.},
 but that should not be an issue as this is not a feature that is intended to be
 used in competitive environments (and if the users of a tutorial intentionally
 break the system under themselves, well, good for them).
@@ -358,7 +358,7 @@ and write to \code{/tmp/}, causing the whole procedure to repeat again and again
 This continued until my machine would start to run out of memory and begin swapping
 pages to disk%
 \footnote{When a modern operating system runs out of physical RAM, it is going to swap
-virtual memory pages to disk so it can continue to operate --- slowly}
+virtual memory pages to disk so it can continue to operate --- slowly.}
 like crazy, causing the whole system to spiral downwards
 in a spectacular fashion until the whole thing managed to crash.
 It was an event of such rare and chaotic beauty, that I often fondly recall it to this day.

content/architecture.tex

@@ -20,7 +20,7 @@ This task is very easy to solve, with lots of possible solutions
 (named pipes, sockets or shared memory to name a few).
 The hard part is that frontend components running inside a web browser --- which could
 potentially be located on the other side of the planet%
-\footnote{Potentially introducing all sorts of issues regarding latency} --- would
+\footnote{Potentially introducing all sorts of issues regarding latency.} --- would
 also need to partake in said communication.
 So what we need to create is something of a hybrid between an IPC system and something
 that can communicate with JavaScript running in a browser connected to it.
@@ -54,7 +54,7 @@ some of the design decisions behind this:
 
 The old way of creating dynamic webpages was AJAX%
 \footnote{AJAX stands for Asynchronous JavaScript And XML, despite usually not having
-anything to do with XML in practice}
+anything to do with XML in practice.}
 polling, which is basically sending
 HTTP requests to a server at regular intervals from JavaScript to update the contents
 of your website (and as such requiring to go over the whole TCP handshake and the
@@ -68,7 +68,7 @@ This allows for communication with lower overhead and latency facilitating effic
 real-time applications, which were not always possible to create before due to
 the overheads%
 \footnote{In some applications this overhead could be bigger than the actual data sent,
-such as singaling} introduced by AJAX polling.
+such as singaling.} introduced by AJAX polling.
 
 The Tutorial Framework uses WebSockets to connect to it's web frontend.
 The TFW proxy server is capable to connecting to an arbirary number of WebSockets,
@@ -101,7 +101,7 @@ A few examples of top contenders and reasons for not using them in the end:
     all bytes are sent or received both require constantly checking the return values of the
     libc \code{send()} and \code{recv()} system calls%
 \footnote{Developers forget this very often, resulting in almost untraceable bugs
-that seem to occour randomly},
+that seem to occour randomly.},
     while ZMQ takes care of this
     extra logic involved and even provides higher level messaging patterns such as
     subscribe-publish, which would need to be implemented on top of raw sockets again.
@@ -114,9 +114,9 @@ that seem to occour randomly},
     force you to write synchronous or asynchronous code, whereas common HTTP servers
     are either async%
 \footnote{Async servers use the \code{select} or \code{epoll} system calls among others
-to avoid blocking on IO} or pre-fork%
+to avoid blocking on IO.} or pre-fork%
 \footnote{Pre-fork servers spawn multiple processes and threads to handle requests
-simultaneously} in nature, which extorts certain design choices on code
+simultaneously.} in nature, which extorts certain design choices on code
     built on them.
 \end{itemize}
 
@@ -172,7 +172,7 @@ All valid messages \emph{must} include a \code{key} field as this is used by the
 framework for addressing: event handlers and frontend components subscribe to one
 or more of these \code{key}s and only receive%
 \footnote{In reality they do receive them, just like how network interfaces receive all
-ethernet frames, they just choose ignore the ones not concerning them}
+ethernet frames, they just choose ignore the ones not concerning them.}
 messages with \code{key}s that they have
 subscribed to.
 It is possible to send a message with an empty key, however these messages will not

content/introduction.tex

@@ -10,8 +10,8 @@ about the risks involved in relying so much on software in our everyday lives.
 When taking a look on recent events, such as a cyber arms race taking place between leading
 powers\cite{CyberArmsRace}, 50 million Facebook accounts being breached
 due to the incorrect handling of access tokens\cite{FacebookBreach},
-the very recent Marriott hack where sensitive data on 500 million customers
-was stolen\cite{MarriottBreach},
+the very recent Marriott hack where sensitive data of 500 million customers
+got stolen\cite{MarriottBreach},
 or how China is building an Orwellian state of total digital surveillance%
 \cite{ChinaSurv}\cite{ChinaCredit},
 it becomes clear that security and privacy in the IT sector
@@ -56,7 +56,7 @@ The goal of Avatao as a company is to help software developers in building a \em
 security amongst themselves, with the vision that if the world is going to be taken over by
 software no matter what, that software might as well be \emph{secure software}.
 To achieve this goal we have been working on an online e-learning platform with hundreds%
-\footnote{654 exercises as of today, to be exact}
+\footnote{654 exercises as of today, to be exact.}
 of hands-on learning exercises to help students and professionals
 master IT security, collaborating with
 universities around the world and providing a solution for companies in building
@@ -122,7 +122,7 @@ Soon after recording demo videos was not even necessary anymore, as I have start
 the solution script with the challenge code itself, making it toggleable using build-time
 variables.
 Should the solution script be enabled, the challenge would automatically start%
-\footnote{I did this by injecting the solution script into the user's \code{.bashrc} file}
+\footnote{I did this by injecting the solution script into the user's \code{.bashrc} file.}
 completing itself in the terminal integrated into it's frontend, often even explaining the
 commands executed during the solution process.
 

content/using_the_framework.tex

@@ -280,7 +280,7 @@ I am going to display the implementation of the same FSM using these methods
 to showcase the capabilities of the framework.
 
 \subsection{YAML based FSM}
-YAML\footnote{YAML Ain't Markup Language \href{http://yaml.org}{http://yaml.org}}
+YAML\footnote{YAML Ain't Markup Language: \href{http://yaml.org}{http://yaml.org}}
 is a human friendly data serialization standard and a superset of JSON.
 It is possible to use this format to define a state machine like so:
 \lstinputlisting[
@@ -368,7 +368,7 @@ bash -c "$(curl -fsSL https://git.io/vxBfj)"
 This command downloads the script using \code{curl}%
 \footnote{\href{https://curl.haxx.se}{https://curl.haxx.se}}, then executes it in bash.
 In the open source community it is quite common to distribute installers this way%
-\footnote{A good example of this is oh-my-zsh
+\footnote{A good example of this is oh-my-zsh:
 \href{https://github.com/robbyrussell/oh-my-zsh}{https://github.com/robbyrussell/oh-my-zsh}},
 which might seem a little scary at first, but is not less safe then
 downloading and executing a binary installer from a website with a valid TLS certificate, as
@@ -454,7 +454,7 @@ Angular uses various optimizations such as tree shaking%
 {https://webpack.js.org/guides/tree-shaking/}}
 to remove all the dependencies that won't be used when running the application%
 \footnote{Otherwise it won't be possible to serve these applications efficiently
-over the internet}.
+over the internet.}.
 The problem is, that these things can take a \emph{really} long time.
 This is why today frontend builds usually take a lot longer than building anything
 not involving JavaScript (such as C++, C\# or any other compiled programming language).
@@ -462,7 +462,7 @@ not involving JavaScript (such as C++, C\# or any other compiled programming lan
 This mess presents it's own challenges for the Tutorial Framework as well.
 Since hundreds of megabytes of npm dependencies have no place inside Docker images%
 \footnote{Or it may take tens of seconds just to send the build context to
-the Docker daemon, which means waiting even before the build began},
+the Docker daemon, which means waiting even before the build began.},
 by default the framework will only copy the results of a frontend production build
 of \code{solvable/frontend} into the image layers.
 This slows down the build time of TFW based challenges so much, that instead of like
@@ -474,7 +474,7 @@ you use.
 To circumvent this, it is possible to entirely exclude the Angular frontend from a TFW
 build, using build time arguments%
 \footnote{In practice this is done by supplying the option
-\code{--build-arg NOFRONTEND=1} to Docker}.
+\code{--build-arg NOFRONTEND=1} to Docker.}.
 But when doing so, developers would have to run the frondent locally with
 the whole \code{node_modules} directory present.
 The bootstrap script takes care of putting these dependencies there,