[taler-marketing] branch master updated: added design principles, shortened age restriction

[gnunet]

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

oec pushed a commit to branch master
in repository marketing.

The following commit(s) were added to refs/heads/master by this push:
     new 62b45d2  added design principles, shortened age restriction
62b45d2 is described below

commit 62b45d25ea74565265b092c8be28e9c86179f786
Author: Özgür Kesim <oec-taler@kesim.org>
AuthorDate: Sun Jan 23 23:39:24 2022 +0100

    added design principles, shortened age restriction
---
 2022-privacy/literature.bib |  28 ++++++-
 2022-privacy/privacy.tex    | 175 ++++++++++++++++++++++++++------------------
 2 files changed, 127 insertions(+), 76 deletions(-)

diff --git a/2022-privacy/literature.bib b/2022-privacy/literature.bib
index 527e364..7e14cd9 100644
--- a/2022-privacy/literature.bib
+++ b/2022-privacy/literature.bib
@@ -31,14 +31,14 @@
   month =     {May},
 }
 
-@Article{french2021,
-  author =       {Gilles DOWEK and Elisabeth GROSDHOMME and Joëlle TOLEDANO 
and 
https://cnnumerique.fr/nos-travaux/billets-et-jetons-la-nouvelle-concurrence-des-monnaies},
+@article{french2021,
+  author =       {Gilles Dowek and Elisabeth Grosdhomme and Joëlle Toledano},
   title =        {Billets et jetons --- La Nouvelle concurrence des monnaies},
   journal =      {Counseil National Du Numerique},
   year =         {2021},
   pages =     {44},
   month =     {November},
-  note =      
{\url{https://cnnumerique.fr/nos-travaux/billets-et-jetons-la-nouvelle-concurrence-des-monnaies}},
+  note = 
{\url{https://cnnumerique.fr/nos-travaux/billets-et-jetons-la-nouvelle-concurrence-des-monnaies}},
 }
 
 @Misc{rugpull,
@@ -371,3 +371,25 @@ series = {SEC'16}
        
howpublished={\url{https://www.spd.de/fileadmin/Dokumente/Koalitionsvertrag/Koalitionsvertrag_2021-2025.pdf}},
        year={2021},
 }
+
+@Misc{designagerestriction2021,
+       title={{Anonymous Age Restriction Extension for GNU Taler}},
+       author={\"Ozg\"ur Kesim},
+       
howpublished={\url{https://docs.taler.net/design-documents/024-age-restriction.html}},
+       journal={{GNU Taler Design documents}},
+       year={2021},
+}
+
+@Misc{talerPrinciples,
+       title={GNU Taler: Design Principles},
+       author={{GNU Taler Authors}},
+       howpublished={\url{https://taler.net/en/principles.html}},
+       year={2014},
+}
+
+@misc{EurostatAge10,
+  author       = {Eurostat},
+  title        = {{Population on 1 January by age and sex (Europa, 
Altersgruppe 10)}},
+  howpublished = {Webpräsenz von Eurostat},
+  url          = {https://bit.ly/32iWEyV}
+}
diff --git a/2022-privacy/privacy.tex b/2022-privacy/privacy.tex
index 3252298..b777a59 100644
--- a/2022-privacy/privacy.tex
+++ b/2022-privacy/privacy.tex
@@ -33,7 +33,7 @@ Along the same lines, the French council scientific numerique 
published a
 report on ``Notes and Tokens, The New Competition of Currencies''.  Here, the
 authors make similar false assumptions about inevidable properties of CBDCs,
 going as far as stating that a CBDC is not possible without an E-ID
-system. Our paper attempts to set the record straight.
+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?
 }
@@ -89,13 +89,13 @@ for critical infrastructure created by European 
institutions.
 Here the wording of the French report is confusing, as it suggests that
 monitoring would be a mandatory component of the system, which is
 scientifically false: There are many digital currencies that do not allow such
-surveillance, such as Monero~\cite{monero} or Taler~\cite{dold2019}.  Thus, it 
is dangerous for the authors
-of the French report take a possible design choice of an account-based system
-as fact, for example when they write that ``the centralization and data
-tracking of central bank digital currency projects leads to a loss of privacy
-that coupled with the programmability of the currency can have serious
-consequences.''  Using the indicative here is a serious mistake, as it is
-understood that any CBDC would lead to a loss
+surveillance, such as Monero~\cite{monero} or Taler~\cite{dold2019}.  Thus, it
+is dangerous for the authors of the French report take a possible design choice
+of an account-based system as fact, for example when they write that ``the
+centralization and data tracking of central bank digital currency projects
+leads to a loss of privacy that coupled with the programmability of the
+currency can have serious consequences.''  Using the indicative here is a
+serious mistake, as it is understood that any CBDC would lead to a loss
 of privacy, when this is false.
 
 Since this far-fetched assumption is taken as true while counterexamples
@@ -128,22 +128,21 @@ CBDC.
 
 \section{Harmful coupling with identity}
 
-The probably most dangerous idea of the ECB report is ``combining use of
+The arguably most dangerous idea of the ECB report is ``combining use of
 digital identity and CBDC''. The same idea is echoed in the French report
 which quotes Catenae~\cite{catenae2020} to say that ``it is difficult to
 envisage the creation of a retail CBDC, and more specifically a Digital Euro
 without first creating a reliable, secure digital identity offering the
-necessary guarantees''.  From a technical perspective, the statement is hard 
to defend since current
-cryptocurrencies work perfectly well without depending on a ``trusted digital
-identity''.
-
-From a regulatory perspective, it is understood that institutions working with 
a Digital Euro will
-at times be legally required to establish the identity of actors. However,
-when a Digital Euro needs a digital identity for some of the actors in the
-digital currency production chain, one can use existing KYC processes of
-commercial banks or use certificates based on the
-already widely used X.509 standard, which are both
-already in common use on the
+necessary guarantees''.  From a technical perspective, the statement is hard to
+defend since current cryptocurrencies work perfectly well without depending on
+a ``trusted digital identity''.
+
+From a regulatory perspective, it is understood that institutions working with
+a Digital Euro will at times be legally required to establish the identity of
+actors. However, when a Digital Euro needs a digital identity for some of the
+actors in the digital currency production chain, one can use existing KYC
+processes of commercial banks or use certificates based on the already widely
+used X.509 standard, which are both already in common use on the
 Internet.\footnote{They correspond to the ``s'' in ``https'', for example.}
 While we can imagine a world in which a new ``trusted digital identity''
 exists, and develop new protocols for this world, this is by no means a
@@ -156,14 +155,15 @@ French report.
 What neither report appreciates is that combining payments with such a digital
 identity system would create a serious liability.  Even if central banks were
 neutral custodians of citizens' privacy (see above), the problem is the data
-itself.  As Bruce Schneier has concisely argued already in 2016: ``Data is a
-toxic asset.  We need to start thinking about it as such, and treat it as we
-would any other source of toxicity. To do anything else is to risk our
-security and privacy.''~\cite{schneier2016toxic} Despit this well-established
-insight, the ECB report is insunuating to link identities with payments which
-consequently and inevitably produces highly sensitive\footnote{Or to stick
-with Schneier's analogy, ``super-toxic''} metadata.  Referring to the toxicity
-of this metadata, Edward Snowden famously said at IETF 93 in 2019
+itself.  As Bruce Schneier has concisely argued already in 2016:
+``Data is a toxic asset.  We need to start thinking about it as such, and treat
+it as we would any other source of toxicity. To do anything else is to risk our
+security and privacy.''~\cite{schneier2016toxic}
+Despite this well-established insight, the ECB report is insunuating to link
+identities with payments which consequently and inevitably produces highly
+sensitive\footnote{Or to stick with Schneier's analogy, ``super-toxic''}
+metadata.  Referring to the toxicity of this metadata, Edward Snowden famously
+said at IETF 93 in 2019
 that \begin{quote} ``(...) we need to get away from true-name payments on the
   Internet.  The credit card payment system is one of the worst things that
   happened for the user, in terms of being able to divorce their access from
@@ -171,9 +171,8 @@ that \begin{quote} ``(...) we need to get away from 
true-name payments on the
 \end{quote}
 If the European Union wants to avoid a dystopia of the transparent citizen
 and catastrophic cases of personal data theft, it must enable citizens to put a
-firewall between their identity and their payments.
-Tightly coupling them is thus probably the worst idea so far
-proposed in the design space for CBDCs.
+firewall between their identity and their payments.  Tightly coupling them is
+thus arguably the worst idea so far proposed in the design space for CBDCs.
 
 The Swiss population recently rejected a proposal for a national
 E-ID~\cite{eid2021}, and the newly elected German government is promising a
@@ -202,36 +201,6 @@ Not only is this simplistic approach rarely
 cost-effective, but it contributes to the conversion of soverign citizens to
 digital subjects.
 
-\subsection{Privacy in payments can be done right}
-% msc: GNU Taler needs a cite. And I would even suggest to ONLY use a cite.
-% Also: The age verification plug is a stretch.
-% The example of age verification was given by this
-% paper above. How does it related to the ECB paper? Is this a strawman going
-% down here? Should this section come at the end and formulate requirements
-% that should be taken into account for a CDBC?
-Token-based payments like GNU Taler~\cite{dold2019} offer an alternative, 
enabling the state
-to ensure business is legal (and tax-paying) without infringing on the
-soverenity of private citizens.
-We recently extended this principle also into
-the domain of age-restrictions in e-commerce. %citation needed
-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{Addressing Balance Sheet Disintermediation via Self-Custody}
 
 The ECB report describes the risk of (commercial) bank balance sheet
@@ -277,20 +246,19 @@ With electronic tokens it is possible to implement 
payment systems that are
 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 (the exact problem GNU Taler 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
+are problematic, as giving change (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
 to deflate economic crises by inflating the currency at the expense of the
 working class''.\footnote{Personal communication.} It remains to be seen if
 this effective limitation on central bank policy making is ultimately
-beneficial, given the ecological cost of mining gold and the detrimental
-effect of rampant economic crises on the poor. Regardless, the idea is
-interesting as it may require governments to take a more preventative stance
-against economic crises --- and economists (naturally ignoring the global
-environmental impact of mining gold) have previously claimed that a competing
-gold-backed payment system might be inherently beneficial to the (Swiss)
-economy~\cite{nzz}.
+beneficial, given the ecological cost of mining gold and the detrimental effect
+of rampant economic crises on the poor. Regardless, the idea is interesting as
+it may require governments to take a more preventative stance against economic
+crises --- and economists (naturally ignoring the global environmental impact
+of mining gold) have previously claimed that a competing gold-backed payment
+system might be inherently beneficial to the (Swiss) economy~\cite{nzz}.
 
 Systems like Bitcoin and Ethereum that are based on distributed ledger
 technology are often confused with true token-based systems. In Bitcoin and
@@ -311,8 +279,8 @@ with e-gold it would do nothing to migitage the 
environmental cost of
 preferable choice.
 
 For the conversion between fiat currency, e-gold and Depolymerizer-tokenized
-cryptocurrencies it is likely that regulated payment service providers will be
-required to perform some kind of know-your-customer (KYC) procedure to
+cryptocurrencies it is likely that regulated payment service pro\-viders will
+be required to perform some kind of know-your-customer (KYC) procedure to
 identify their customers. However, this is no different from identification
 procedures required by banks today, and hence hardly predicated on the
 creation of a national or even global electronic identity platform with its
@@ -365,6 +333,67 @@ 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}
+
+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
+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.
+
 
 \section{Conclusion}
 

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