aboutsummaryrefslogtreecommitdiff
path: root/articles
diff options
context:
space:
mode:
Diffstat (limited to 'articles')
-rw-r--r--articles/ui/ui.tex43
1 files changed, 23 insertions, 20 deletions
diff --git a/articles/ui/ui.tex b/articles/ui/ui.tex
index 5060de2ee..a6ba08491 100644
--- a/articles/ui/ui.tex
+++ b/articles/ui/ui.tex
@@ -141,8 +141,9 @@ transactions involving the exchange of physical goods. Consequently,
if we want to associate payments with these types of transactions, we
face the challenge of reducing the mental and technical overheads of
existing payment systems. For example, executing a 3DS payment
-process (Figure~\ref{fig:cc3ds}) takes too long, is way too complex
-and way to expensive to be used for payment for typical Web articles.
+process (Figure~\ref{fig:cc3ds}) takes too long, is way too complex,
+and way too expensive to be used for payment for typical Web articles.
+%KG: Define 3DS. I have no idea WTF you're talking about throughout the paper with this.
Addressing this problem is urgent: ad-blocking technology is eroding
advertising as a substitute for micropayments~\cite{adblockblocks},
@@ -166,23 +167,23 @@ means that for any transaction the state can easily obtain the
necessary information about the identity of the merchant and the
respective contract in order to levy income, sales, or value-added
taxes. Taler uses blind signatures~\cite{chaum1983blind} to create
-digital coins, and a new {\em refresh} protocol~\cite{talercrypto} to
+digital coins and a new {\em refresh} protocol~\cite{talercrypto} to
allow giving change and refunds while maintaining unlinkability.
This paper will not consider the details of Taler's cryptographic
protocols.\footnote{Details of the protocol are documented at
\url{https://api.taler.net/}} The basic cryptography behind
blind-signature based payment systems has been known for over 25
-years~\cite{chaum1990untraceable}. However, only in 2015 the W3c
+years~\cite{chaum1990untraceable}. However, it was not until 2015 that the W3C
started the payments working group~\cite{pigs} to explore requirements
for deploying payment systems that are more secure and easy to use for
the Web. Our work describes how a modern payment system using blind
signatures could practically be integrated with the modern Web to
-improve usability, security and privacy. This includes the challenge
+improve usability, security, and privacy. This includes the challenge
of hiding the cryptography from the users, integrating with modern
browsers, integrating with Web shops, providing proper cryptographic
proofs for all operations, and handling network failures. We explain
-our design using terms from existing {\em mental models} users have
+our design using terms from existing {\em mental models} that users have
from widespread payment systems.
%\newpage
@@ -215,7 +216,7 @@ based on resources from the W3C payment interest group.
Cash has traditionally circulated by being passed directly from buyers
to sellers with each seller then becoming a buyer. Thus, cash is
-inherently a {\em peer-to-peer} payment system as participants all
+inherently a {\em peer-to-peer} payment system, as participants all
appear in both buyer and seller roles, just at different times.
However, this view is both simplified and
somewhat dated.
@@ -246,7 +247,7 @@ for the customer. Instead, the merchant provides paper
{\em receipts}, which are generated independently and do not receive
the same anti-forgery protections that are in place for cash.
-Against most attacks, customers and merchants {\em limit} their risks
+Against most attacks, customers and merchants {\em limit} their risk
to the amount of cash that they carry or accept at a given
time~\cite{Bankrate}. Additionally, customers are advised to choose
the ATMs they use carefully, as malicious ATMs may attempt to
@@ -266,6 +267,7 @@ issued by the customer's bank.
\caption{Card payment processing with 3DS. (From: W3C Web Payments IG.)}
\label{fig:cc3ds}
\end{figure*}
+%KG: I hope they can print this larger, because this is WAY too small to be of any use.
Credit and debit card payments operate by the customer providing their
credentials to the merchant. Many different authentication and
@@ -286,13 +288,14 @@ entering the credit card details like the owner's name, card number,
expiration time, CCV code, and billing address; and {(4.)}
(optionally) authorizing the transaction via mobile TAN, or by
authenticating against the customer's bank. Due to the complexity
-of this the data entry is often performed on a Web site that
+of this, the data entry is often performed on a Web site that
is operated by a third-party payment processor and {\em not} the merchant or
the customer's bank. Figure~\ref{fig:cc3ds} shows a typical card-based payment
process on the Web using the UML style of the W3C payment interest
group~\cite{pigs}. Most of the details are not relevant to this
paper, but the diagram nicely illustrates the complexity of the common
3-D secure (3DS) process.
+%KG: Define 3DS the FIRST time you use it.
Given this process, there is an inherent risk of information leakage
of customers' credentials. {\em Fraud detection} systems attempt to detect
@@ -325,9 +328,9 @@ malicious merchants to later change the terms of the contract.
Beyond these primary issues, customers face secondary risks of
identity theft from the personal details exposed by the authentication
procedures. In this case, even if the financial damages are ultimately
-covered by the bank, the customer always has to deal with the hassle
+covered by the bank, the customer always has to deal with the procedure
of {\em notifying} the bank in the first place. As a result,
-customers must remain wary about using their card, which limits their
+customers must remain wary about using their cards, which limits their
online shopping~\cite[p. 50]{ibi2014}.
% There is nevertheless a trend towards customers preferring cards
% over cash even in face-to-face purchases \cite{} in part because
@@ -515,7 +518,7 @@ ago, cryptographers have viewed blind signatures as the optimal
cryptographic primitive for privacy-preserving consumer-level transaction systems.
However, previous transaction systems based on blind signatures have
failed to see widespread adoption. This paper details strategies for
-hiding the cryptography from users and integrating smoothly with the
+hiding the complexity of the cryptography from users and integrating smoothly with the
Web, thereby providing crucial steps to bridge the gap between good
cryptography and real-world deployment.
@@ -562,7 +565,7 @@ hold, and spend coins. Wallets manage the customer's accounts
at the exchange, and keep receipts in a transaction history. Wallets can be
realized as browser extensions, mobile Apps or even in custom
hardware. If a user's digital wallet is compromised, the current
-balance may be lost, just like with an ordinary wallet containing cash.
+balance may be lost, just as with an ordinary wallet containing cash.
A wallet includes a list of trusted auditors, and will warn
users against using an exchange that is not certified by a trusted
auditor.
@@ -591,9 +594,9 @@ auditor.
customers to withdraw anonymous digital coins,
and merchants to deposit digital coins, in exchange for
bank money. Coins are signed by the exchange using
-a blind signing scheme~\cite{chaum1983blind}. Thus, only
+a blind signature scheme~\cite{chaum1983blind}. Thus, only
an exchange can issue new coins, but coins cannot be traced back
-to the customer that withdrew them.
+to the customer who withdrew them.
Furthermore, exchanges learn the amounts withdrawn by customers
and deposited by merchants, but they do not learn the relationship
between customers and merchants. Exchanges perform online detection
@@ -606,7 +609,7 @@ by customers' wallets. Merchants deposit these coins at the
exchange used by the customer in return for a bank wire
transfer of their value. While the exchange is determined by
the customer, the merchant's contract specifies the currency,
-a list of accepted auditors and the maximum exchange deposit
+a list of accepted auditors, and the maximum exchange deposit
fee the merchant is willing to pay. Merchants consist of a
{\em frontend}, which interacts with the customer's wallet, and a {\em
backend}, which interacts with the exchange. Typical frontends include
@@ -653,7 +656,7 @@ operation. Restarting the browser is not required.
As with cash, the customer must first withdraw digital coins
(Figure~\ref{fig:taler-withdraw}). For this, the customer must first
visit the bank's online portal. Here, the bank will
-typically require some form of authentication, the specific method
+typically require some form of authentication; the specific method
used depends on the bank (Figure~\ref{subfig:login}).
The next step depends on the level of Taler support offered by the bank:
@@ -671,8 +674,8 @@ The next step depends on the level of Taler support offered by the bank:
54-character reserve key, which includes 256 bits of entropy and an
8-bit checksum into the transfer subject. Naturally, the above is
exactly the kind of interaction we would like to avoid for
- usability reason.
-\item Hence, if the bank fully supports Taler, the
+ usability reasons.
+\item Otherwise, if the bank fully supports Taler, the
customer has a form in the online banking portal in which they can specify
an amount to withdraw (Figure~\ref{subfig:withdraw}).
The bank then triggers an interaction with
@@ -1547,7 +1550,7 @@ at \url{https://demo.taler.net/}.
This work benefits from the financial support of the Brittany Region
(ARED 9178) and a grant from the Renewable Freedom Foundation. We
thank Bruno Haible for his financial support enabling us to
-participate with the W3c payment working group. We thank the W3c
+participate with the W3c payment working group. We thank the W3C
payment working group for insightful discussions about Web payments.
We thank Krista Grothoff and Neal Walfield for comments on an earlier
draft of the paper. We thank Gabor Toth for his help with the