[taler-marketing] branch master updated: expand principles

[gnunet]

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

grothoff pushed a commit to branch master
in repository marketing.

The following commit(s) were added to refs/heads/master by this push:
     new b736d00  expand principles
b736d00 is described below

commit b736d00bb617e21e721b25229ca6e0f364e99a3a
Author: Christian Grothoff <grothoff@gnunet.org>
AuthorDate: Wed Jan 26 00:16:59 2022 +0100

    expand principles
---
 2022-privacy/privacy.tex | 285 ++++++++++++++++++++++++++++++++++++-----------
 1 file changed, 217 insertions(+), 68 deletions(-)

diff --git a/2022-privacy/privacy.tex b/2022-privacy/privacy.tex
index 4fce83f..6282bb1 100644
--- a/2022-privacy/privacy.tex
+++ b/2022-privacy/privacy.tex
@@ -11,7 +11,8 @@
 \usepackage{enumitem}
 
 \title{Accounts are an Unnecessary Evil \\ A critique of two papers}
-\author{Antoinne Aligny \and Emmanuel Benoist \and Christian Grothoff \and 
\"Ozg\"ur Kesim \and Martin Schanzenbach}
+\author{Antoinne Aligny \and Emmanuel Benoist \and Florian Dold \and
+        Christian Grothoff \and \"Ozg\"ur Kesim \and Martin Schanzenbach}
 \date{\today}
 \begin{document}
 
@@ -38,6 +39,23 @@ system.  Our paper attempts to set the record straight.
 % [oec] Shouldn't we also mention GNU Taler already here as an example for an 
alternative?
 }
 
+\section{Introduction}
+
+FIXME: We had discussed doing a brief introduction of terms here:
+cryptocurrency, CBDC, retail CBDC vs. wholesale CBDC.
+
+Emmanuel: you wanted to integrate this with your critique:
+
+Part two of the report is of a much better level, one should still note that
+the ontological difference between pure digital currencies and traditional
+currencies is not very well addressed.
+
+
+After introducing retail vs. wholesale CBDC, we should
+mention French report's confusion between retail CBDC (SNB-Taler
+paper) and wholesale CBDC (Swiss Helvetia project).
+
+
 \section{The ECB cannot be the Guardian of Privacy}
 \label{sec:guardians}
 
