krista pass

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