aboutsummaryrefslogtreecommitdiff
path: root/articles/ui
diff options
context:
space:
mode:
authorChristian Grothoff <christian@grothoff.org>2016-08-25 17:37:49 +0200
committerChristian Grothoff <christian@grothoff.org>2016-08-25 17:37:49 +0200
commitb4f3dbc56841dddba11458b80cd551f39f80bd2f (patch)
tree6b050b288cfcbcaa43e3e3e039cbee1069863be2 /articles/ui
parent481f9ff554af9acb14fe4ab29aa57ed102c91ea4 (diff)
minor edits
Diffstat (limited to 'articles/ui')
-rw-r--r--articles/ui/ui.tex50
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