[taler-marketing] branch master updated: minor edits, added a FIXME

[gnunet]

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

dold pushed a commit to branch master
in repository marketing.

The following commit(s) were added to refs/heads/master by this push:
     new 7a145f3  minor edits, added a FIXME
7a145f3 is described below

commit 7a145f3654fcb5aeeee6c87de69bf5965d54c450
Author: Florian Dold <florian@dold.me>
AuthorDate: Mon Mar 29 13:09:30 2021 +0200

    minor edits, added a FIXME
---
 2021-offline/offline.tex | 28 +++++++++++++---------------
 1 file changed, 13 insertions(+), 15 deletions(-)

diff --git a/2021-offline/offline.tex b/2021-offline/offline.tex
index e631faf..6c20ebc 100644
--- a/2021-offline/offline.tex
+++ b/2021-offline/offline.tex
@@ -94,7 +94,6 @@ choices:
   accessing certain functions of the device.\footnote{
     A good example for such a design is~\cite{christodorescu2020twotier}.}
 \item
-  % FIXME: this is a bit too technical
   Retroactively identifying the user after network
   connectivity is restored, in privacy-preserving systems
   using conditional deanonymization, and attempting to recoup
@@ -145,28 +144,28 @@ informational self-determination. Forcing users to use 
hardware that
 they do not control is limiting their ability to control and customize
 their digital lives.
 
-In privacy-friendly systems (like those based on
+Even in privacy-friendly systems (like those based on
 Chaum~\cite{chaum1988untraceable}) where citizens can use digital cash to
 make purchases anonymously, adding the ability to retroactively deanonymize
 double-spending users implies that accidentally double-spending (say after
-restoring from backup) voids the privacy assurances of the system. A key
-security property of the systems would thus be weakened and becomes brittle.
-
+restoring from backup) voids the privacy assurances of the system.
+% FIXME: Not clear what this refers to.  What is the security property
+% that is weakened?
+A key security property of the systems would thus be weakened and becomes 
brittle.
 
 \subsection{Hurting availability}
 
-A hardware-based solution not only limits availability to those
-users that can afford the device, but also limits user's ability
-to make backups of their digital cash. Thus, loosing the hardware
-will result in citizens loosing their digital cash, something a
-software-based solution can avoid.  This drawback can only be
-offset by revealing the user's identity which means the solution
-would not offer good privacy protections.
+A hardware-based solution not only limits availability to those users that can
+afford the device, but also limits user's ability to make backups of their
+digital cash. Thus, loosing the hardware will result in citizens loosing their
+digital cash, something a software-based solution can avoid.  This drawback can
+only be offset by revealing the user's identity to reveal a double spending
+fraud without using trusted hardware, which means the solution would not offer
+good privacy protections.
 
 Similarly, in systems where double-spending is detected and later
 penalized, the resulting financial risks will create pressures
 to deny citizens with insufficient reputation or credit score
-from using the system to mitigate operational risk.
 
 One argument for offline CBDC is the objective to improve availability
 in situations where network access is unreliable. However, today
@@ -179,7 +178,7 @@ unlikely to significantly improve availability.
 \subsection{Hurting innovation}
 
 In a world where everything is headed towards software solutions, a
-mandatory hardware security solution for a CBDC is pretty restrictive,
+mandatory hardware security solution for a CBDC is restrictive,
 not just for customers but also for businesses who want to process
 payments or offer services related to payments.  Furthermore, to
 ensure the security of the solution, the production of approved
@@ -209,7 +208,6 @@ adding offline payment systems have inherent and severe 
risks.
 The exposure to these risks should be limited by only resorting to an offline
 fallback mode of the payment system when actually required.
 
-% FIXME:  Probably this is not explained well enough
 Discouraging the use of the offline fallback mode can be easily achieved by by
 exposing the payee to counterparty risk.  In a system based on restricted
 hardware elements, the payee would bear the risk in case of a compromised

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