[taler-anastasis] branch master updated: misc minor edits

[gnunet]

This is an automated email from the git hooks/post-receive script.

grothoff pushed a commit to branch master
in repository anastasis.

The following commit(s) were added to refs/heads/master by this push:
     new c029d9a  misc minor edits
c029d9a is described below

commit c029d9a85736284f0520a5d45239c9c47fe4330f
Author: Christian Grothoff <christian@grothoff.org>
AuthorDate: Wed Jun 10 23:57:13 2020 +0200

    misc minor edits
---
 doc/thesis/business_model.tex      | 47 ++++++++++++++++++++++++--------------
 doc/thesis/client_architecture.tex |  4 ++--
 doc/thesis/design.tex              |  4 ++--
 doc/thesis/implementation.tex      | 10 ++++----
 4 files changed, 39 insertions(+), 26 deletions(-)

diff --git a/doc/thesis/business_model.tex b/doc/thesis/business_model.tex
index 2171379..ecfcf1f 100644
--- a/doc/thesis/business_model.tex
+++ b/doc/thesis/business_model.tex
@@ -95,9 +95,9 @@ wallet key.
 \subsubsection{Key partners}
 
 Our key partners for Anastasis are three entities. First the business
-partners, Taler Systems SA and PEP Foundation, with whom we could
+partners, Taler Systems SA and p$\equiv$p Foundation, with whom we could
 already make contracts and wish to integrate our product.  Second are
-the providers of Cloud Services. To operate Anastasis with minimal
+the providers of Cloud services. To operate Anastasis with minimal
 cost we need the service of these providers. These providers can
 additionally provide us authentication services, this also minimizes
 the complexity of our solution since we do not have to implement these
@@ -147,20 +147,32 @@ is user friendly and inexpensive.
 \subsubsection{Customer relationships}
 
 In the early stages of our start-up our customers are primary going to
-be Business customers. Like Taler Systems SA which wants to integrate
-our solution into their wallet. This means at the begin our customers
-are mainly the users of already existing solutions. In later stages of
-our start-up we also want to acquire business to customer clients, for
-example users who want to secure their private key for their disk
-encryption.
+be business customers like Taler Systems SA, p$\equiv$p Foundation,
+Fraunhofer AISEC and NymTech, which all want to integrate our solution
+into their products.  Thus, early on we will likely pursue B2B sales,
+lining up businesses that would want to integrate Anastasis with
+existing security products.
+
+Once successful products exist in the market, our revenue should
+inherently shift to a B2C model, as then customers will pay for the
+recovery service.  We may then also ourselves invest in integration of
+Anastasis with further software solutions to grow the business, even
+in domains where there is no significant business partner.  This will
+be the case for applications where popular non-commercial solutions
+are freely available. An example for this domain would be consumer
+software that enables disk encryption.
 
 \subsubsection{Customer segments}
 
-As mentioned earlier our customers will be primarily other solutions
-which need a way to backup their keys.  Many applications with
-decentralized structures need such a solution.  Other possible
-customers are users of digital currencies or users of OpenPGP
-solutions.
+Our business customers will be primarily developers of security
+applications which need a way to enable end-users to securely
+backup end-user key material.
+
+End-users paying for the recovery service will be all users using
+privacy-enhancing technologies, where the putting the user in charge
+of their data also burdens the user with taking care of their private
+keys.  Specific applications include payment services including
+crypto-currencies and end-to-end encrypted communication services.
 
 \subsubsection{Cost structure}
 
@@ -177,10 +189,11 @@ In the beginning, businesses like Taler Systems SA will 
pay us to
 operate an Anastasis server and to help them integrate our protocol
 with their software.  Once we have many end-users utilizing Anastasis,
 they will have to pay directly for the service. The users have to pay
