gnunet-svn
[Top][All Lists]
Advanced

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

[taler-marketing] branch master updated: tone down wording a bit


From: gnunet
Subject: [taler-marketing] branch master updated: tone down wording a bit
Date: Mon, 14 Feb 2022 23:15:09 +0100

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 4082fe3  tone down wording a bit
4082fe3 is described below

commit 4082fe32614db373674e3b0261641d6c33947917
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Mon Feb 14 23:15:05 2022 +0100

    tone down wording a bit
---
 2022-privacy/privacy.tex | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/2022-privacy/privacy.tex b/2022-privacy/privacy.tex
index e48e382..0367794 100644
--- a/2022-privacy/privacy.tex
+++ b/2022-privacy/privacy.tex
@@ -41,7 +41,7 @@ project to succeed.
 
 Along the same lines, the French National Council for Digitalization published
 a report on ``Notes and Tokens, The New Competition of
-Currencies''~\cite{french2021}.  Here, the authors make similar false
+Currencies''~\cite{french2021}.  Here, the authors make similar
 assumptions about inevitable properties of Central Bank Digital Currencies
 (CBDCs), going as far as stating that a CBDC is not possible without an eID
 system.  Our paper sets the record straight.
@@ -167,7 +167,7 @@ European System of Central Banks (ECBS) itself and within 
Europe, it is clear
 that the ECB's is caught in a dangerous self-delusion of central banks being
 politically neutral and public-minded institutions.
 
-This delusion is dangerous because it leads to the ECB trusting itself with
+This assumption is a dangerous conjecture because it leads to the ECB trusting 
itself with
 information and decisions that it must be entrusted with.  In particular, the
 authors write that the ECB ``may also prefer the (...) the ability to control
 the privacy of payments data''. This is a fundamental misconception of the
@@ -176,9 +176,9 @@ if they themselves have control over their payment data. 
Privacy and the human
 right of informational self-determination requires that each (legally capable)
 citizen is in control of their personal data.  The ECB asserting the ``ability
 to control the privacy'' is thus an oxymoron: once anyone else has control,
-citizens have no privacy.  As an institution that claims to act in the public
-interest, the ECB's report thus shows a fundamental lack of respect of its
-sovereign: the European citizens.
+citizens have no privacy.
+Any institution that strives to act in the public must acknowledge this or
+otherwise risk infantilizing its sovereign: the European citizens.
 
 The French report~\cite{french2021} correctly states that a Digital Euro based
 on accounts poses ``democratic risks''\footnote{risques démocratiques} and 
could allow ``state surveillance of
@@ -209,7 +209,7 @@ 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.
 
-Since this far-fetched assumption is taken as true while counterexamples
+Since this conjecture is taken as fact while counterexamples
 exists, the conclusion of the first part of the French report follows a
 logical fallacy.  The authors assert that ``the new properties of CBDC raise
 political questions''\footnote{``Dans un contexte où les nombreux projets 
d’émettre
@@ -240,7 +240,7 @@ CBDC.
 
 \section{Harmful coupling with identity}
 \label{sec:coupling}
-The arguably most dangerous idea of the ECB report is ``combining use of
+The arguably most dangerous 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
@@ -248,7 +248,7 @@ 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 
+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''.
@@ -323,7 +323,7 @@ fixed low limit would strangle the utility of the CBDC, 
while a fixed high
 limit may not be effective. They then propose a dynamic limit which they would
 ``calculate in accordance to (...) presumed cash needs''.
 
-Here, the ECB fails to learn the hard lessons from the introduction of $CO_2$
+Here, the authors fail to learn the hard lessons from the introduction of 
$CO_2$
 emissions certificates, where initial allocations were calculated based on
 ``presumed emission needs'' of certain industries, resulting in windfalls for
 shifty polluters that managed to rig the calculations, giving them excess
@@ -397,7 +397,7 @@ inspired by~\cite{dold2019}, given in order of priority:
     % FIXME: I'd suggest a comma after 'possible',
     % otherwise 'possible' might be understood as
     % a adjective for 'privacy'.
-    Where possible privacy should be guaranteed via technical measures as 
opposed to mere
+    Where possible, privacy should be guaranteed via technical measures as 
opposed to mere
     organizational 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.

-- 
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]