commit 805adb221b9be924f723a85f630ae23a767d53c8
parent 527a8c3fd9f9a49dbaa9fb7001136b1d027d92bd
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Fri, 28 Jan 2022 17:07:11 +0100
comments;typos
Diffstat:
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/2022-privacy/privacy.tex b/2022-privacy/privacy.tex
@@ -185,11 +185,12 @@ ignore this danger and must reestablish the principles of personal
responsibility, personal independence and subsidiarity in the design processes
for critical infrastructure created by European institutions.
+%FIXME Where?
Here the wording of the French report is confusing, as it suggests that
privacy-invasive monitoring would be a mandatory component of any CBDC, which
is demonstrably false: There are many digital currencies and payment systems
that do not allow comprehensive surveillance~\cite{monero,dold2019}. Thus, it
-is wrong for the authors of the French report to take a possible design choice
+is wrong for the authors to take a possible design choice
of an account-based system as a necessity, 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
@@ -198,7 +199,7 @@ serious mistake, as it is understood that any CBDC design would necessarily
lead to a loss of privacy, when this is false.
Since this far-fetched assumption is taken as true while counterexamples
-exists, the conclusion of the first part of the French report follows a logical fallacy.
+exist, the conclusion of the first part of the French report follows a logical fallacy.
In it, the authors ask ``Should the objectives, mandate and governance of central banks be redefined?'',
% FIXME: this is a bad quote, we should quote not a question on 'should',
% but their specific conclusion THAT the mandate needs a redefinition (if they make such a conclusion).
@@ -276,13 +277,13 @@ space for CBDCs but is exactly what is proposed.
Citizens themselves are well aware of this aspect and it consequently would
have a significant impact on acceptance of a CDBC:
The Swiss population recently rejected a proposal for a national
-E-ID~\cite{eid2021}, and the newly elected German government is promising a
-reversal of ubiquitous data retention (without cause) in
-Germany~\cite{koalitionsvertrag2021}. The European Parliament has members
+eID~\cite{eid2021}, and the newly elected German government is promising a
+reversal of ubiquitous data retention (without cause)~\cite{koalitionsvertrag2021}.
+The European Parliament has members
proposing to ban the use of facial recognition in public
spaces~\cite{euai2021}. The ECB's proposal seemingly ignores the popular
rejection of treating every citizen as a criminal suspect by doubling down.
-Payment data is typically retained for 6 or more years.
+Payment data is already typically retained for 6 or more years.
% FIXME: What is this referring to? Is it already retained 6 or more years? Is that proposed?
% That is common fact for banking in EU/US/UK and likely other states.
% That said, if someone has a good reference, that would be appreciated...
@@ -294,6 +295,8 @@ offerings already put it. If CBDC payment data is strongly coupled with our
identities, those who dislike living in a panopticon could only hope for such a
CBDC to be rarely used.
+
+% FIXME This paragraph. It conflates and rambles incoherently with a lot of ()s
But the ECB is not the only institution pushing for digital identity-based
solutions. Another domain where this is inappropriately pursued is the
decades-old debate about age-verification for Websites. The common pattern
@@ -348,6 +351,9 @@ risk, quite comparable to the risk of hoarding cash. By analyzing this risk,
citizens and businesses would themselves determine appropriate individual
limits for their CBDC holdings based on their actual cash needs.
+
+%FIXME this whole section is out of place. It is not a critique of the paper(s)
+% but it is also not a proposal of properties. Why is it here?
\section{Tokenization beyond CBDC}
\label{sec:tokenization}
@@ -454,6 +460,7 @@ We think that any CBDC must be based on the following design principles
inspired by~\cite{dold2019}, given in order of priority:
\begin{enumerate}
+ % FIXME: free software using open standards?
\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''.
@@ -488,6 +495,8 @@ inspired by~\cite{dold2019}, given in order of priority:
\item \textbf{A CBDC must protect the privacy of buyers.}\label{item:privacy}
+ % FIXME s/should/must?
+ % guaranteed??? That is too hard!
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
@@ -547,7 +556,7 @@ inspired by~\cite{dold2019}, given in order of priority:
\item \textbf{A CBDC must be efficient.}
- Approaches such as proof-of-work are ruled out by this requirement. Efficiency is
+ 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.
