tex: rework conclusion
This commit is contained in:
parent
cd6431fe83
commit
18871cdcf6
53
tex/text.tex
53
tex/text.tex
@ -1727,39 +1727,46 @@ a testing instance; therefore, limits to prevent abuse might be imposed.
|
|||||||
% =========================================================================== %
|
% =========================================================================== %
|
||||||
\nn{Conclusion}
|
\nn{Conclusion}
|
||||||
|
|
||||||
This thesis opened by introducing common terminology and continued with a dive
|
The objectives of the thesis have been to create the Password Compromise
|
||||||
into cryptography topics such as encryption, mentioned Diffie-Hellman key
|
Monitoring Tool aimed at security-conscious user in order to validate their
|
||||||
distribution scheme and briefly mentioned TLS. Further, it discussed the inner
|
assumptions on the security of their credentials. The thesis opened by
|
||||||
workings of browsers and the protocols that underpin them.
|
introducing common terminology and continued with a dive into cryptography
|
||||||
|
topics such as encryption, Diffie-Hellman key distribution scheme and briefly
|
||||||
|
mentioned TLS. Furthermore, it discussed the inner workings of browsers and the
|
||||||
|
protocols that underpin them.
|
||||||
|
|
||||||
Additionally, security mechanisms such as Site Isolation and Content Security
|
Additionally, security mechanisms such as Site Isolation and Content Security
|
||||||
Policy, that are commonly employed by mainstream browsers of today were
|
Policy, commonly employed by mainstream browsers of today, were
|
||||||
introduced and the reader learnt how Content Security Policy is easily and
|
introduced and the reader learnt how Content Security Policy is easily and
|
||||||
dynamically configured.
|
dynamically configured.
|
||||||
|
|
||||||
The large part of the thesis then revolved around the practical part, described
|
An extensive body of the thesis then revolved around the practical part,
|
||||||
everything from tooling used through application high-level-view architecture
|
describing everything from tooling used through application high-level-view
|
||||||
to implementation of specific parts of the application across the stack.
|
architecture to implementation of specific parts of the application across the
|
||||||
|
stack.
|
||||||
|
|
||||||
Finally, the practical part concluded by extensively describing validation
|
Finally, the practical part concluded by broadly depicting validation
|
||||||
methods used to verify the application worked correctly.
|
methods used to verify if the application worked correctly.
|
||||||
|
|
||||||
Of course, there are things that the author wishes were done differently or
|
The author would like to recognise that there are certain aspects of the thesis
|
||||||
engineered better, but not everything could realistically be realised in the
|
in the need of further development. It is necessary to admit that not
|
||||||
limited timespan and scope that had to be imposed on the project to prevent
|
everything could have realistically been realised in the limited timespan and
|
||||||
diverging. This constitutes clear candidates for future work that improves on
|
scope imposed on the project to prevent diverging. The concerns mentioned above
|
||||||
the existing state, for example accessibility-wise. Author's unfamiliarity with
|
constitute clear candidates for future work of the author who intends to
|
||||||
the accessibility tooling sometimes compromising on the quality in this segment
|
improve on the existing state, for example accessibility-wise. The author's
|
||||||
of the application, but it is a known deficiency. Further, on the list of tasks
|
unfamiliarity with the accessibility tooling sometimes compromised on the
|
||||||
for the future also remained adding \emph{fuzzing} tests for the program,
|
quality in this segment of the application, but it is a known deficiency.
|
||||||
producing Software Bill of Materials, utilising additional immutable database
|
Furthermore, the list of tasks for the future may also contain adding
|
||||||
or unifying the frontend design language across the pages.
|
\emph{fuzzing} tests for the program, producing Software Bill of Materials,
|
||||||
|
utilising additional immutable database or unifying the frontend design
|
||||||
|
language across the pages.
|
||||||
|
|
||||||
The program does have a very solid core that for instance listens for OS
|
The program does have a very solid core that for instance listens for OS
|
||||||
signals, handles graceful shutdown and supports structured logging but still
|
signals, handles graceful shutdown and supports structured logging but still
|
||||||
has room for improvements, despite the fact that its creation really was
|
has room for improvements, despite the fact that its creation has been
|
||||||
best-effort. Due to the list of things mentioned earlier, it cannot really be
|
best-effort. Due to a number of reasons mentioned earlier, it should not be
|
||||||
called a \emph{finished} project yet, but it can already serve a purpose.
|
called an utterly \emph{finished} project yet, but it can already serve a clear
|
||||||
|
purpose.
|
||||||
|
|
||||||
|
|
||||||
% =========================================================================== %
|
% =========================================================================== %
|
||||||
|
Reference in New Issue
Block a user