@@ -262,10 +280,6 @@ not CBDCs. For example, a Swiss group around Claudio
 Zanetti~\footnote{\url{https://www.zanetti.ch/}} is considering launching an
 electronic payment system based on gold. Direct payments with physical gold
 are problematic, as giving change
-% This heavy use of "()" makes it difficult to read. If you want to make
-% this point, maybe in the design principles/plug at the end
-%(the exact problem GNU Taler~\cite{dold2019}
-%solves for Chaum's DigiCash~\cite{chaum1988untraceable})
 is impractical with
 gold as is the validation that the gold is pure. With eGold, Zanetti plans to
 ``establish a private competitor to the Swiss National Bank, that is not able
@@ -311,6 +325,7 @@ tokenization system would share is that they require some 
trust
 into the issuer of the currency, as in all cases the issuer could renegotiate 
on its
 promise to redeem the electronic tokens for the underlying asset.
 %FIXME: Should this also/instead be a design principle at the end?
+%CG: I think it fits here better...
 For such systems it should be possible for third parties to audit the issuer of
 tokens~\cite{dold2019}, which in the absence of fractional reserve banking
 reduces the risk from the issuer to that of the underlying asset class.
@@ -356,66 +371,210 @@ even if this has not always been the case. From this 
perspective, we can see
 that some of the large crypto-currencies also more or less respect these
 criteria (with some problems on the side of price stability).
 
-\section{Design principles for CBDC}
-
-We think that any CBDC must be based on design principles with a strong
-emphasis on privacy, like those GNU Taler is based upon:  Free/Libre software,
-protection of privacy of buyers, auditability, fraud prevention, information
-parsimony, usability, efficiency, fault-tolerance and fostering
-competition~\cite{talerPrinciples}.  In particular, the principle to protect of
-the privacy of the buyers states:
-\begin{quote}
-       Privacy is most meaningful when it is guaranteed via technical
-       measures, as opposed to mere policies. Without a technical layer
-       providing privacy-by-default, financial transactions reveal unnecessary
-       levels of personal or private data. This would be especially true when
-       making micropayments for online publications. Thus, GNU Taler must
-       protect the privacy of buyers to avoid facilitating totalitarian
-       control over the population.  Limited private data, such as the
-       shipping address for a physical delivery, may need to be collected
-       according to business needs and protected according to local laws. In
-       this case, GNU Taler must enable deletion of such data as soon as it is
-       no longer required.
-\end{quote}
+\section{Design principles for CBDCs}
+
+We think that any CBDC must be based on the following design principles
+inspired by~\cite{dold2019}, given in order of priority:
+
+\begin{enumerate}
+  \item \textbf{A CBDC must be implemented as free software.}
+
+    Free refers to ``free as in free speech'', as opposed to ``free as in free 
beer''.
+    More specifically, the four essential freedoms of free software
+    \cite{stallman2002essays} must be respected, namely users must have the
+    freedom to (1) run the software, (2) study and modify it, (3) redistribute
+    copies, and (4) distribute copies of the modified version.
+
+    This prevents vendor lock-in, as another software provider can
+    take over, should the current one provide inadequate quality of service.
+    Only Free Software can be seen as truly respecting the soveregnty of
+    citizens using the software, as well as countries relying on it.
+    As the ECB report states, international or even cross-border use of a
+    CBDC may be desireable, but this excludes solutions that would be under
+    the control of one nation unless we presume that nations will be willing
+    to subject critical infrastructure to the whims of other nations. Given
+    recent attacks by the US government against Huawei --- which effectively 
limited
+    Huawei's ability to use US software to Free Software~\cite{huawei} --- it 
is clear that
+    only Free Software is acceptable for critical infrastructure of sovereign
+    countries.  With Free Software all countries and
+    organizations can run the payment system without being controlled by a
+    foreign entities.  Customers benefit from this freedom, as the wallet
+    software can be made to run on a variety of platforms, and user-hostile
+    features such as tracking or telemetry could easily be removed from
+    wallet software.
+
+    This rules out the mandatory usage of specialized
+    hardware such as smart cards or other hardware security modules, as the
+    software they run cannot be modified by the user.  These components can,
+    however, be voluntarily used by merchants, customers or payment processors
+    to increase their operational security.
+
+  \item \textbf{A CBDC must protect the privacy of buyers.}\label{item:privacy}
+
+    Privacy should be guaranteed via technical measures, as opposed to mere
+    policies.  Especially with micropayments for online content, a
+    disproportionate amount of rather private data about buyers would be 
revealed, if
+    the payment system does not have privacy protections.
+
+    In legislations with data protection regulations (such as the recently 
introduced GDPR in Europe~\cite{voigt2017eu}),
+    merchants benefit from this as well, as no data breach of customers can 
happen if this information
+    is, by design, not collected in the first place.  Obviously some private 
data, such as the shipping
+    address for a physical delivery, must still be collected according to 
business needs.
+
+    The security of the payment systems also benefits from this, as the model
+    shifts from authentication of customers to mere authorization of payments.
+    This approach rules out whole classes of attacks such as 
phishing~\cite{garera2007framework} or credit
+    card fraud~\cite{sahin2010overview}.
+
+  \item \textbf{A CBDC must enable the state to tax income and crack down on
+    illegal business activities.}
+
+    Naturally, a central bank cannot deploy a payment system that does not
+    meet broadly accepted rules and regulations for payment systems. While
+    it is conceivable that specific rules and regulations may be modified to
+    accomodate a CBDC, it is inconceivable that states would relax the rules
+    to the point where businesses receiving income are not held accountable
+    for their actions, especially as there seems to be a broad consensuse that
+    levying of taxes based on economic activity is beneficial to society.
+
+  \item \textbf{A CBDC must prevent payment fraud.}
+
+    This imposes requirements on the security of the system, as well as on the
+    general design, as payment fraud can also happen through misleading user
+    interface design or the lack of cryptographic evidence for certain
+    processes.
+
+  \item \textbf{A CBDC must only disclose the minimal amount of information
+    necessary.}
+
+    The reason behind this goal is similar to (\ref{item:privacy}).  The
+    privacy of buyers is given priority, but other parties such as merchants
+    still benefit from it, for example, by keeping details about the 
merchant's financials
+    hidden from competitors.  Similarly, the central bank should not know
+    all the details of say the contract between a merchant and a consumer, and
+    only learn the amount transacted. Other state agencies, such as the tax
+    office during a tax audit, may be able to compell merchants to disclose
+    additional information, but again always only the minimal amount necessary
+    for the specific function.
+
+  \item \textbf{A CBDC must be usable.}
+
+    Specifically it must be usable for non-expert customers, such as children.
+    We note that account-based payments are generally not accessible to
+    children, as they are often unable to open a regular bank account under
+    current rules.  This alone is a good reason for a CBDC to not be
+    account-based! Usability also
+    applies to the integration with merchants, and informs choices about the
+    architecture, such as encapsulating procedures that require cryptographic
+    operations into an isolated component with a simple API.
+
+  \item \textbf{A CBDC must be efficient.}
+
+    Approaches such as proof-of-work are ruled out by this requirement.  
Efficiency is
+    necessary for a CBDC to scale to the hundreds of thousands of transactions
+    required to support larger economic areas. Efficient payments can also open
+    up new use-cases by enabling micropayments.
+
+  \item \textbf{A CBDC must avoid single points of failure.}
+
+    While a central bank is itself kind-of a single point of failure and 
inherent
+    in a CBDC, the technical deployment should avoid single
+    points of failure.  This manifests in architectural choices such as
+    the isolation of certain components, and auditing procedures.
+
+  \item \textbf{A CBDC must foster competition.}
+
+    It must be relatively easy for various commercial businesses to operate
+    components of the overall payment system.  While the
+    barriers for this in traditional financial systems are rather high, the
+    technical burden for new operators to join must be minimized. Operators
+    may incluce licensed entities such as banks (for operations that are 
closely
+    related to the payment processing), but also unlicensed entities can 
partake
+    in activities such as enabling backups or integrating payment services at
+    retailers.  A design choice that supports this is to split the whole 
system into smaller
+    components with well-defined protocols between them, such that the various
+    components can be operated, developed and improved upon independently,
+    instead of having one completely monolithic system.
+
+\end{enumerate}
 
 In our opinion, any candidate for CBDC must follow at least those principles
-to be trustworthy and successful.  And privacy in digital payments can be done
-right: Token-based payments like GNU Taler offer an alternative to
+to be trustworthy and successful.
+
+A cross-cutting concern here is that when achieving the security goals, the
+CBDC must never rely on the central bank being trustworthy. Good security
+designs always strive to avoid trusted parties. This implies that neither the
+correctness nor the privacy assurances must rely on an honest central
+bank. Michael Hayden (the former head of the CIA and NSA) famously made the
+mistake of asserting that with respect to control over the toxic data assets
+accumulated by the NSA ``nobody comes after us''~\cite{jake2022}, suggesting
+that the (by Mr. Hayden presumed trustworthy) US government would never
+fall. This false assumption quickly turned deadly when the Taliban took over
+personal profiles including biometric data of Afgahnis that had collaborated
+with NATO forces after the retreat of NATO in 2021~\cite{afganistan2022}.  We
+must not make the same mistake, that is believing that our institutions are
+good and eternal, when it comes to out private payment data. Thus, it is
+necessary that technical protections for our privacy are put in place that
+even the central bank cannot break:
+
+Privacy is most meaningful when it is guaranteed via technical measures, as
+opposed to mere policies. Without a technical layer providing
+privacy-by-default, financial transactions reveal unnecessary levels of
+personal or private data. This would be especially true if a CBDC became a
+ubiquitous payment method. Thus, a CBDC must protect the privacy of buyers and
+avoid the use of accounts to avoid facilitating totalitarian control over the
+population.  Limited private data, such as the shipping address for a physical
+delivery, may need to be collected by merchants (but not the central bank)
+according to business needs and protected according to local laws. In this
+case, the CBDC must enable deletion of such data as soon as it is no longer
+required.
+
+\section{GNU Taler}
+
+We have implemented the GNU Taler token-based payment system based on the
+above principles~\cite{dold2019}. GNU Taler offers an alternative to
 ID/account-based systems, while still enabling the state to ensure business is
 legal (and tax-paying) without infringing on the soverenity of private
 citizens.
 
 In addition, CBDCs should also provide additional benefits compared to existing
-digital payment systems.  For example, GNU Taler has recently extended the
-principle of strictly protected privacy also into the domain of age
-restrictions in e-commerce~\cite{designagerestriction2021}.  This extension
-offers benefits for society in multiple ways:  Buyers remain anonymous during
-payment, yet efficacy of age restriction is guaranteed.  Anonmyous age
-restriction during payment simplifies processees for merchants significantly.
-It is based on the principle of subsidiarity and gives control over age
-restriction to closest responsible persons (generally the parents).  And
-finally, for more than 5 million children in the EU between 10 and
-18~\cite{EurostatAge10} this would allow participation in e-commerce more
-freely.
-
-% [oec] Maybe too much detail?:
-%
-%Assuming that owners of bank-accounts are mature adults, it allows them to
-%withdraw age-restricted coins for their wards.  The wards can then anonymously
-%spend the coins, but transactions will fail at merchants that sell goods with
-%an age restriction exceeding the age-limit of the coins as specified by the
-%bank account holder, acting as a guardian.  This design guarantees that the
-%only information disclosed is that the age-restriction imposed by the merchant
-%is satisfied - but not the age itself. The payment service provider does not
-%even learn that age-restrictions are being used, and merchants cannot
-%distinguish successful purchases by adults from successful purchases by wards
-%with a sufficiently high age-limit.  Thus, this design offers a clear
-%alternative to identity-based age-verification that is better aligned with the
-%principle of subsidiarity which requires that we solve problems at the 
smallest
-%unit that can solve them.  And protecting the children should be the task of
-%their parents. We argue that the ECB should merely give the parents the
-%technical means to protect their children as they see fit, instead of taking
-%control.
+digital payment systems. One of the key questions the ECB report raises is
+what it might take for a CBDC to be successful in the market, as the authors
+realize that even if a central bank offers a payment system, this does not
+assure that the population will adopt it to a meaningful extend.
+
+So far, we have already given several reasons for adoption, including the use
+of Free Software, the protection of privacy, usability and cost-effectiveness.
+Furthermore, we believe that a CBDC should also strongly consider the issue of
+inclusion, from children to illiterate or innumerate users which are
+underserved by contemporary commercial payment solutions. We have recently
+started to work on this challenge by extending the principle of strictly
+protected privacy also into the domain of age restrictions in
+e-commerce~\cite{designagerestriction2021}.  This extension offers benefits
+for society in multiple ways: Buyers remain anonymous during payment, yet
+efficacy of age restriction is guaranteed.  Anonmyous age restriction during
+payment simplifies processees for merchants significantly.  It is based on the
+principle of subsidiarity and gives control over age restriction to closest
+responsible persons (generally the parents).  And finally, for more than 5
+million children in the EU between 10 and 18~\cite{EurostatAge10} this would
+allow participation in e-commerce more freely.
+
+Assuming that owners of bank-accounts are mature adults, it allows them to
+withdraw age-restricted coins for their wards.  The wards can then anonymously
+spend the coins, but transactions will fail at merchants that sell goods with
+an age restriction exceeding the age-limit of the coins as specified by the
+bank account holder, acting as a guardian.  This design guarantees that the
+only information disclosed is that the age-restriction imposed by the merchant
+is satisfied - but not the age itself. The payment service provider does not
+even learn that age-restrictions are being used, and merchants cannot
+distinguish successful purchases by adults from successful purchases by wards
+with a sufficiently high age-limit.  Thus, this design offers a clear
+alternative to identity-based age-verification that is better aligned with the
+principle of subsidiarity which requires that we solve problems at the smallest
+unit that can solve them.  And protecting the children should be the task of
+their parents. We argue that the ECB should merely give the parents the
+technical means to protect their children as they see fit, instead of taking
+control.
 
 
 \section{Conclusion}
@@ -456,13 +615,3 @@ they should keep up even if we question their universal 
realization.
 
 Yet to integrate:
 
-Part two of the report is of a much better level, one should still note that
-the ontological difference between pure digital currencies and traditional
-currencies is not very well addressed.
-
-This report is very heterogeneous. While some sections are of a very good
-level and well documented, there are still too many approximations and very
-superficial statements about central bank digital currencies in this report.
-
-Mention somewhere French report's confusion between retail CBDC (SNB-Taler
-paper) and wholesale CBDC (Swiss Helvetia project).

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