cleanup

1 files changed, 0 insertions, 1642 deletions

diff --git a/articles/ui/ui.tex b/articles/ui/ui.tex
deleted file mode 100644
index ccf36cdf9..000000000
--- a/articles/ui/ui.tex
+++ /dev/null
@@ -1,1642 +0,0 @@
-\documentclass{llncs}
-
-%\documentclass[twoside,letterpaper]{IEEEtran}
-\usepackage[margin=1in]{geometry}
-\usepackage[utf8]{inputenc}
-\usepackage{url}
-\usepackage{tikz}
-\usepackage{eurosym}
-\usepackage{listings}
-\usepackage{graphicx}
-%\usepackage{wrapfig}
-\usepackage[caption=false,font=normalsize,labelfont=sf,textfont=sf]{subfig}
-\usepackage{wrapfig}
-\usepackage{url}
-%\usepackage{stfloats}
-
-\usetikzlibrary{shapes,arrows}
-\usetikzlibrary{positioning}
-\usetikzlibrary{calc}
-
-% CSS
-\lstdefinelanguage{CSS}{
-  keywords={color,background-image:,margin,padding,font,weight,display,position,top,left,right,bottom,list,style,border,size,white,space,min,width, transition:, transform:, transition-property, transition-duration, transition-timing-function},
-  sensitive=true,
-  morecomment=[l]{//},
-  morecomment=[s]{/*}{*/},
-  morestring=[b]',
-  morestring=[b]",
-  alsoletter={:},
-  alsodigit={-}
-}
-
-% JavaScript
-\lstdefinelanguage{JavaScript}{
-  morekeywords={typeof, new, true, false, catch, function, return, null, catch, switch, var, if, in, while, do, else, case, break},
-  morecomment=[s]{/*}{*/},
-  morecomment=[l]//,
-  morestring=[b]",
-  morestring=[b]'
-}
-
-\lstdefinelanguage{HTML5}{
-  language=html,
-  sensitive=true,
-  alsoletter={<>=-},
-  morecomment=[s]{<!-}{-->},
-  tag=[s],
-  otherkeywords={
-  % General
-  >,
-  % Standard tags
-	<!DOCTYPE,
-  </html, <html, <head, <title, </title, <style, </style, <link, </head, <meta, />,
-	% body
-	</body, <body,
-	% Divs
-	</div, <div, </div>,
-	% Paragraphs
-	</p, <p, </p>,
-	% scripts
-	</script, <script,
-  % More tags...
-  <canvas, /canvas>, <svg, <rect, <animateTransform, </rect>, </svg>, <video, <source, <iframe, </iframe>, </video>, <image, </image>
-  },
-  ndkeywords={
-  % General
-  =,
-  % HTML attributes
-  charset=, src=, id=, width=, height=, style=, type=, rel=, href=,
-  % SVG attributes
-  fill=, attributeName=, begin=, dur=, from=, to=, poster=, controls=, x=, y=, repeatCount=, xlink:href=,
-  % CSS properties
-  margin:, padding:, background-image:, border:, top:, left:, position:, width:, height:,
-	% CSS3 properties
-  transform:, -moz-transform:, -webkit-transform:,
-  animation:, -webkit-animation:,
-  transition:,  transition-duration:, transition-property:, transition-timing-function:,
-  }
-}
-
-\date{}
-\begin{document}
-\title{Enabling Secure Web Payments with GNU Taler}
-
-
-% Not sure how to do authors with the
-% IEEEtran template correctly ...
-\author{Jeffrey Burdges \and
-Florian Dold \and
-Christian Grothoff \and
-Marcello Stanisci}
-\institute{Inria Rennes - Bretagne Atlantique \\
-\email{FIRSTNAME.LASTNAME@inria.fr}
-}
-
-\maketitle
-
-
-\begin{abstract}
-GNU Taler is a new electronic online payment system which provides
-privacy for customers and accountability for merchants. It uses an
-exchange service to issue digital coins using blind signatures,
-and is thus not subject to the performance issues that plague
-Byzantine fault-tolerant consensus-based solutions.
-
-The focus of this paper is addressing the challenges payment systems
-face in the context of the Web.  We discuss how to address
-Web-specific challenges, such as handling bookmarks and sharing of
-links, as well as supporting users that have disabled JavaScript.  Web
-payment systems must also navigate various constraints imposed by
-modern Web browser security architecture, such as same-origin policies
-and the separation between browser extensions and Web pages.  While
-our analysis focuses on how Taler operates within the security
-infrastructure provided by the modern Web, the results partially
-generalize to other payment systems.
-
-We also include the perspective of merchants, as existing systems have
-often struggled with securing payment information at the merchant's
-side.  Here, challenges include avoiding database transactions for
-customers that do not actually go through with the purchase, as well
-as cleanly separating security-critical functions of the payment
-system from the rest of the Web service.
-\end{abstract}
-
-{\bf Errata:} Corrected statement about BOLT (see footnote).
-
-\section{Introduction}
-
-The Internet needs a secure, usable and privacy-preserving
-micropayment system, which is not backed by a ``crypto currency''.
-Payment systems involving state-issued currencies have been used for
-centuries to facilitate transactions, and the involvement of the state
-has been critical as state institutions can dampen fluctuations in the
-value of the currency~\cite{dominguez1993}. Controlling money supply
-is critical to ensure stable prices that facilitate
-trade~\cite{quantitytheory1997volckart} instead of speculation~\cite{lewis_btc_is_junk}.
-
-Internet transactions, such as sending an e-mail or reading a Web
-site, tend to be of smaller commercial value than traditional
-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 3-D Secure~\cite{3DSsucks} payment
-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.
-
-Addressing this problem is urgent: ad-blocking technology is eroding
-advertising as a substitute for micropayments~\cite{adblockblocks},
-and the Big Data business model in which citizens pay with their
-private information~\cite{ehrenberg2014data} in combination with the
-deep state hastens our society's regression towards
-post-democracy~\cite{rms2013democracy}.
-
-
-The focus of this paper is GNU Taler, a new free software payment
-system designed to meet certain key ethical considerations from a
-social liberalism perspective. In Taler, the paying customer remains
-anonymous while the merchant is easily identified and thus taxable.
-Here, {\em anonymous} simply means that the payment process does not require
-any personal information from the customer, and that different
-transactions by the same customer are unlinkable.  Naturally, the
-specifics of the transaction---such as delivery of goods to a shipping
-address, or the use of non-anonymous IP-based communication---may
-still leak information about the customer's identity.  {\em Taxable}
-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
-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, it was not until 2015 that the W3C
-started the payments working group~\cite{w3cpig} 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
-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} that users have
-from widespread payment systems.
-
-%\newpage
-Key contributions of this paper are:
-\begin{itemize}
- \item A description of different payment systems using
-  common terminology, which allows us to analytically compare
-  these systems.
- \item An introduction to the Taler payment system from the
-  perspective of users and merchants, with a focus on how
-  to achieve secure payments in a way that is intuitive and
-  has adequate fail-safes.
- \item Detailed considerations for how to adapt Taler to
-  Web payments and the intricacies of securing payments
-  within the constraints of modern browsers.
- \item A publicly available free software
-  reference implementation of the presented architecture.
-\end{itemize}
-
-
-\section{Existing payment workflows}
-
-Before we look at the payment workflow for Taler, we sketch the
-workflow of existing payment systems. This establishes a common
-terminology which we will use to compare different payment processes.
-We include interaction diagrams for some of the payment systems
-based on resources from the W3C payment interest group.
-
-\subsection{Cash}
-
-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
-appear in both buyer and seller roles, just at different times.
-However, this view is both simplified and
-somewhat dated.
-
-In today's practice, cash is frequently first {\em withdrawn} from
-ATMs by customers who then {\em spend} it with merchants, who, in turn,
-{\em deposit} the cash with their respective {\em bank}.  In this
-flow, security is achieved as the customer {\em authenticates} to the
-ATM using {\em credentials} provided by the customer's bank, and the
-merchant specifies his {\em account} details when depositing the cash.
-The customer does not authenticate when spending the cash, but the
-merchant {\em validates} the authenticity of the {\em coins} or bills.
-Coins and bills are {\em minted} by state-licensed institutions, such
-as the US Mint.  These institutions also provide detailed instructions
-for how to validate the authenticity of the coins or
-bills~\cite{ezb2016ourmoney}, and are typically the final trusted
-authority on the authenticity of coins and bills.
-
-As customers need not authenticate, purchases remain {\em
-  anonymous}, modulo the limited tracking enabled in theory
-by serial numbers printed on bills~\cite{pets2004kuegler},
-which make each bill {\em unique}.
-% NOTE : Internet claims this does not happen, but no references.
-% https://rocketatm.com/notice-_recorded_serial_numbers_atm_decal
-
-Spending cash does not provide any inherent {\em proof of purchase}
-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 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
-{\em steal} their customer's credentials~\cite{ECB:TRoCF2014}.  Authentication with an
-ATM can involve a special ATM card, or the use of credit or
-debit cards.  In all these cases, these physical security tokens are
-issued by the customer's bank.
-
-
-% \smallskip
-\subsection{Credit and debit cards}
-
-\begin{figure*}[h!]
-\begin{center}
-\includegraphics[width=0.95\textwidth]{figs/cc3ds.pdf}
-\end{center}
-\caption{Card payment processing with 3-D Secure (3DS). (From: W3C Web Payments WG \cite{w3cpig})}
-\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
-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{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:
-{(1.)} the merchant offering a secure communication channel using TLS
-based on the X.509 public key infrastructure;\footnote{Given numerous
-  TLS protocol and implementation flaws as well as X.509 key
-  management incidents in recent years~\cite{holz2014}, one cannot
-  generally assume that the security provided by TLS is adequate under
-  all circumstances.}  {(2.)} selecting a {\em payment method}; {(3.)}
-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
-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{w3cpig}.  Most of the details are not relevant to this
-paper, but the diagram nicely illustrates the complexity of the common
-3-D secure 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
-misuse of stolen credentials, and payment system providers handle
-disputes between customers and merchants.  As a result, Web payment
-processes may finish with {(5.)} the payment being rejected for a
-variety of reasons, such as false positives in fraud detection or
-the merchant not accepting the particular card issuer.
-
-Traditionally, merchants bear most of the financial risk, and a key
-``feature'' of the 3DS process compared to traditional card payments
-is to shift dispute {\em liability} to the issuer of the card---who
-may then try to shift it to the customer \cite[\S2.4]{3DSsucks}.
-%
-% online vs offline vs swipe vs chip vs NFC ???
-% extended verification
-%
-Even in cases where the issuer or the merchant remain legally first in
-line for liabilities, there are still risks customers incur from the
-card dispute procedures, such as neither them nor the payment
-processor noticing fraudulent transactions, or them noticing
-fraudulent transactions past the {\em deadline} until which their bank
-would reimburse them.  The customer also typically only has a
-merchant-generated comment and the amount paid in his credit card
-statement as a proof for the transaction.  Thus, the use of credit
-cards online does not generate any cryptographically {\em verifiable}
-electronic receipts for the customer, which theoretically enables
-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 procedure
-of {\em notifying} the bank in the first place.  As a result,
-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
-% cash theft can be violent even if the amounts as stake are smaller
-% than with electronic theft.
-%
-%Merchants are exposed to these same risks because either laws and/or
-%contracts with the payment system providers require them to take care
-%in handling customer information.
-% 40 million stolen at target.  fine?
-
-%In cash payments, these risks do not exist because customers have
-%complete control over the authentication procedure with their bank
-%and the merchant is not involved.
-
-% pressure to shop with big merchants
-% merchants keep payment credentials on file
-% Just a few merchants like Apple demand credentials up front
-%  "this reversal of authentication vs shopping slows shopping"
-
-% \smallskip
-\subsection{Bitcoin}
-
-\begin{figure*}[b!]
-\includegraphics[width=\textwidth]{figs/bitcoin.pdf}
-\caption{Bitcoin payment processing. (From: W3C Web Payments WG \cite{w3cpig})}
-\label{fig:bitcoin}
-\end{figure*}
-
-Bitcoin operates by recording all transactions in a pseu\-do\-ny\-mous
-public {\em ledger}.  A Bitcoin account is identified by its public
-key, and the owner must know the corresponding private key to
-authorize the transfer of Bitcoins from the account to other accounts.
-The information in the global public ledger allows everybody to
-compute the balances in all accounts and to see all transactions.
-Transactions are denominated in a new currency labeled BTC, whose
-valuation depends upon {\em speculation}, as there is no authority
-that could act to stabilize exchange rates or force anyone to
-accept BTC as {\em legal tender} to settle obligations.  Adding transactions to
-the global public ledger involves broadcasting the transaction data,
-peers verifying and appending it to the public ledger, and some peer
-in the network solving a moderately hard computational proof-of-work
-puzzle, which is called {\em mining}.
-
-The mining process is incentivised by a combination of transaction
-fees and mining rewards~\cite{nakamoto2008bitcoin}. The latter
-process also provides primitive accumulation~\cite{primitiveacc} for BTC.
-Conversion to BTC from other currencies and vice versa incurs
-substantial fees~\cite{BTCfees}.  There is now an extreme diversity of
-Bitcoin-related payment technologies, but usability improvements are
-usually achieved by adding a trusted third party, and there have been
-many incidents where such parties then embezzled funds from their
-customers~\cite{BTC:demise}.
-
-The classical Bitcoin payment workflow consisted of entering payment
-details into a peer-to-peer application.  The user would access their
-Bitcoin {\em wallet} and instruct it to transfer a particular amount
-from one of his accounts to the account of the merchant. He could
-possibly include additional metadata to be associated with the
-transfer to be embedded into the global public ledger.  The wallet
-application would then transmit the request to the Bitcoin
-peer-to-peer overlay network.  The use of an external payment
-application makes payments significantly less
-browser-friendly than ordinary card payments, as illustrated in
-Figure~\ref{fig:bitcoin}. This has led to the development of
-browser-based
-wallets.\footnote{\url{https://github.com/frozeman/bitcoin-browser-wallet}}
-
-Bitcoin payments are only confirmed when they appear in the public
-ledger, which is updated at an average frequency of once every 10
-minutes.  Even then, it is possible that a fork in the so-called block
-chain may void durability of the transaction; as a result, it is
-recommended to wait for 6 blocks (on average one hour) before
-considering a transaction committed~\cite{nakamoto2008bitcoin}.  In
-cases where merchants are unable to accommodate this delay, they incur
-significant fraud risks.
-
-Bitcoin is considered to be secure against an adversary who cannot
-control around a fifth of the Bitcoin miner's computational
-resources~\cite{BTC:Bahack13,BTC:MajorityNotEnough,BTC:Eclipse}.  % 21percent?
-As a result, the network must expend considerable computational
-resources to keep this value high.
-According to~\cite{vice_btc_unsustainable}, a single Bitcoin transaction uses roughly enough
-electricity to power 1.57 American households for a day.
-These costs are largely hidden by speculation in BTC,
-but that speculation itself contributes to BTC's valuation being
-volatile.~\cite{jeffries_economists_v_btc,lehmann_btc_fools_gold,lewis_btc_is_junk}. % exacerbating risk
-
-% fees hit you 2-3 times with currency conversions
-% more on massive transaction fees from blockchain.info
-
-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}.
-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}.
-This has resulted in the development of new protocols with better
-privacy protections.
-
-\begin{figure*}[t!]
-\includegraphics[width=\textwidth]{figs/paypal.pdf}
-\caption{Payment processing with PayPal. (From: W3C Web Payments IG.)}
-\label{fig:paypal}
-\end{figure*}
-
-Zerocoin \cite{miers2013zerocoin} is such an extension of Bitcoin:
-It affords protection against linkability of transactions,
-but at non-trivial additional computational costs even for
-spending coins.  This currently makes using Zerocoin unattractive
-for payments, especially with mobile devices.
-
-Bitcoin also faces serious scalability limitations, with the classic
-implementation being limited to at most 7 transactions per second
-globally on
-average.\footnote{\url{http://hackingdistributed.com/2016/08/04/byzcoin/}}
-There are a variety of efforts to confront Bitcoin's scaling problems
-with off-blockchain techniques, like side-chains. % \cite{???}
-Amongst these, the blind off-chain lightweight transactions (BOLT)
-proposal~\cite{BOLT} provides anonymity by routing off-blockchain
-transfers through bank-like intermediaries.  Although interesting,
-there are seemingly fragile aspects of the BOLT protocol, including
-aborts deanonymizing customers and theft if a party fails to post a
-refute message in a timely fashion.  Intermediaries may be subject
-to legal risks as well. \footnote{Errata: We originally assesed the
-financial liabilities of BOLT intermediaries incorrectly.}
-% Of course, Taler itself could be used to provide a side-chain like technology
-% Assuming these issues can be addressed,
-% % and the relatively advanced crypto involved became production ready,
-% Taler might prove a better platform for deploying a BOLT-like scheme
-% than Zerocoin.
-
-
-% In addition, the Bitcoin protocol does not interact well with
-% conventional anonymity networks like Tor \cite{BTC:vsTor}
-% dark pools?
-
-% outdated ideas :
-%  mining suck0rs,
-%  DDoS : wired article?
-%  economic ideology
-
-\subsection{Walled garden payment systems}
-
-Walled garden payment systems offer ease of use by processing payments
-using a trusted payment service provider. Here, the customer
-authenticates to the trusted service, and instructs the payment
-provider to execute a transaction on his behalf
-(see Figure~\ref{fig:paypal}).  In these payment systems, the provider
-basically acts like a bank with accounts carrying balances for the
-various users.  In contrast to traditional banking systems, both
-customers and merchants are forced to have an account with the same
-provider.  Each user must take the effort to establish his identity
-with a service provider to create an account.  Merchants and customers
-obtain the best interoperability in return for their account creation
-efforts if they start with the biggest providers.  As a result, there
-are a few dominating walled garden providers, with AliPay, ApplePay,
-GooglePay, SamsungPay and PayPal being the current {\em oligopoly}.  In this
-paper, we will use PayPal as a representative example for our discussion
-of these payment systems.
-
-As with card payment systems, these oligopolies are politically
-dangerous~\cite{crinkey2011rundle}, and the lack of {\em competition}
-can result in excessive profit taking that may require political
-solutions~\cite{guardian2015cap} to the resulting {\em market
-  failure}.  The use of non-standard {\em proprietary} interfaces to
-the payment processing service of these providers serves to reinforce
-the customer {\em lock-in}.
-
-
-\section{Taler}
-
-Taler is a free software cryptographic payment system. It has an open
-protocol specification, which couples cash-like anonymity for customers
-with low transaction costs, signed digital
-receipts, and accurate income information to facilitate taxation and
-anti-corruption efforts.
-
-% FIXME: maybe say what blind signature are
-Taler achieves anonymity for buyers using {\em blind
-signatures}~\cite{chaum1983blind}.  Since their discovery thirty years
-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 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.
-
-%\subsection{Design overview}
-
-\begin{figure}[b!]
-\centering
-\begin{tikzpicture}
- \tikzstyle{def} = [node distance=3em and 5em, inner sep=1em, outer sep=.3em];
- \node (origin) at (0,0) {};
- \node (exchange) [def,above=of origin,draw]{Exchange};
- \node (customer) [def, draw, below left=of origin] {Customer};
- \node (merchant) [def, draw, below right=of origin] {Merchant};
- \node (auditor) [def, draw, above right=of origin]{Auditor};
-
- \tikzstyle{C} = [color=black, line width=1pt]
-
- \draw [<-, C] (customer) -- (exchange) node [midway, above, sloped] (TextNode) {withdraw coins};
- \draw [<-, C] (exchange) -- (merchant) node [midway, above, sloped] (TextNode) {deposit coins};
- \draw [<-, C] (merchant) -- (customer) node [midway, above, sloped] (TextNode) {spend coins};
- \draw [<-, C] (exchange) -- (auditor) node [midway, above, sloped] (TextNode) {verify};
-
-\end{tikzpicture}
-\caption{Taler system overview.}
-\label{fig:system}
-\end{figure}
-
-
-There are four key roles in the Taler system (Figure~\ref{fig:system}):
-
-\begin{figure*}[b!]
-\includegraphics[width=0.9\textwidth]{figs/taler-withdraw.pdf}
-\caption{Withdrawing coins with Taler.}
-\label{fig:taler-withdraw}
-\end{figure*}
-
-
-
-
-\begin{itemize}
-\item
-{\em Customers} use a digital wallet to withdraw,
-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 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.
-
-\begin{figure}[b!]%[36]{R}{0.5\linewidth}
-\subfloat[Bank login. (Simplified for demonstration.)]{
-\includegraphics[width=0.4\linewidth]{figs/bank0a.png}
-\label{subfig:login}} \hfill
-\subfloat[Specify amount to withdraw. (Integrated bank support.)]{
-\includegraphics[width=0.4\linewidth]{figs/bank1a.png}
-\label{subfig:withdraw}} \\
-\subfloat[Select exchange provider. (Generated by wallet.)]{
-\includegraphics[width=0.4\linewidth]{figs/bank2a.png}
-\label{subfig:exchange}} \hfill
-\subfloat[Confirm transaction with a PIN. (Generated by bank.)]{
-\includegraphics[width=0.4\linewidth]{figs/bank3a.png}
-\label{subfig:pin}}
-\caption{Required steps in a Taler withdrawal process.}
-\label{fig:withdrawal}
-\end{figure}
-
-
-
-\item
-{\em Exchanges}, which are run by financial service providers, enable
-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 signature scheme~\cite{chaum1983blind}.  Thus, only
-an exchange can issue new coins, but coins cannot be traced back
-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
-of double spending, thus providing merchants instant feedback
----including digital proofs---in case of misbehaving customers.
-
-\item
-{\em Merchants} provide goods or services in exchange for coins held
-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
-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
-Web shops and point-of-sale systems.
-
-\item
-{\em Auditors} verify that exchanges operate correctly to limit the risk
-that customers and merchants incur by using a particular exchange.
-Auditors are typically operated by or on behalf of financial regulatory authorities.
-Depending on local legislation, auditors may mandate that exchanges
-have enough financial reserves before authorizing them to create a given
-volume of signed digital coins to provide a buffer against potential risks due to
-operational failures (such as data loss or theft of private keys) of the exchange.
-Auditors certify exchanges that they audit using digital signatures.  The
-respective signing keys of the auditors are distributed to customer and
-merchants.
-\end{itemize}
-
-
-The specific protocol between wallet and merchant depends on the
-setting.  For a traditional store, a near field communication (NFC)
-protocol might be used between a point-of-sale system and a mobile
-application.  In this paper, we focus on Web payments for an online
-shop and explain how the actors in the Taler system interact by way of
-a typical payment.
-
-Initially, the customer installs the Taler wallet extension for
-their browser.  This only needs to be done once per
-browser. Naturally, this step may become superfluous if Taler is
-integrated tightly with browsers in the future.  Regardless,
-installing the extension involves only one or two clicks to confirm the
-operation. Restarting the browser is not required.
-
-
-\begin{figure*}[b!]
-\includegraphics[width=0.9\textwidth]{figs/taler-pay.pdf}
-\caption{Payment processing with Taler.}
-\label{fig:taler-pay}
-\end{figure*}
-
-
-\subsection{Withdrawing coins}
-
-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
-used depends on the bank (Figure~\ref{subfig:login}).
-
-The next step depends on the level of Taler support offered by the bank:
-\begin{itemize}
-\item If the bank does not offer integration with Taler, the
-  customer needs to use the menu of the wallet to create a {\em reserve}.
-  The wallet will ask which amount in which {\em currency} (e.g. EUR
-  or USD) the customer wants to withdraw, and allow the customer to
-  select an exchange.  Given this information, the wallet will
-  instruct the customer to transfer the respective amount to the
-  account of the exchange.  The customer will have to enter a
-  % FIXME it is not said that this crypto token is the reserve,
-  % or, more abstractly, that "identify" this operation
-  % CG: I don't think this has to be said.
-  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 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
-  the wallet to allow the customer to select an exchange
-  (Figure~\ref{subfig:exchange}).  Afterwards,
-  the wallet instructs the bank about the details of the wire
-  transfer.  The bank asks the customer to authorize the transfer, and
-  finally confirms to the wallet that the transfer has been
-  successfully initiated.
-\end{itemize}
-
-In either case, the wallet can then withdraw the coins from the
-exchange, and does so in the background without further interaction
-with the customer.
-
-In principle, the exchange can be directly operated by the bank, in
-which case the step where the customer selects an exchange could be
-skipped by default.  However, we generally assume that the exchange is
-a separate entity, as this yields the largest anonymity set for
-customers, and may help create a competitive market.
-
-\subsection{Spending coins}
-% \tinyskip
-
-\begin{figure}[p!]
-  \subfloat[Select article][Select article. \\ Generated by Web shop.]{
-\includegraphics[width=0.30\textwidth]{figs/cart.png}
-\label{subfig:cart}} \hfill
-\subfloat[Confirm payment][Confirm payment. \\ Generated by Taler wallet.]{
-\includegraphics[width=0.30\textwidth]{figs/pay.png}
-\label{subfig:payment}} \hfill
-\subfloat[Receive article][Receive article. \\ Generated by Web shop.]{
-\includegraphics[width=0.30\textwidth]{figs/fulfillment.png}
-\label{subfig:fulfillment}}
-\caption{Required steps in a Taler checkout process.}
-\label{fig:shopping}
-\end{figure}
-
-
-At a later point in time, the customer can spend their coins by
-visiting a merchant that accepts digital coins in the respective
-currency issued by the respective exchange
-(Figure~\ref{fig:taler-pay}).  Merchants are generally configured to
-either accept a specific exchange, or to accept all the exchanges
-audited by a particular auditor.  Merchants can also set a ceiling for
-the maximum amount of transaction fees they are willing to cover.
-Usually these details do not matter for the customer, as we expect
-most merchants to accept most exchange providers accredited by the
-auditors that wallets include by default.  Similarly, we expect
-exchanges to operate with transaction fees acceptable to most
-merchants to avoid giving customers a reason to switch to another
-exchange.  If transaction fees are higher than what is covered by the
-merchant, the customer may choose to cover them.
-
-% \tinyskip
-\lstdefinelanguage{JavaScript}{
-  keywords={typeof, new, true, false, catch, function, return, null, catch, switch, var, if, in, while, do, else, case, break, for},
-  keywordstyle=\color{blue}\bfseries,
-  ndkeywords={class, export, boolean, throw, implements, import, this},
-  ndkeywordstyle=\color{darkgray}\bfseries,
-  identifierstyle=\color{black},
-  sensitive=false,
-  comment=[l]{//},
-  morecomment=[s]{/*}{*/},
-  commentstyle=\color{purple}\ttfamily,
-  stringstyle=\color{red}\ttfamily,
-  morestring=[b]',
-  morestring=[b]"
-}
-
-\begin{figure*}[p!]
- \lstset{language=HTML5}
- \lstinputlisting{figs/taler-presence-js.html}
- \caption{Sample code to detect the Taler wallet. Allowing the
-  Web site to detect the presence of the wallet leaks one bit
-  of information about the user. The above logic also works
-  if the wallet is installed while the page is open.}
-  \label{listing:presence}
-\end{figure*}
-
-
-\begin{figure*}[p!]
-  \lstset{language={}}
-\begin{lstlisting}
-HTTP/1.1 402 Payment Required
-Content-Type: text/html; charset=UTF-8
-X-Taler-Contract-Url: https://shop/generate-contract/42
-
-<!DOCTYPE html>
-<html>
-  <!-- fallback for browsers without the Taler extension -->
-  You do not seem to have Taler installed, here are other payment options ...
-</html>
-\end{lstlisting}
- \caption{Sample HTTP response to prompt the wallet to show an offer.}
-  \label{listing:http-contract}
-\end{figure*}
-
-\begin{figure*}[p!]
- \lstset{language=HTML5}
- \lstinputlisting{figs/taler-contract.html}
- \caption{Sample JavaScript code to prompt the wallet to show an offer.
-          Here, the contract is fetched on-demand from the server.
-          The {\tt taler\_pay()} function needs to be invoked
-          when the user triggers the checkout.}
- \label{listing:contract}
-\end{figure*}
-
-
-As with traditional Web transactions, customers first select which
-items they wish to buy.  This can involve building a traditional
-shopping cart, or simply clicking on a particular link for the
-respective article (Figure~\ref{subfig:cart}).  Once the articles have
-been selected, the Web shop directs the user to the {\em offer} URL,
-where the payment details are negotiated.  The process usually starts
-by allowing the user to select a {\em payment method} from a set of
-methods supported by the Web shop.  Taler also allows the Web shop to
-detect the presence of a Taler wallet (Figure~\ref{listing:presence}),
-so that the selection of alternative payment methods can be skipped if
-a Taler wallet is installed (as it is in Figure~\ref{fig:shopping}).
-
-\begin{figure*}[t!]
-  \lstset{language=JavaScript}
-\begin{lstlisting}
-{
-  "H_wire":"YTH0C4QBCQ10VDNTJN0DCTTV2Z6JHT5NF43F0RQHZ8JYB5NG4W4G...",
-  "amount":{"currency":"EUR","fraction":1,"value":0},
-  "auditors":[{"auditor_pub":"42V6TH91Q83FB846DK1GW3JQ5E8DS273W4236AXC397892ESD0B0"}],
-  "exchanges":[{"master_pub":"1T5FA8VQHMMKBHDMYPRZA2ZFK2S63AKF0YTHJZWFKF45K2JGC8H0",
-                "url":"https://exchange/"}],
-  "expiry":"/Date(1480119270)/",
-  "fulfillment_url": "https://shop/article/42?tid=249960194066269&time=1471479270",
-  "max_fee":{"currency":"EUR","fraction":01,"value":0},
-  "merchant":{"address":"Mailbox 4242","jurisdiction":"Jersey","name":"Shop Inc."},
-  "merchant_pub":"Y1ZAR5346J3ZTEXJCHQY9NJN78EZ2HSKZK8M0MYTNRJG5N0HD520",
-  "products":[{
-    "description":"Essay: The GNU Project",
-    "price":{"currency":"EUR","fraction":1,"value":0},
-    "product_id":42,"quantity":1}],
-  "refund_deadline":"/Date(1471522470)/",
-  "timestamp":"/Date(1471479270)/",
-  "transaction_id":249960194066269
-}
-\end{lstlisting}
-  \caption{Minimal Taler contract over a digital article with a value of \EUR{0.10}. The merchant will pay transaction fees up to \EUR{0.01}.  The hash over the wire transfer information was truncated to make it fit to the page.}
-  \label{listing:json-contract}
-\end{figure*}
-
-\subsubsection{Offer}
-
-The offer URL of the Web shop can then initiate payments by sending a
-\emph{contract proposal} (Figure~\ref{listing:json-contract}) to the
-wallet, either via the HTTP status code {\tt 402 Payment Required}
-(Figure~\ref{listing:http-contract}), or via Taler's JavaScript API
-(Figure~\ref{listing:contract}).  The wallet then presents the
-contract to the user.  The format of the contract is in an extensible
-JSON-based format defined by Taler and not HTML, as the rendering of
-the contract is done by the wallet to ensure correct visual
-representation of the terms and prices.  In case that transaction fees
-need to be covered by the customer, these are shown together with the
-rest of the proposed contract.
-
-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.  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.
-
-If the customer approves the contract by clicking the ``Confirm
-Payment'' button (Figure~\ref{subfig:payment}), their wallet signs the
-contract with enough coins to cover the contract's cost, stores all of
-the information in its local database, and redirects the browser to
-the {\em fulfillment} URL provided by the merchant in the contract
-(Figure~\ref{subfig:fulfillment}).
-
-\subsubsection{Fulfillment}
-
-\begin{figure*}[t!]
-  \lstset{language=HTML5}
-\begin{lstlisting}
-  taler.executePayment("2BAH2AT4GSG5JRM2W4YWTSYGY66EK4X8CX2V69D5VF7XV703AJMG",
-    "https://shop/pay", "https://shop/article/42",
-    (err) => { alert("Sending payment failed");  });
-\end{lstlisting}
-\caption{Sample JavaScript code to trigger transmission of a payment to the merchant.}
-  \label{listing:javascript-execute}
-\end{figure*}
-
-
-\begin{figure*}[t!]
-  \lstset{language={}}
-\begin{lstlisting}
-HTTP/1.1 402 Payment Required
-Content-Type: text/html; charset=UTF-8
-X-Taler-Contract-Hash: 2BAH2AT4GSG5JRM2W4YWTSYGY66EK4X8CX2V69D5VF7XV703AJMG...
-X-Taler-Pay-Url: https://shop/pay
-X-Taler-Offer-Url: https://shop/article/42
-
-<!DOCTYPE html>
-<html>
-  <!-- fallback for browsers without the Taler extension -->
-  You do not seem to have Taler installed, here are other payment options ...
-</html>
-\end{lstlisting}
-\caption{Sample HTTP response when the user agent navigates to a fulfillment
-  URL without the session state that indicates they have paid for the resource.
-  Note that unlike in Listing~\ref{listing:http-contract}, the response
-  references a contract that typically is already known to the wallet via its
-  hash code.}
-  \label{listing:http-execute}
-\end{figure*}
-
-The fulfillment URL uniquely identifies a purchase by some customer,
-while the offer URL identifies a generic offer that is not specific to
-a customer.  The purchase identified by a fulfillment URL may have
-been completed or still be in progress.  The information contained in
-the fulfillment URL must allow the merchant to restore the full
-contract (including a unique transaction identifier) that was
-associated with the purchase, either directly from the URL or
-indirectly from an identifier in a database.  Efficiently
-reconstructing the contract entirely from the URL instead of using
-costly database transactions can be important, as costly disk
-operations for incomplete purchases make merchants more susceptible to
-denial-of-service attacks from adversaries pretending to be customers.
-
-When a customer has completed a purchase, navigating to the
-fulfillment URL in a browser will show the resource associated with
-the purchase.  This resource can be a digital good such as a news
-article, or simply a confirmation for products that are delivered by
-other means.
-
-When a customer has not yet completed a purchase (this is always the
-case when a customer visits the fulfillment URL for the first time),
-or when the Web shop cannot confirm that this visitor has paid for the
-contract, for example because the session state was
-lost,\footnote{This can happen when when privacy conscious users
-  delete their cookies.  Also, some user agents (such as the TOR
-  browser) do not support persistent (non-session) cookies.} the Web
-store responds by (again) triggering a payment process (either via
-JavaScript or using {\tt 402 Payment Required}, see
-Figures~\ref{listing:javascript-execute} and~\ref{listing:http-execute}).  However, unlike the response from
-the offer URL, the 402 response from the fulfillment page includes the
-headers {\tt X-Taler-Contract-Hash}, {\tt X-Taler-Pay-Url} and {\tt
-  X-Taler-Offer-Url}.
-
-If the contract hash matches a payment which the user already
-previously approved, the wallet reacts to this by injecting the logic
-to transmit the payment to the {\em pay} URL of the Web shop into
-the page.  Then the wallet inspects the response as it may contain
-error reports about a failed payment which the wallet has to handle.
-By submitting the payment this way, we also ensure that this
-intermediate request does not require JavaScript and still does not
-interfer with navigation.  Once the Web shop confirms the payment, the
-wallet causes the fulfillment URL to be reloaded.
-
-If the contract hash does not match a payment which the user
-already approved, for example because the user obtained the link
-from another user, the wallet navigates to the offer URL included
-in the header.
-
-\subsubsection{Discussion}
-
-Various failure modes are considered in this design:
-
-\begin{itemize}
-\item If the payment fails on the network, the request is typically
- retried.  How often the client retries automatically before informing
- the user of the network issue is up to the merchant.  If the network
- % FIXME this (above) could be ambiguous because the network failure
- % can happen between the wallet and the merchant without the merchant
- % getting any (failing) request, so the merchant cannot count how much
- % times a payment has failed.
- % CG: Well, the merchant can do that counting *client-side*. The retries
- % will be controlled by the JS on the client side, which is provided
- % by the merchant initially.
- failure persists and is between the customer and the merchant, the wallet
- will try to recover control over the coins at the exchange by
- effectively spending the coins first using Taler's
- refresh protocol.  In this case, later deposits by the merchant
- will simply fail.  If the merchant already succeeded with the payment
- before the network failure, the customer can either retry the
- operation via the transaction history kept by the wallet, or demand a refund (see
- below).  Handling these errors does not require the customer to give
- up his privacy.
-\item If the payment fails due to the exchange
- claiming that the request was invalid, the diagnostics created by the
- exchange are passed to the wallet for inspection.  The wallet then
- decides whether the exchange was correct, and can then inform the
- user about a fraudulent or buggy exchange.  At this time, it allows
- the user to export the relevant cryptographic data to be used in
- court.  If the exchange's proofs were correct and coins were
- double-spent, the wallet informs the user that its database must have
- been out-of-date (e.g. because it was restored from backup),
- updates the database and allows the user to retry
- the transaction.
-\end{itemize}
-
-\noindent
-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 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.
-  \item Asynchronously transmitting coins from injected JavaScript costs
-    one roundtrip, but does not interfer with navigation and allows
-    proper error handling.
-  \item The different pages of the merchant have clear
-    delineations: the shopping pages conclude by making an offer, and
-    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
-    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
-    originating from Web pages to execute the payment process.
-\end{itemize}
-
-% \smallskip
-
-\subsection{Giving change and refunds}
-
-\begin{figure*}[b!]
-  \lstset{language={HTML5}}
-\begin{lstlisting}
-<script src="taler-wallet-lib.js"></script>
-<script>
-  // Obtain refund permissions from the merchant backend
-  // ...
-  let refundPermissions = /* ... */;
-  taler.acceptRefunds(refundPermissions, (err) => {
-    alert("An error occured while attempting a refund");
-  });
-</script>
-\end{lstlisting}
- \caption{Sample JavaScript code to trigger a refund from the merchant's web shop}
-  \label{listing:refund}
-\end{figure*}
-
-An important cryptographic difference between Taler and previous
-transaction systems based on blind signing is that Taler is able to
-provide unlinkable change and refunds.  From the user's point of view,
-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, 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
-the exchange providers and fee structure, but not the cryptographic
-coins.  Consequently, the major cryptographic advances of Taler are
-invisible to the user.
-
-Taler's refresh protocol~\cite{talercrypto} also allows merchants to give
-refunds to customers. To refund a purchase, the merchant obtains a signed refund permission
-from the exchange, which the customer's wallet processes
-(Figure~\ref{listing:refund}) to obtain new, unlinkable coins as refund.
-This process allows the customer to say anonymous when receiving refunds.
-
-Taler's refresh protocol ensures unlinkability for both change and
-refunds, thereby assuring that the user has key conveniences of other
-payment systems while maintaining the security standard of an
-anonymous payment system.
-
-% Alternative version:
-%An important technical difference between Taler and previous
-%transaction systems based on blind signing is that in Taler coins
-%consist of a public-private key pair with the blind signature on the
-%public key, so that coins themselves can be used to anonymously sign
-%the purchase contract.
-%
-%An important technical difference between Taler and previous
-%transaction systems based on blind signing is that Taler coins
-%consist of a public-private key pair with the blind signature on the
-%public key, so that coins themselves can be used to anonymously sign
-%the purchase contract.
-%
-%In general, these coins exceed the cost of the contract, so the wallet
-%may specify that only a fraction of a coin be spent, leaving some
-%residual value on the partially spent coin as ``change''.
-%
-%As the merchant received only a signature of the coin, not private
-%or symmetric key material, merchants can refund anonymous coins by
-%asking the mint to restore a part of the coin's original value,
-%and notifying the customer's wallet to refresh the coin.
-%
-%Spending Taler coins reveals nothing about a customer per se.
-%Yet, any coins that hold value after being involved in a purchase or
-%a refund operation cannot be considered anonymous anymore because a
-%merchant, and possibly the exchange, has now seen them and could
-%link them that previous transaction.  At best, these tainted coins
-%are only pseudononymous, similar to Bitcoin accounts.
-%
-%To maintain anonymity, a Taler wallet automatically performs a
-%{\em refresh} operation with the mint API to both replace tainted
-%coins with new freshly anonymized coins and to exchange old coins
-%before their denomination's expiration date.  We view refreshing
-%partially spent coins as analogous to giving change in cash
-%transactions, but refreshing refunded coins allows Taler merchants
-%to refund anonymous customers.  Cash transactions have these options,
-%but credit cards require customer identification for both operations.
-% Is this true?
-% no comment around randomizing the serial numbers on bills
-
-
-
-\subsection{Deployment considerations for merchants}
-
-Payment system security is not only a concern for
-customers, but also for merchants.  For consumers, existing schemes
-may be inconvenient and not provide privacy, but remembering to
-protect a physical token (e.g. the card) and to guard a secret
-(e.g. the PIN) is relatively straightforward.  In contrast, merchants
-are expected to securely handle sensitive customer payment data on
-networked computing devices.  However, securing computer systems---and
-especially payment systems that represent substantial value---is a
-hard challenge, as evidenced by large-scale break-ins with millions of
-consumer card records being illicitly copied~\cite{target}.
-
-Taler simplifies the deployment of a secure payment system for
-merchants. The high-level cryptographic design provides the first
-major advantage, as merchants never receive sensitive payment-related
-customer information.  Thus, they do not have to be subjected to
-costly audits or certified hardware, as is commonly the case for
-processing card payments~\cite{pcidss}. In fact, the exchange does not
-need to have a formal business relationship with the merchant at all.
-According to our design, the exchange's contract with the state
-regulator or auditor and the customers ought to state that it must
-honor all (legal and valid) deposits it receives.  Hence, a merchant
-supplying a valid deposit request should be able to enforce this in
-court without a prior direct business agreement with the exchange.
-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.
-
-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.  We simplify this for merchants by
-providing a generic payment processing {\em backend} for the Web
-shops.
-
-\begin{figure*}[b!]
-\begin{center}
-\begin{tikzpicture}[
-  font=\sffamily,
-  every matrix/.style={ampersand replacement=\&,column sep=2cm,row sep=2cm},
-  source/.style={draw,thick,rounded corners,fill=green!20,inner sep=.3cm},
-  process/.style={draw,thick,circle,fill=blue!20},
-  sink/.style={source,fill=green!20},
-  datastore/.style={draw,very thick,shape=datastore,inner sep=.3cm},
-  dots/.style={gray,scale=2},
-  to/.style={->,>=stealth',shorten >=1pt,semithick,font=\sffamily\footnotesize},
-  every node/.style={align=center}]
-
-  % Position the nodes using a matrix layout
-  \matrix{
-    \node[source] (wallet) {Wallet};
-      \& \node[process] (browser) {Browser};
-      \& \node[process] (shop) {Web shop};
-      \& \node[sink] (backend) {Taler backend}; \\
-  };
-
-  % Draw the arrows between the nodes and label them.
-  \draw[to] (browser) to[bend right=50] node[midway,above] {(4) signed contract}
-      node[midway,below] {(signal)} (wallet);
-  \draw[to] (wallet) to[bend right=50] node[midway,above] {(signal)}
-      node[midway,below] {(5) signed coins} (browser);
-  \draw[<->] (browser) -- node[midway,above] {(3,6) custom}
-      node[midway,below] {(HTTP(S))} (shop);
-  \draw[to] (shop) to[bend right=50] node[midway,above] {(HTTP(S))}
-      node[midway,below] {(1) proposed contract / (7) signed coins} (backend);
-  \draw[to] (backend) to[bend right=50] node[midway,above] {(2) signed contract / (8) confirmation}
-      node[midway,below] {(HTTP(S))} (shop);
-\end{tikzpicture}
-\end{center}
- \caption{Both the customer's client and the merchant's server
-          execute sensitive cryptographic operations in a
-          secured background/backend that is protected against direct access.
-          Interactions with the Taler exchange from the wallet background
-          to withdraw coins and the Taler backend
-          to deposit coins are not shown.
-          Existing system security mechanisms
-          are used to isolate the cryptographic components (boxes) from
-          the complex rendering logic (circles), hence the communication
-          is restricted to JavaScript signals or HTTP(S), respectively.}
- \label{fig:frobearch}
-\end{figure*}
-
-Figure~\ref{fig:frobearch} shows how the secure payment components
-interact with the existing Web shop logic.  First, the Web shop
-frontend is responsible for constructing the shopping cart.  For this,
-the shop frontend generates the customary Web shop pages, which are transmitted
-to the customer's browser.  Once the order has been constructed, the
-shop frontend provides a {\em proposed contract} in JSON format to the
-payment backend, which signs it and returns it to the frontend.  The
-frontend then transfers the signed contract over the network, and
-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 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
-result of the transaction to the front\-end, which is then responsible
-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 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
-sending it to the client; {\bf (7)} passing coins received in payment
-for a contract to the backend; and, {\bf (8)} executing fulfillment
-business logic if the backend confirms the validity of the payment.
-
-To setup a Taler backend, the merchant only needs to configure the
-wire transfer routing details, such as the merchant's IBAN number, as
-well as a list of acceptable auditors and limits for transaction fees.
-Ideally, the merchant might also want to obtain a certificate for the
-public key generated by the backend for improved authentication.
-Otherwise, the customer's authentication of the Web shop simply
-continues to rely upon HTTPS/X.509.
-
-
-\section{Discussion}
-
-We will now discuss how customer's may experience relevant operational
-risks and failure modes of Taler, and relate them to failure modes
-in existing systems.
-
-% \smallskip
-\subsection{Security risks}
-
-In Taler, customers incur the risk of wallet loss or theft.  We
-believe customers can manage this risk effectively because they manage
-similar risks of losing cash in a physical wallet.  Unlike physical
-wallets, Taler's wallet could be backed up to secure against loss of a
-device.  We note that managing the risk does not imply that customers
-will never suffer from such a loss.  We expect that customers will
-limit the balance they carry in their digital wallet.  Ideally, the
-loss should be acceptable given that the customer gains the insight
-that their computer was compromised.
-
-Taler's contracts provide a degree of protection for customers,
-because they are signed by the merchant and retained by the wallet.
-While they mirror the paper receipts that customers receive in
-physical stores, Taler's cryptographically signed contracts ought to
-carry more weight in courts than typical paper receipts.  Customers
-can choose to discard the receipts, for example to avoid leaking their
-shopping history in case their computer is compromised.
-
-Point-of-sale systems providing printed receipts have been compromised
-in the past by merchants to embezzle sales
-taxes.~\cite{munichicecream} With Taler, the merchant still generates
-a receipt for the customer, however, the record for the tax
-authorities ultimately is anchored with the exchange's wire transfer
-to the merchant.  Using the subject of the wire transfer, the state
-can trace the payments and request the merchant provide
-cryptographically matching contracts.  Thus, this type of tax
-fraud is no longer possible, which is why we call Taler {\em
-taxable}.  The mere threat of the state sometimes tracing transactions
-and contracts back to the merchant also makes Taler unsuitable for
-illegal activities.
-
-The exchange operator is obviously crucial for risk management in
-Taler, as the exchange operator holds the customer's funds in a
-reserve in escrow until the respective deposit request
-arrives\footnote{As previously said, this {\it deposit request} is
-  aimed to exchange {\it coins} for bank money, and it is made by a
-  merchant after successfully receiving coins from a wallet during the
-  payment process.} To ensure that the exchange operator does not
-embezzle these funds, Taler expects exchange operators to be regularly
-audited by an independent auditor\footnote{Auditors are typically run
-  by financial regulatory bodies of states.}.  The auditor can then
-verify that the incoming and outgoing transactions, and the current
-balance of the exchange matches the logs with the cryptographically
-secured transaction records.
-
-
-% \smallskip
-\subsection{Failure modes}
-
-There are several failure modes which a customer using a Taler wallet may
-encounter:
-
-\begin{itemize}
-\item
-As Taler supports multiple exchanges, there is a chance that a
-merchant might not support any exchange where the customer withdrew
-coins from.  We mitigate this problem by allowing merchants to
-support all exchanges audited by a particular auditor.  We believe
-this a reasonable approach, because auditors and merchants must
-operate with a particular legal and financial framework anyways.  We
-note that a similar failure mode exists with credit cards where not
-all merchants accept all issuers, which is often the case internationally.
-
-\item
-Restoring the Taler wallet state from previous backups, or copying the
-wallet state to a new machine may cause honest users to attempt to
-double spend coins, as the wallet does not know when coins are spent
-between backup and recovery.  In this case, the exchange provides
-cryptographic proof to the wallet that the coins were previously spent so the
-wallet can verify that the exchange and the merchant are behaving honestly.
-
-% FIXME FIXME: the following paragraph seems to describe a scenario where the
-% wallet lost coins due to a restore from backup and then ask for refresh
-% of lost coins: but how does the wallet know lost coins' public keys?
-% CG: I don't understand the problem.
-%
-% Also in this paragraph: how can a payment end in-flight due to insufficient
-% funds? If the payment has been started by the wallet, then no 'insufficient
-% funds' may occur, otherwise the wallet would not have started the payment.
-%
-% CG: Yes, as I explain if the Wallet isn't aware that some coins were
-% already spent (I make a backup, spend coins, restore backup, try to
-% spend again), then this may happen.
-%
-% A way to fix that could be to better define 'internal invariants' ..
-%
-% CG: The internal invariant is exactly the one you fell upon:
-% That the wallet knows which coins have been spent!
-\item
-There could be insufficient funds in the Taler wallet when making a
-payment.  Usually the wallet can trivially check this before beginning
-a transaction, but when double-spending is detected this may also
-happen after the wallet already initiated the payment. This would
-usually only happen if the wallet is unaware of a backup operation
-voiding its internal invariant of knowing which coins have already
-been spent.  If a payment fails in-flight due to
-insufficient funds, the wallet can use Taler's refresh protocol to
-obtain a refund for those coins that were not actually double-spent,
-and then explain to the user that the balance was inaccurate due to
-inconsistencies, and insufficient for payment.
-For the user, this failure mode appears equivalent to an insufficient
-balance or credit line when paying with debit or credit cards.
-\end{itemize}
-
-In the future, we plan to make it easy for users to backup and
-synchronize wallets to reduce the probability of the later two failure
-modes.  A key issue in this context is that these processes will need
-to be designed carefully to avoid leaking information that might allow
-adversaries to link purchases via side channels opened up by the
-synchronization protocol.
-
-\subsection{Comparison}
-
-The different payment systems discussed make use of different security
-technologies, which has an impact on their usability and the
-assurances they can provide.  Except for Bitcoin, all payment systems
-described involve an authentication step.
-% FIXME alternative for the following sentence:
-% With Taler, the authentication is implicit when withdrawing, since
-% the user has to login into his bank's Web portal in the first place,
-% and no further authentication is required during the whole payment
-% experience.
-% CG: Not exactly, as the authentication to the bank is still
-% a very explicit authentication step. It's just more natural.
-With Taler, the authentication itself is straightforward, as the customer is
-at the time visiting the Web portal of the bank, and the authentication is
-with the bank (Figure~\ref{fig:taler-withdraw}).  With PayPal, the
-shop redirects the customer to the PayPal portal (step 5 in
-Figure~\ref{fig:paypal}) after the user selects PayPal as the payment
-method. The customer then provides the proof of payment to the
-merchant.  Again, this is reasonably natural.  The 3DS workflow
-(Figure~\ref{fig:cc3ds}) has to deal with a multitude of banks and
-their different implementations, and not just a single provider.
-Hence, the interactions are more complicated as the merchant needs to
-additionally perform a lookup in the card scheme directory and verify
-availability of the bank (steps 8 to 12).
-
-A key difference between Taler and 3DS or PayPal is that
-in Taler, authentication is done ahead of time.
-After authenticating once to withdraw digital coins, the customer can
-perform many micropayments without having to re-authenticate.  While
-this simplifies the process of the individual purchase, it shifts the
-mental overhead to an earlier time, and thus requires some planning,
-especially given that the digital wallet is likely to only contain a
-% FIXME line below: which 'funds'? Coins or real money? (If they are
-% coins, recall that the wallet withdraw all the coins from a fresh
-% reserve, so there is no 'fraction' of user's available funds; at
-% least in the current implementation)
-% I originally wrote ``wealth'' or ``net value'', but given that
-% most customers are in debt today, that makes little sense, so
-% I changed it to ``available funds'', but I meant _all_ the money
-% he has.
-small fraction of the customer's available funds.  As a result, Taler
-improves usability if the customer withdraws funds once to
-then perform many micropayments, while Taler is likely less usable
-if for each transaction the customer first visits the bank to withdraw
-funds.  This is {\em deliberate}, as Taler can only achieve reasonable
-privacy for customers if they keep a balance in their wallet, as
-this is necessary to break the association between withdrawal and deposit.
-% FIXME the sentence above can be in contrast with how the exchange
-% actually deposits funds to merchants, that is through 'aggregate
-% deposits' that may add unpredictable delays (but that doesn't affect
-% this article too much)
-% CG: I think mentioning aggregation here would distract.
-
-Bitcoin's payment process (Figure~\ref{fig:bitcoin}) resembles that of
-Taler in one interesting point, namely that the wallet is given
-details about the contract the user enters (steps 7 to 11).
-However, in contrast to Taler, Bitcoin wallets are expected
-to fetch the ``invoice'' from the merchant. In Taler, the browser
-can provide the proposed contract directly to the wallet.  In
-PayPal and 3DS, the user is left without a cryptographically secured
-receipt.
-
-Card-based payments (including 3DS) and PayPal also extensively rely
-on TLS for security.  The customer is expected to verify that their
-connections to the various Web sites are properly authenticated using
-X.509, and to know that it is fine to provide their bank account
-credentials to the legitimate
-\url{verifiedbyvisa.com}.\footnote{The search query
-``verifiedbyvisa.com legit'' is so common that, when we entered
-``verifiedbyvisa'' into a search engine, it was the suggested
-auto-completion.}  However, relying on users understanding their
-browser's indications of the security context is inherently
-problematic.  Taler addresses this challenge by ensuring that digital
-coins are only accessible from wallet-generated pages. As such
-there is no risk of Web pages mimicking the look of the respective
-page, as they would still not obtain access to the digital coins.
-
-Once the payment process nears its completion, merchants need to have
-some assurance that the contract is valid.  In Taler, merchants
-obtain a non-repudiable confirmation of the payment.  With 3DS and
-PayPal, the confirmation may be disputed later (e.g. in case of
-fraud), or accounts may be frozen arbitrarily~\cite{diaspora2011}.
-Payments in cash require the merchant to assume the risk of receiving
-counterfeit money.
-% FIXME what about (for the following sentence): merchants should care
-% about maintaining change and depositing the money earned
-% CG: No, it's not optional, ``should'' doesn't come into the equation
-% here. It's a mandatory business expense.
-Furthermore, with cash merchants have the cost of maintaining change
-and depositing the money earned.  The most extreme case for lack of
-assurances upon ``completion'' is Bitcoin, where there is no time
-until a payment can be said to be definitively confirmed (step 19,
-Figure~\ref{fig:bitcoin}), leaving merchants in a bit of a tricky
-situation.
-
-Finally, attempts to address the scalability hudles of Bitcoin using
-side-chains or schemes like BOLT introduce semi-centralized
-intermediaries, not wholey unlike Taler's use of exchanges.  Compared
-to BOLT, we would expect a Taler exchange operating in BTC to offer
-stronger security to all parties and stronger anonymity to customers,
-as well as being vastly cheaper to operate.
-
-
-\section{Future work}
-
-This paper has focused on how Taler would work for Web payments.
-However, the underlying cryptography should work just as well for
-other domains.  In particular, we plan to adapt Taler for NFC and
-peer-to-peer payments in the future.
-
-\subsection{NFC payments}
-
-We have so far focused on how Taler could be used for Web payments;
-however, Taler can in theory also be used over other protocols, such
-as near field communication (NFC).  Here, the user would hold his
-NFC-enabled device running a wallet application near an NFC terminal
-to obtain the contract and confirm the payment on his device, which
-would then transfer the coins and obtain a receipt.  A native NFC
-application would be less restricted in its interaction with the
-point-of-sale system compared to a browser extension, and the security
-of the communication channel is also comparable. Thus, running
-Taler over NFC is largely a simplification of the existing process.
-
-In particular, there are no significant new concerns arising from an
-NFC device possibly losing contact with a point-of-sale system, as for
-Web payments, Taler already only employs idempotent operations to
-ensure coins are never lost, and that transactions adequately persist
-even in the case of network or endpoint failures.  As a result, the
-NFC system can simply use the same transaction models to replay
-transmissions once contact with the point-of-sale system is
-reestablished.
-
-
-\subsection{Peer-to-peer payments}
-
-Peer-to-peer payments are in principle possible with Taler as well;
-however, we need to distinguish two types of peer-to-peer payments.
-
-First, there is the {\em sharing} of coins among entities that
-mutually trust each other, for example within a family.  Here, all
-users have to do is to export and import electronic coins over a
-secure channel, such as encrypted e-mail or via NFC.  For NFC, the
-situation is straightforward because we presumably do not have to worry
-about man-in-the-middle attacks, while secure communication over the
-Internet is likely to remain a significant usability challenge.  We
-note that sharing coins by copying the respective private keys across
-devices is not taxable: the exchange is not involved, no contracts are
-signed, and no records for taxation are created.  However, the
-involved entities must trust each other, because after copying a private
-key both parties could try to spend the coins, but only the first
-transaction will succeed.  Given this crucial limitation
-inherent in sharing keys, we consider it ethically acceptable that
-sharing is not taxable.
-
-Second, there is the {\em transactional} mutually exclusive transfer
-of ownership.  This requires the receiving party to have a {\em
-  reserve} with an exchange, and the sender's exchange would have to
-support wire transfers to the receiver's exchange.  If taxability is
-desired, the {\em reserve} would still need to be tied to a particular
-citizen's identity for tax purposes, and thus require similar
-identification protocols as commonly used for establishing a bank
-account.  As such, in terms of institutions, one would expect this
-setup to be offered most easily by traditional banks, effectively
-merging the technical concepts of a (traditional) bank accounts and
-Taler reserves into one service for the customer.
-
-In terms of usability, transactional
-transfers are just as easy as sharing when performed over NFC, but
-more user friendly when performed over the Internet as they do not
-require a secure communication channel: the Taler protocol is by
-design still safe to use even if the communication is made over an
-unencrypted channel. Only the authenticity of the proposed contract
-needs to be assured.
-
-
-
-\section{Conclusions}
-
-Customers and merchants should be able to easily adapt their existing
-mental models and technical infrastructure to Taler.  In contrast,
-Bitcoin's payment models fail to match common expectations be it in
-terms of performance, durability, security, or privacy.  Minimizing
-the need to authenticate to pay fundamentally improves security
-and usability.
-
-% FIXME (following paragraph): it's never said that the Taler wallet
-% keeps any 'receipt' of transaction -- maybe here we want to say 'contract'
-% instead of 'receipt'?
-% CG: I'd say on the customer side, the signed contract is a receipt.
-% That should be intuitive.
-We expect that electronic wallets that automatically collect digitally
-signed receipts for transactions will become commonplace.
-By providing a free software wallet, Taler gives the user full control
-over the usage of their
-transaction history, as opposed to giving control to big data corporations.
-
-\begin{center}
-  \bf
-We encourage readers to try our prototype for Taler
-at \url{https://demo.taler.net/}.
-\end{center}
-%and to ponder why the billion dollar
-%e-commerce industry still relies mostly on TLS for security given
-%that usability, security and privacy can clearly {\em all} be improved
-%simultaneously using a modern payment protocol.
-
-% These APIs are all RESTful in the modern sense because that greatly
-% simplify integrating Taler with web shops and browsers.
-
-\section*{Acknowledgements}
-
-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
-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
-implementation.
-
-\bibliographystyle{splncs03}
-\bibliography{ui,btc,taler,rfc}
-
-
-
-\end{document}
-
-
-
-
-
-
-
-% \smallskip
-\subsection{Anonymity}
-
-We strongly recommend that the user use Tor Browser to protect their
-% FIXME wasn't the use of Tor discouraged to login into personal things?
-IP address, both initially when withdrawing coins and later during
-purchases.
-
-There are lingering risks that anonymous coins can be correlated to
-customers using additional information.
-
-After withdrawing coins, customer should usually wait before spending
-them, as spending them immediately ....
-% wallet determines coin denominations
-
-
-
-
-
-
-
-Wallet provides isolation
-  Near copy from EXIST proposal?
-- Limits user risk
-- Nearly eliminates risk for merchant and exchange
-  - lower transaction fees
-- Reserves simplify things
-
-Denomination choice
-- Anonymity refresh protocol
-- Withdraw automates like ATMs
-
-Browser extension
-- RESTful vs Bitcoin, OpenCoin, etc.
-  - Retrying RESTful transactions always works
-- minimizing dialog
-- see & pay ??
-- TBB integration
-  - Needed anyways
-- Other browser integration?
-  - Is it wise?  Ok if not worried about anonymity  Taler is still better
-  - Is tor2web worse?
-- W3C
-
-Autopay?  pat payment recognition?
-- dangerous?
-- high charges
-- good for funny money
-
-NFC
-
-
-
-
-
-
-
-
-
-
-
-
-
-% \smallskip
-\subsection{Risks}
-
-A Taler exchange's need not face significant financial risks beyond
-the risk of losing a denomination signing key.  Exchanges can limit that
-risk by carefully tracking how much they issue in each denomination.
-Taler merchant's risks are limited primarily by depositing coins
-quickly and stating contracts accurately.