minor edits

1 files changed, 23 insertions, 27 deletions

diff --git a/articles/ui/ui.tex b/articles/ui/ui.tex
index 7bf0c1a2d..3167e7465 100644
--- a/articles/ui/ui.tex
+++ b/articles/ui/ui.tex
@@ -272,7 +272,7 @@ credentials to the merchant.  Many different authentication and
 authorization schemes are in use in various combinations. Secure
 systems typically combine multiple forms of authentication including
 secret information, such as personal identification numbers (PINs),
-transaction numbers (TANs)~\cite{kolbil2016tan} or credit card
+transaction numbers (TANs)~\cite{kobil2016tan} or credit card
 verification (CCV) codes, and physical security devices such cards
 with an EMV chip~\cite{emv}, TAN generators, or the customer's mobile
 phone~\cite{mtan}.  A typical modern Web payment process involves:
@@ -422,12 +422,12 @@ volatile.~\cite{jeffries_economists_v_btc,lehmann_btc_fools_gold,lewis_btc_is_ju
 Bitcoin's pseudononymity applies equally to both customers and
 merchants, which makes Bitcoin amen\-able to tax evasion, money
 laundering, sales of contraband, and especially extorion
- \cite{NYA:CyberExtortionRisk}.  
+ \cite{NYA:CyberExtortionRisk}.
 As a result, anonymity tools like mixnets do not enjoy widespread
 support in the Bitcoin community where many participants seek to make
 the currency appear more legitimate.  While Bitcoin's transactions
 are difficult to track, there are several examples of Bitcoin's
-pseudononymity being broken by investigators~\cite{BTC:Anonymity}.  
+pseudononymity being broken by investigators~\cite{BTC:Anonymity}.
 This has resulted in the development of new protocols with better
 privacy protections.
 
@@ -569,16 +569,16 @@ auditor.
 
 \begin{figure}[b!]%[36]{R}{0.5\linewidth}
 \subfloat[Bank login. (Simplified for demonstration.)]{
-\includegraphics[width=0.45\linewidth]{figs/bank0a.png}
+\includegraphics[width=0.4\linewidth]{figs/bank0a.png}
 \label{subfig:login}} \hfill
 \subfloat[Specify amount to withdraw. (Integrated bank support.)]{
-\includegraphics[width=0.45\linewidth]{figs/bank1a.png}
+\includegraphics[width=0.4\linewidth]{figs/bank1a.png}
 \label{subfig:withdraw}} \\
 \subfloat[Select exchange provider. (Generated by wallet.)]{
-\includegraphics[width=0.45\linewidth]{figs/bank2a.png}
+\includegraphics[width=0.4\linewidth]{figs/bank2a.png}
 \label{subfig:exchange}} \hfill
 \subfloat[Confirm transaction with a PIN. (Generated by bank.)]{
-\includegraphics[width=0.45\linewidth]{figs/bank3a.png}
+\includegraphics[width=0.4\linewidth]{figs/bank3a.png}
 \label{subfig:pin}}
 \caption{Required steps in a Taler withdrawal process.}
 \label{fig:withdrawal}
@@ -848,16 +848,13 @@ provided by the merchant (Figure~\ref{subfig:fulfillment}).
 The Taler wallet operates from a securely isolated {\em background}
 context on the client side.  The user interface that displays the
 contract and allows the user to confirm the payment is displayed by
-this background context.  If the user accepts, the resulting signed
-coins are transferred from the client to the merchant's server.
-
-By running in the background context, the wallet can perform the
-cryptographic operations protected from the main process of the Web
-site.  In particular, this architecture is secure against a merchant
-that generates a page that looks like the wallet's payment page
-(Figure~\ref{subfig:payment}), as such a page would still not have
-access to the private keys of the coins that are exclusive to the
-background context.
+this background context.  By running in the background context, the
+wallet can perform the cryptographic operations protected from the
+main process of the Web site.  In particular, this architecture is
+secure against a merchant that generates a page that looks like the
+wallet's payment page (Figure~\ref{subfig:payment}), as such a page
+would still not have access to the private keys of the coins that are
+exclusive to the background context.
 
 %The current Taler specification is written to accommodate for
 %the rather restrictive set of APIs that WebExtension, a
@@ -992,8 +989,8 @@ While our design requires a few extra roundtrips,
 it has the following key advantages:
 \begin{itemize}
   \item It works in the confines of the WebExtensions API.
-  \item It supports restoring session state for bookedmarked
-    web resources when session state is cleared in the user agent.
+  \item It supports restoring session state for bookmarked
+    Web resources even after the session state is lost by the user agent.
   \item Sending deep links to fullfilment or offer pages to
     other users has the expected behavior
     of asking the other user to pay for the resource.
@@ -1005,7 +1002,7 @@ it has the following key advantages:
     the fulfillment page begins with processing an accepted contract.  It is thus
     possible for these pages to be managed by separate parties. The
     control of the fulfillment page over the transmission of the payment
-    information minimizes the need for exceptions to handle cross-origin
+    data minimizes the need for exceptions to handle cross-origin
     resource sharing~\cite{rfc6454,cors}.
   \item The architecture supports security-conscious users that may have
     disabled JavaScript, as it is not necessary to execute JavaScript
@@ -1040,7 +1037,7 @@ obtaining change is automatic and handled by the wallet, i.e., if the
 user has a single coin worth \EUR{5} and wants to spend \EUR{2}, the
 wallet may request three \EUR{1} coins in change. Critically, the
 change giving process is completely hidden from the user.
-In fact, the graphical user
+In fact, our graphical user
 interface does not offer a way to inspect the denominations of the
 various coins in the wallet, it only shows the total amount available
 in each denomination.  Expanding the views to show details may show
@@ -1130,17 +1127,16 @@ This dramatically simplifies setting up a shop to the point that the
 respective software only needs to be provided with the merchant's wire
 transfer routing information to become operational.
 
-Figure~\ref{listing:presence} shows how easy it is for a Web site to
-detect the presence of a Taler wallet.  The payment process requires a
+The payment process requires a
 few cryptographic operations on the side of the merchant, such as
 signing a contract and verifying the customer's and the exchange's
 signatures.  The merchant also needs to store transaction data, in
 particular so that the store can match sales with incoming wire
-transfers from the exchange.  Taler simplifies this for merchants by
+transfers from the exchange.  We simplify this for merchants by
 providing a generic payment processing {\em backend} for the Web
 shops.
 
-\begin{figure*}[t!]
+\begin{figure*}[b!]
 \begin{center}
 \begin{tikzpicture}[
   font=\sffamily,
@@ -1199,7 +1195,7 @@ passes it to the wallet (sample code for this is shown in
 Figure~\ref{listing:contract}).
 
 Instead of adding any cryptographic logic to the merchant frontend,
-the generic Taler merchant backend allows the implementor to delegate
+the Taler merchant backend allows the implementor to delegate
 coin handling to the payment backend, which validates the coins,
 deposits them at the exchange, and finally validates and persists the
 receipt from the exchange.  The merchant backend then communicates the
@@ -1208,7 +1204,7 @@ for executing the business logic to fulfill the order.  As a result of
 this setup (Figure~\ref{fig:frobearch}), the cryptographic details
 of the Taler protocol do not have to be re-implemented by each
 merchant.  Instead, existing Web shops implemented in a multitude of
-programming languages can straightforwardly add support for Taler by:
+programming languages can add support for Taler by:
 {\bf (0)} detecting in the browser that Taler is available; {\bf (1)}
 upon request, generating a contract in JSON based on the shopping
 cart; {\bf (2)} allowing the backend to sign the contract before