[taler-marketing] 02/02: merge

[gnunet]

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

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

commit d715f2955eddb929947e9694e704b97b215ef90c
Merge: f017700 62b45d2
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Mon Jan 24 00:03:27 2022 +0100

    merge

 2022-privacy/literature.bib |  28 ++++++-
 2022-privacy/privacy.tex    | 173 ++++++++++++++++++++++++++------------------
 2 files changed, 126 insertions(+), 75 deletions(-)

diff --cc 2022-privacy/privacy.tex
index c0873c4,b777a59..765760e
--- a/2022-privacy/privacy.tex
+++ b/2022-privacy/privacy.tex
@@@ -87,24 -86,16 +87,23 @@@ ignore this danger and must reestablis
  responsibility, personal independence and subsidiarity in the design processes
  for critical infrastructure created by European institutions.
  
 +% FIXME:
 +% Changed scientifically to demonstrably.
 +% It is still unclear here what "the system" is and if it would be
 +% mandatory because of technical or regulatory reasons.
 +% The monero reference is missing/wrong and I could not find ad hoc 
references.
  Here the wording of the French report is confusing, as it suggests that
  monitoring would be a mandatory component of the system, which is
- demonstrably false: There are many digital currencies that do not allow such
- surveillance, such as Monero~\cite{monero} or Taler~\cite{dold2019}.
 -scientifically false: There are many digital currencies that do not allow such
 +%FIXME dangerous for the authors? What exactly is dangerous?
 +% Maybe just say it is false? An incorrect conclusion?
- 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
++demonstrably 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
  of privacy, when this is false.
  
  Since this far-fetched assumption is taken as true while counterexamples
@@@ -163,15 -154,16 +161,16 @@@ deploying a new electronic identity sch
  
  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
 +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} Despite this well-established
- insight, the ECB report is insinuating 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
++Despite this well-established insight, the ECB report is insinuating 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
@@@ -213,42 -201,8 +212,12 @@@ Not only is this simplistic approach ra
  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}
  
 +% FIXME: This is probably true in above statements as well but
 +% whenever the report is referenced, a more specific pointer would be
 +% helpful (e.g. section, paragraph etc).
 +% I think the more accessible term (to me) here is "bank run".
  The ECB report describes the risk of (commercial) bank balance sheet
  disintermediation as one of the major risks to consider from the introduction
  of a CBDC.  Basically, the risk is that consumers loosing faith in a

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