commit 2cc902c24cd2b7f20a60016857f07764e6334fdb
parent d797ff8b1101953416dc13657a750b6e1c4451ef
Author: Casaburi Johannes <johannes.casaburi@students.bfh.ch>
Date: Wed, 12 Jun 2024 19:48:39 +0200
thesis small fixes
Diffstat:
11 files changed, 176 insertions(+), 44 deletions(-)
diff --git a/doc/thesis/abstract.tex b/doc/thesis/abstract.tex
@@ -22,5 +22,12 @@ donor can provide this donation statement to the tax authority which
can check its validity and can then approve the tax deduction.
%motivation
+Providing evidence of charitable donations for tax deductions often requires
+sensitive personal information, raising privacy concerns.
+Donors may wish to anonymize receipts while still beeing able to make
+legitimate donations to recognized charities.
+Deductions for unrecognized charities or failure to deduct valid foreign
+donations also occur. A system allowing anonymous yet verifiable donation
+receipts would address these issues.
\end{abstract}
diff --git a/doc/thesis/chapters/approach/concept.tex b/doc/thesis/chapters/approach/concept.tex
@@ -81,7 +81,7 @@ Upon receiving the signed issue request from the charity, the Donau must verify
the charity signature and check that the yearly donation limit of the charity
is not exceeded.
After successful verification the Donau blind signs the donation receipt which
-is then sent via the charity back to the Donor (See figure: \ref{fig:issue
+is then sent via the charity back to the Donor (See figure \ref{fig:issue
receipt response}).
The donor now unblinds the signature from the Donau to make it valid for the
unblinded receipt (for more information on blind signatures see section \ref{blind_signatures}).
@@ -113,7 +113,7 @@ have accumulated any number of these donation receipts.
\section{Summarize the Receipts}\label{summarize_the_receipts}
When it is time for the tax declaration (usually at the beginning of the next
year) the donor has to request a final donation statement signature from the
-Donau, summarizing all the donation receipts of a year (see figure:
+Donau, summarizing all the donation receipts of a year (see figure
\ref{fig:summarize receipts}).
This step combines the amounts of the donation receipts in a single total
amount.
@@ -166,7 +166,7 @@ donation receipts.
\section{Validation}\label{validation}
Once the donor has received the donation statement signature, he can summarize
them in a QR code. The donor must submit the QR-Code with his tax documents,
-in order to claim the tax reduction (see figure:\ref{fig:validation}).
+in order to claim the tax reduction (see figure \ref{fig:validation}).
The final check is made by the tax authority, by checking the donation
statement signature. If the signature is valid, this is the proof that the
specified donor indeed has donated the claimed amount in the indicated year.
diff --git a/doc/thesis/chapters/background/blindsign.tex b/doc/thesis/chapters/background/blindsign.tex
@@ -47,5 +47,6 @@ trip is no longer significant.\cite{DemHeuz2022}
Because clause schnorr signatures are based on elliptic curves, smaller keys
can be used. GNU Taler supports one fixed 256 bit key size, which provides an
-security level of 128 bits.
+security level of 128 bits. The exact processes of this signature scheme do not
+need to be understood in order to understand this thesis.
diff --git a/doc/thesis/chapters/implementation/android.tex b/doc/thesis/chapters/implementation/android.tex
@@ -1,5 +1,15 @@
\section{Android Verification App}\label{android_verification_app}
-The Android app is part of the verification process used by the tax authority to check the donation statement (see \ref{donor_sends_final_statement_to_a_validator}).
+The Android app is part of the verification process used by the tax authority
+to check the donation statement (see
+\ref{donor_sends_final_statement_to_a_validator}).
-It is possible to define an URI scheme for an Android app. The app opens when the link is activated. The arguments defined in chapter \ref{donor_sends_final_statement_to_a_validator} are separated with slashes. To ensure that as many characters as possible can be stored in the QR code, the QR code should be alphanumeric encoded\footnote{alphanumeric encoded QR codes have a capaticity of up to 4296 characters and support only a few special characters}. This means that each argument is stringified. To ensure that no special characters are used for binary data, the hash and the signature are encoded in ASCII using CrockfordBase32.\cite{qrcodedensowavewebsite}
+It is possible to define an URI scheme for an Android app. The app opens when
+the link is activated. The arguments defined in chapter
+\ref{donor_sends_final_statement_to_a_validator} are separated with slashes. To
+ensure that as many characters as possible can be stored in the QR code, the QR
+code should be alphanumeric encoded\footnote{alphanumeric encoded QR codes have
+a capaticity of up to 4296 characters and support only a few special
+characters}. This means that each argument is stringified. To ensure that no
+special characters are used for binary data, the hash and the signature are
+encoded in ASCII using CrockfordBase32.\cite{qrcodedensowavewebsite}
%TODO: Add Link example
diff --git a/doc/thesis/chapters/implementation/arch.tex b/doc/thesis/chapters/implementation/arch.tex
@@ -1,10 +1,15 @@
\section{System Architecture}\label{system_architecture}
-As the charity backend and donor wallet implementation are not yet developed the following architecture is reduced to the Donau backend.
+As the charity backend and donor wallet implementation are not yet developed
+the following architecture is reduced to the Donau backend.
\begin{figure}[ht]
\includegraphics[width=1\textwidth]{donau_system_arch}
\caption{Donau system architecture} \label{fig:donau_system_arch}
\end{figure}
-The Donau backend implements the REST API and HTTP handler which communicates with the database plugin. The postgresql database is further described in section \ref{donau_database} of the thesis.
-The HTTP handler includes a key handler that interacts with the three secmod processes. The secmod processes generate the keys. Only they have access to the private keys.
+The Donau backend implements the REST API and HTTP handler which communicates
+with the database plugin. The postgresql database is further described in
+section \ref{donau_database} of the thesis.
+The HTTP handler includes a key handler that interacts with the three secmod
+processes. The secmod processes generate the keys. Only they have access to the
+private keys.
diff --git a/doc/thesis/chapters/implementation/donau.tex b/doc/thesis/chapters/implementation/donau.tex
@@ -1,13 +1,25 @@
\section{Donau}\label{donau}
-The Donau is written in C as it reuses parts of the codebase from the exchange of GNU Taler \ref{taler}. The Donau has a similar architecture and uses crypographic blinded signatures in a similar way as the exchange does.
+The Donau is written in C as it reuses parts of the codebase from the exchange
+of GNU Taler (see section \ref{taler} for more information about GNU Taler).
+The Donau has a similar architecture and uses
+crypographic blinded signatures in a similar way as the exchange does.
\subsection{REST API} \label{rest_api}
-The detailed REST API specificatoin of the Donau backend is publicy available at the following url: \url{https://docs.taler.net/core/api-donau.html}. The following are the main API endpoints:
+The detailed REST API specificatoin of the Donau backend is publicy available
+under the following URL: \url{https://docs.taler.net/core/api-donau.html}. The
+following are the main API endpoints:
\subsubsection{\texttt{/keys}}
-The \texttt{GET /keys} request returns all valid donation unit public keys offered by the Donau, as well as the Donau's current EdDSA public signing key. Donation unit keys are used by the Donau to sign blinded messages for an issue receipt request. The signing key is primarily used to create the donation statement signature for the donor (see section \ref{donor_requests_a_donation_statement_from_the_donau}).
+The \texttt{GET /keys} request returns all valid donation unit public keys
+offered by the Donau, as well as the Donau's current EdDSA public signing key.
+Donation unit keys are used by the Donau to sign blinded messages for an issue
+receipt request. The signing key is primarily used to create the donation
+statement signature for the donor (see section
+\ref{donor_requests_a_donation_statement_from_the_donau}).
-The following is an example response of a \lstinline{curl 127.0.0.1:8080/keys} command. Some parts of the following example respones are truncated (denoted by \texttt{...}) to make them more readable.
+The following is an example response of a \lstinline{curl 127.0.0.1:8080/keys}
+command. Some parts of the following example respones are truncated (denoted by
+the three dots '\texttt{...}') to make them more readable.
\begin{lstlisting}
{
@@ -55,16 +67,24 @@ The following is an example response of a \lstinline{curl 127.0.0.1:8080/keys} c
\end{lstlisting}
\subsubsection{\texttt{/charities}}
-In order for a charity to be able to issue receipts by a specific Donau it must be registered by this Donau. To do so the Donau provides an API to manage charities. It is expected that only the Donau administrator can manage the registered charities.
-The charity itself should be able to request their issued donation receipt to keep track of the set donation limit.
-The response includes the maximum donation amount and the current donated amount for the charity of the current year.
+In order for a charity to be able to issue receipts by a specific Donau it must
+be registered by this Donau. To do so the Donau provides an API to manage
+charities. It is expected that only the Donau administrator can manage the
+registered charities.
+The charity itself should be able to request their issued donation receipt to
+keep track of the set donation limit.
+The response includes the maximum donation amount and the current donated
+amount for the charity of the current year.
\begin{figure}[ht]
\includegraphics[width=1\textwidth]{donau_flow_register_charity}
\caption{flow chart register charity} \label{fig:donau_flow_register_charity}
\end{figure}
-The following is an example response of a \lstinline{curl 127.0.0.1:8080/charities} command. There is only one charity named \texttt{example} registered with a donation limit of 10 euros.
+The following is an example response of a
+\lstinline{curl 127.0.0.1:8080/charities} command.
+There is only one charity named
+\texttt{example} registered with a donation limit of 10 euros.
\begin{lstlisting}
{
@@ -81,7 +101,9 @@ The following is an example response of a \lstinline{curl 127.0.0.1:8080/chariti
}
\end{lstlisting}
-To insert a charity a POST request can be sent using \lstinline{curl -d @charity.json -X POST http://127.0.0.1:8080/charities}.
+To insert a charity a \texttt{POST} request can be sent using
+\lstinline{curl -d @charity.json -X POST http://127.0.0.1:8080/charities}.
+
\begin{lstlisting}[title=charity.json]
{
"charity_pub": "ABETNXT9ZF606FRF3WD5...",
@@ -102,10 +124,19 @@ The response consists of the charity ID generated by the database.
\subsubsection{\texttt{/batch-issue}}
-Only recognized charities are allowed to issue receipts for their donors (see section \ref{issuing_donation_receipts}).
-An \texttt{POST} issue receipt request includes an array of \texttt{BKP}s. A \texttt{BKP} consists of a \texttt{BUDI} and a hash of a public donation unit key (see section \ref{notation_and_definitions}).
-The charity also signs the request with its own EdDSA private key. The corresponding public key was given to the Donau in the registration process of the charity.
-After the Donau checked the signature from the charity it signs the \texttt{BUDI}s with the corresponding donation unit private key. Before the signatures are returned to the charity the Donau saves a hash of the request and all donation unit signatures to make the request idempotent (see section \ref{donau_database}).
+Only recognized charities are allowed to issue receipts for their donors (see
+section \ref{issuing_donation_receipts}).
+A \texttt{POST} issue receipt request includes an array of \texttt{BKP}s. A
+\texttt{BKP} consists of a \texttt{BUDI} and a hash of a public donation unit
+key (see section \ref{notation_and_definitions}).
+The charity signs the request with its own EdDSA private key. The
+corresponding public key was given to the Donau in the registration process of
+the charity.
+After the Donau checked the signature from the charity it signs the
+\texttt{BUDI}s with the corresponding donation unit private key. Before the
+signatures are returned to the charity the Donau saves a hash of the request
+and all donation unit signatures to make the request idempotent (see section
+\ref{donau_database}).
\begin{figure}[ht]
\includegraphics[width=1\textwidth]{donau_flow_issue_receipt}
@@ -113,7 +144,8 @@ After the Donau checked the signature from the charity it signs the \texttt{BUDI
\end{figure}
The following is an example response of a \\
-\lstinline{curl -d @issue.json -X POST http://127.0.0.1:8080/batch-issue/1} request. The number at the end of the URL is the charity ID.
+\lstinline{curl -d @issue.json -X POST http://127.0.0.1:8080/batch-issue/1}
+request. The number at the end of the URL is the charity ID.
\begin{lstlisting}[title=issue.json]
{
@@ -146,13 +178,21 @@ The following is an example response of a \\
\end{lstlisting}
\subsubsection{\texttt{/batch-submit}}
-The post submit route is used by the donor to summarize his or her donation receipts into one donation statement EdDSA signature.
-The request is composed of the donation receipt (see section \ref{notation_and_definitions}), the corresponding year and the hash of the salted tax ID.
-Processing the request the Donau checks the validity of the donation receipts and searches after more saved donation receipts made in the requested year.
-The EdDSA signature over the total amount of the value of the donation units of all donation receipts of the year, the hash of the salted tax id and the year forms the donation statement. The donation statement and the receipts are stored in the database (see section \ref{donau_database}).
+The batch-submit route is used by the donor to summarize their donation
+receipts into one donation statement EdDSA signature.
+The request is composed of the donation receipt (see section
+\ref{notation_and_definitions}), the corresponding year and the hash of the
+salted tax ID.
+When processing the request the Donau checks the validity of the donation
+receipts and searches after more saved donation receipts made in the requested
+year. The EdDSA signature over the total amount of the value of the donation
+units of all donation receipts of the year, the hash of the salted tax ID and
+the year forms the donation statement. The donation statement and the receipts
+are stored in the Donau database (see section \ref{donau_database}).
\subsubsection{\texttt{/donation-statement}}
-Even the donation statement will not be returned after a submit request, a donation statement get request can be made for a specified year and a salted and hashed tax id.
+The donation statement will not be returned after a submit request, a
+donation statement get request can be made for a specified year and tax ID.
\begin{figure}[ht]
\includegraphics[width=1\textwidth]{donau_flow_submit_receipt}
@@ -160,7 +200,9 @@ Even the donation statement will not be returned after a submit request, a donat
\end{figure}
The following is an example of a \\
-\lstinline{curl -d @submit.json -X POST http://127.0.0.1:8080/batch-submit} request. If successful, the Donau returns the \texttt{HTTP 201} status code with an empty response.
+\lstinline{curl -d @submit.json -X POST http://127.0.0.1:8080/batch-submit}
+request. If successful, the Donau returns the \texttt{HTTP 201} status code
+with an empty response.
\begin{lstlisting}[title=submit.json]
{
@@ -194,17 +236,29 @@ The last parameter of the URL is the salted hash of the donor tax ID.
}
\end{lstlisting}
\subsection{Donau Client}
-The REST client removes some of the complexity of sending requests to the Donau Server. It converts request parameters into JSON and parses JSON responses into a usable C format. What the exact queries are and how they look like is already described in the chapter \label{rest_api}.
+The REST client removes some of the complexity of sending requests to the Donau
+Server. It converts request parameters into JSON and parses JSON responses into
+a usable C format. What the exact queries are and how they look like is already
+described in chapter \label{rest_api}.
\subsection{Donau Database}\label{donau_database}
-The Donau database contains five tables as shown in figure \ref{fig:db_physical_model}. The \texttt{donation\_units} and \texttt{donau\_sign\_keys} table store the keys necessary for signing and creating donation receipts. Donation receipts that are issued to be signed by the donau are stored in the \texttt{receipts\_issued} table while the receipts that are already signed are stored in the \texttt{receipts\_submitted} table. The \texttt{history} table keeps the donation records of the past years.
+The Donau database contains five tables as shown in figure
+\ref{fig:db_physical_model}. The \texttt{donation\_units} and
+\texttt{donau\_sign\_keys} table store the keys necessary for signing and
+creating donation receipts. Donation receipts that are issued to be signed by
+the donau are stored in the \texttt{receipts\_issued} table while the receipts
+that are already signed are stored in the \texttt{receipts\_submitted} table.
+The \texttt{history} table keeps the donation records of the past years.
\begin{figure}[ht]
\includegraphics[width=1\textwidth]{db_physical_model}
\caption{database physical model (generated by \url{dbdiagram.io})} \label{fig:db_physical_model}
\end{figure}
\subsubsection{charities}
-Each registered charity has an entry in this table. There may be a donation limit imposed by local law which prevents further donations if the limit is reached.
+Each registered charity has an entry in this table. There may be a donation
+limit imposed by local law which prevents further donations if the limit is
+reached.
+
\begin{itemize}
\item \texttt{charity\_id:} Unique ID generated by the database.
\item \texttt{charity\_pub:} Charity EdDSA public key
@@ -246,7 +300,9 @@ Contains all issued donation receipts sent to the Donau.
\end{itemize}
\subsubsection{receipts\_submitted}
-Contains all submitted donation receipts sent to the Donor. By storing the signature \texttt{donation\_unit\_sig}, the idempotentcy of the API is kept in case the private key is replaced.
+Contains all submitted donation receipts sent to the Donor. By storing the
+signature \texttt{donation\_unit\_sig}, the idempotentcy of the API is kept in
+case the private key is replaced.
\begin{itemize}
\item \texttt{receipt\_id:} Unique ID generated by the database.
\item \texttt{h\_tax\_number:} The hash of the tax number and salt.
@@ -257,7 +313,9 @@ Contains all submitted donation receipts sent to the Donor. By storing the signa
\end{itemize}
\subsubsection{history}
-History of the yearly donations for each charity. This data provides a record of donations each year. It could also provide valuable information that could be used in statistics to analize general donations over the year.
+History of the yearly donations for each charity. This data provides a record
+of donations each year. It could also provide valuable information that could
+be used in statistics to analize general donations over the year.
\begin{itemize}
\item \texttt{charity\_id:} Unique ID generated by the database.
\item \texttt{final\_amount:} The final amount that was donated to the charity
diff --git a/doc/thesis/chapters/protocol/definitions.tex b/doc/thesis/chapters/protocol/definitions.tex
@@ -1,7 +1,14 @@
+This chapter describes the Donau protocol. In the first section notations and
+definitions are established which are then used in the later section where
+the protocol details are described.
+To fully comprehend the cryptographic concepts discussed in this chapter, the
+reader may need prior knowledge or background in this field.
+
\section{Notation \& Definitions}\label{notation_and_definitions}
\subsection{Notation}\label{notation}
+The following are notations used in the following pages of this chapter.
\begin{itemize}
- \item $\langle a, b, ... \rangle$ : Pair/tuple
+ \item $\langle a, b, ... \rangle$ is used to represent a Pair or tuple
\end{itemize}
\subsection{Definitions}\label{definitions}
diff --git a/doc/thesis/chapters/results/conclusion.tex b/doc/thesis/chapters/results/conclusion.tex
@@ -1,10 +1,31 @@
\section{Conclusion}\label{conclusion}
-Tax transparency is a crucial aspect of a well-functioning society, as it fosters trust, accountability, and fairness in the relationship between the state and its citizens. Transparency allows for public scrutiny, which can help identify inefficiencies, loopholes, or instances of corruption within the tax system, ultimately leading to necessary reforms and improvements.
+Tax transparency is a crucial aspect of a well-functioning society, as it
+fosters trust, accountability, and fairness in the relationship between the
+state and its citizens. Transparency allows for public scrutiny, which can help
+identify inefficiencies, loopholes, or instances of corruption within the tax
+system, ultimately leading to necessary reforms and improvements.
-Unfortunately, it occured to us that some tax departments still rely on outdated, paper-based systems or legacy software, hindering their ability to operate efficiently and transparently. The lack of digitization not only slows down processes but also increases the risk of errors, data inconsistencies, and potential mishandling of sensitive information.
+Unfortunately, it occured to us that some tax departments still rely on
+outdated, paper-based systems or legacy software, hindering their ability to
+operate efficiently and transparently. The lack of digitization not only slows
+down processes but also increases the risk of errors, data inconsistencies, and
+potential mishandling of sensitive information.
-The adoption of free and open-source software (FOSS) presents a compelling solution. FOSS solutions offer several advantages, including cost-effectiveness, customizability, and the ability to scrutinize the underlying code for security and transparency purposes. By embracing FOSS, tax departments can modernize their systems, streamline processes, and enhance data integrity, ultimately fostering greater transparency and trust with the public.
+The adoption of free and open-source software (FOSS) presents a compelling
+solution. FOSS solutions offer several advantages, including
+cost-effectiveness, customizability, and the ability to scrutinize the
+underlying code for security and transparency purposes. By embracing FOSS, tax
+departments can modernize their systems, streamline processes, and enhance data
+integrity, ultimately fostering greater transparency and trust with the public.
-The Donau system supports tax justice. The Donau not only manages to anonymize user data, so that everyone is treated equally, but also helps the donor to make use of their right to deduct donations from taxes. Because the donation receipts are stored in a central location and can even be deposited in the Donau, the likelihood of losing or forgetting to submit the receipts is reduced.
+The Donau system supports tax justice. The Donau not only manages to anonymize
+user data, so that everyone is treated equally, but also helps the donor to
+make use of their right to deduct donations from taxes. Because the donation
+receipts are stored in a central location and can even be deposited in the
+Donau, the likelihood of losing or forgetting to submit the receipts is
+reduced.
-Of course, bureaucracy and federalism can hinder the introduction of such a system. Especially when it comes to the recognition of charities. But the Donau could provide a first step into a more standardized system that handels donations in a secure and privacy preserving way.
+Of course, bureaucracy and federalism can hinder the introduction of such a
+system. Especially when it comes to the recognition of charities. But the Donau
+could provide a first step into a more standardized system that handels
+donations in a secure and privacy preserving way.
diff --git a/doc/thesis/chapters/results/future.tex b/doc/thesis/chapters/results/future.tex
@@ -1,10 +1,34 @@
\section{Future work}\label{future_work}
\subsection{Client implementation}\label{client_implementation}
-The donor client implementation needs to be implemented in the Taler wallet. This is a necessary step to be able to use the Donau together with the Taler payment system. Then donations could be made fully anonymous. The necessary functionality must be implemented in the \texttt{taler-wallet-core}. This includes the option to make donations and request for the final donation statement. If the donor wants to be able to deduct the donations from taxes, the user is asked to input his tax number. Hidden from the user are the generation of the various elements such as \texttt{DI}, \texttt{UDI}, \texttt{BUDI} and \texttt{BKP}. The blinding and unblinding implementation must also be present.
+The donor client implementation needs to be implemented in the Taler wallet.
+This is a necessary step to be able to use the Donau together with the Taler
+payment system. Then donations could be made fully anonymous. The necessary
+functionality must be implemented in the \texttt{taler-wallet-core}. This
+includes the option to make donations and request for the final donation
+statement. If the donor wants to be able to deduct the donations from taxes,
+the user is asked to input his tax number. Hidden from the user are the
+generation of the various elements such as \texttt{DI}, \texttt{UDI},
+\texttt{BUDI} and \texttt{BKP}. The blinding and unblinding implementation must
+also be present.
\subsection{Charity backend}\label{charity_backend}
-Each registered charity needs to communicate with the donors and the Donau. The Taler merchant backend needs to be modified to incorporate the charity backend logic. To do this it is necessary to add a charity information table to the merchant database. This table should contain information like the charity public key, domain, base URL, currency and instance. The instance beeing a number as there could be different instances running. The merchant backend needs to be extended to incorporate the charity logic. Meaning the signing of BKP's sent to the charity and also the communication with the donor. The charity should return a list of Donaus where the charity is registered, so that the donor can choose the appropriate Donau for tax deduction.
+Each registered charity needs to communicate with the donors and the Donau. The
+Taler merchant backend needs to be modified to incorporate the charity backend
+logic. To do this it is necessary to add a charity information table to the
+merchant database. This table should contain information like the charity
+public key, domain, base URL, currency and instance. The instance beeing a
+number as there could be different instances running. The merchant backend
+needs to be extended to incorporate the charity logic. Meaning the signing of
+BKP's sent to the charity and also the communication with the donor. The
+charity should return a list of Donaus where the charity is registered, so that
+the donor can choose the appropriate Donau for tax deduction.
+%thesis christian blättler
\subsection{Donau SPA}\label{donau_spa}
-For the administrator a single page application is needed to comftably manage the charities. This would include functionality to add, remove and modify charities. This setup could include a reverse proxy, which authenicates the Donau admin. Once the identity has been confirmed the proxy can access the Donau endpoint to manage a charity. The proxy would hold a bearer token, in order to authenticate itself.
+For the administrator a single page application is needed to comftably manage
+the charities. This would include functionality to add, remove and modify
+charities. This setup could include a reverse proxy, which authenicates the
+Donau admin. Once the identity has been confirmed the proxy can access the
+Donau endpoint to manage a charity. The proxy would hold a bearer token, in
+order to authenticate itself.
diff --git a/doc/thesis/chapters/results/results.tex b/doc/thesis/chapters/results/results.tex
@@ -24,7 +24,6 @@ The tax authority emphasises user convenience and simplicity in a system like
the Donau. The tax authority also mentioned the challanges that arise when
operating such a system in the federalism. Each party often has different
requirements that a system like the Donau should fulfill.
-
Although the Donau is in its early stages and the prototype has not yet been
deployed, the tax authority Zürich definitely sees potential in the user
convenience side of the Donau.
diff --git a/doc/thesis/thesis.pdf b/doc/thesis/thesis.pdf
Binary files differ.
