gnunet-svn
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[taler-marketing] branch master updated: -update paper with Emergency Ac


From: gnunet
Subject: [taler-marketing] branch master updated: -update paper with Emergency Act
Date: Wed, 23 Feb 2022 14:34:59 +0100

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 76db323  -update paper with Emergency Act
76db323 is described below

commit 76db3233ab3ebbf9b4d0dc1f8db153fdd81cb923
Author: Christian Grothoff <christian@grothoff.org>
AuthorDate: Wed Feb 23 14:34:57 2022 +0100

    -update paper with Emergency Act
---
 2022-privacy/privacy.tex | 62 +++++++++++++++++++++++++++++-------------------
 1 file changed, 38 insertions(+), 24 deletions(-)

diff --git a/2022-privacy/privacy.tex b/2022-privacy/privacy.tex
index 2409edc..96d623b 100644
--- a/2022-privacy/privacy.tex
+++ b/2022-privacy/privacy.tex
@@ -233,30 +233,44 @@ its rules and regulations, this implies the bank could 
arbitrarily block
 payments by private citizens. The repressive potential of a government with
 such a capability is so large that it must be firmly rejected.
 
-Instead, we believe the question should be if central banks should limit CBDC
-issuance corresponding to their mission instead of adapting it.  Wisely, the
-US Federal Reserve is currently barred from maintaining digital account
-balances for individuals~\cite{usfed2022}, which limits its ability to issue a
-retail CBDC. We consider this law wise, as we will next argue that tightly
-coupling payments with identity is harmful. Furthermore, the law does not seem
-to prevent the Federal Reserve from issuing a token-based privacy-respecting
-CBDC.
-
-
 \section{Harmful coupling with identity}
 \label{sec:coupling}
-A harmful idea emerging from the ECB report is ``combining use of
-digital identity and CBDC''. The same idea is echoed in the French report
-which quotes an unpublished report from Catenae (2020) 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''\footnote{il est difficile d'envisager la
-  création d'une monnaie numérique de banque centrale de détail, et plus
-  particulièrement d’un ``euro numérique'', sans création préalable d'une
-identité numérique fiable, s\'ecuris\'ee et offrant les garanties
- nécessaires}. From a technical perspective, the statement is hard to
-defend since current cryptocurrencies work perfectly well without depending on
-a ``trusted digital identity''.
+
+The risk is not theoretical. After the original submission of this article,
+the Emergencies Act of February 2022 granted the Canadian executive the right
+to freeze bank accounts without judicial
+oversight.\footnote{Summary by Premier Kenney: 
\url{https://www.youtube.com/watch?v=NehMAj492SA}} The
+Canadian minister of justice David Lametti promptly used this to threaten
+people on CTV News with extrajudicial asset freezes if they were making
+significant financial contributions to a political cause he strongly disagrees
+with.\footnote{\url{https://www.youtube.com/watch?v=xoTCxWSQW30}} If this is
+possible in Canada today, we do not want to imagine what might happen in less
+established democracies if an account-based CBDC were to largely displace
+cash.
+
+Consequently, the question should be if central banks should limit CBDC
+issuance within the scope of their current mission instead of modifying their
+rulebooks.  Wisely, the US Federal Reserve is currently barred from
+maintaining digital account balances for individuals~\cite{usfed2022}.  We
+consider this law wise, as we argue that tightly coupling payments with
+identity is harmful.  While the law prevents the Federal Reserve's from
+issuing an account-based retail CBDC, it does not seem to prevent the Federal
+Reserve from issuing a token-based privacy-respecting CBDC.  This is crucial,
+as the technology behind token-based privacy-respecting CBDCs would
+fundamentally not support the kind of asset freezes enabled by the Canadian
+Emergencies Act.
+
+In contrast, ECB report suggests that ``combining use of digital identity and
+CBDC'' might be beneficial. The same idea is echoed in the French report which
+quotes an unpublished report from Catenae (2020) 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''\footnote{il est difficile d'envisager la création d'une
+monnaie numérique de banque centrale de détail, et plus particulièrement d’un
+``euro numérique'', sans création préalable d'une identité numérique fiable,
+s\'ecuris\'ee et offrant les garanties nécessaires}. 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
@@ -275,8 +289,8 @@ by the authors.
 
 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 Section~\ref{sec:guardians}), the 
problem is the data
-itself.  As Bruce Schneier has concisely argued already in 2016:
+neutral custodians of citizens' privacy (see Section~\ref{sec:guardians}), 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}

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]