-a subscription fee and micro payments for each transaction. For
-example a user has to pay 0.1 CHF per month for the subscription and
-0.01 CHF for each upload. Additionally, the user would have to pay for
-expensive authentication methods like video identification.
+a subscription fee and possibly additinal fees for expensive recovery
+operations. For example a user might pay 0.10 CHF per month for the
+subscription and 0.01 CHF for each encrypted truth
+upload. Additionally, the user would have to pay for expensive
+authentication methods like video identification.
 
 \subsection{Project plan}
 
diff --git a/doc/thesis/client_architecture.tex 
b/doc/thesis/client_architecture.tex
index ebe34a5..9c6e1e1 100644
--- a/doc/thesis/client_architecture.tex
+++ b/doc/thesis/client_architecture.tex
@@ -26,8 +26,8 @@ The most important data structures in the crypto API are the 
following:
   \item
 The kdf\_id is a hash code which was generated with Argon2. The
 entropy source is the user's unforgettable secret. The kdf\_id is used
-to create various key's, for more details see Implementation
-Cryptography
+to create various key's, for more details see Chapter~\ref{chap:design}.
+
 \begin{lstlisting}
 struct kdf_id
 {
diff --git a/doc/thesis/design.tex b/doc/thesis/design.tex
index 513104d..34a554f 100644
--- a/doc/thesis/design.tex
+++ b/doc/thesis/design.tex
@@ -1,4 +1,4 @@
-\section{Design}
+\section{Design} \label{chap:design}
 
 Anastasis is a service that allows the user to securely deposit a {\em core
 secret} with an open set of escrow providers and recover it if the
@@ -379,7 +379,7 @@ Anastasis considers two main threats against availability. 
First, the
 Anastasis server operators must be protected against denial-of-service
 attacks where an adversary attempts to exhaust operator’s
 resources. The API protects against these attacks by allowing
-operators to set fees for all operations. Furthermore, all data stored
+operators to set fees for expensive operations. Furthermore, all data stored
 comes with an expiration logic, so an attacker cannot force servers to
 store data indefinitely.
 
diff --git a/doc/thesis/implementation.tex b/doc/thesis/implementation.tex
index 40a5095..d347ace 100644
--- a/doc/thesis/implementation.tex
+++ b/doc/thesis/implementation.tex
@@ -156,7 +156,7 @@ Figure~\ref{fig:recovery_process} illustrates the recovery 
process.
   policies and authentication methods. The user now has to solve these
   challenges. In this example the user has to answer a secure question
   which was sent to them in the recovery document. (GET
-  /truth/\$UUID?resonse=\$RESPONSE) \\
+  /truth/\$UUID?response=\$RESPONSE) \\
 \item Note the server can define that a challenge has a certain cost,
   in this scenario the server rejects the first request because the
   user has not yet paid for recovery.  After the payment the user can
@@ -405,7 +405,7 @@ The following four tests are independently performed.
 \item The first test is the database test. The Anastasis testing library first 
connects to a test database, this database is only used for the testing, we 
never test on the live database. The test first deletes and recreates the 
database. After that it will perform several unit tests to check if the 
database queries of the application are working as intended.
 \item Next we test the Anastasis crypto API, it tests all the
 cryptographic functions used in the API with unit tests.
-The most important part is  that the recreation of the keys 
+The most important part is  that the recreation of the keys
 and decryption works as intended.
 \item After the basic parts of the application are tested the client
 will test every request in the Anastasis server API. For this we need the
@@ -415,8 +415,8 @@ service is needed to proccess the payment operations. The 
testing library
 will now send a request to every end point of the Anastasis REST API. It will
 check if every response of the REST API is as intended.
 \item At the end the whole application flow is tested. For this
-we need to start a Anastasis server, Taler merchant and Taler exchange 
instance. 
+we need to start a Anastasis server, Taler merchant and Taler exchange 
instance.
 The library will now perform a full secret split and secret recovery.
 This test is successful if the provided core secret at the begin, matches the
-recovered core secret. 
-\end{itemize}
\ No newline at end of file
+recovered core secret.
+\end{itemize}

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.