[taler-marketing] branch master updated: comments;typos

[gnunet]

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

martin-schanzenbach pushed a commit to branch master
in repository marketing.

The following commit(s) were added to refs/heads/master by this push:
     new 805adb2  comments;typos
805adb2 is described below

commit 805adb221b9be924f723a85f630ae23a767d53c8
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Fri Jan 28 17:07:11 2022 +0100

    comments;typos
---
 2022-privacy/privacy.tex | 23 ++++++++++++++++-------
 1 file changed, 16 insertions(+), 7 deletions(-)

diff --git a/2022-privacy/privacy.tex b/2022-privacy/privacy.tex
index 2f50433..9fb47e1 100644
--- 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.

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