diff options
Diffstat (limited to 'articles/ui/ui.tex')
-rw-r--r-- | articles/ui/ui.tex | 1352 |
1 files changed, 1352 insertions, 0 deletions
diff --git a/articles/ui/ui.tex b/articles/ui/ui.tex new file mode 100644 index 000000000..9e7cb0078 --- /dev/null +++ b/articles/ui/ui.tex @@ -0,0 +1,1352 @@ + +\title{Taler: \\ Usable, privacy-preserving payments for the Web} +% \author{ +% Jeffrey Burdges \\ \and +% Florian Dold \\ \and +% Christian Grothoff \\ \and +% Marcello Stanisci +% } +\date{\today} + +\documentclass[twoside,letterpaper]{soups} +\usepackage[margin=1in]{geometry} +\usepackage[utf8]{inputenc} +\usepackage{url} +\usepackage{tikz} +\usepackage{eurosym} +\usepackage{listings} +\usepackage{graphicx} +\usepackage{wrapfig} +%\usepackage{caption} +\usepackage{subcaption} +\usepackage{url} + +\usetikzlibrary{shapes,arrows} +\usetikzlibrary{positioning} +\usetikzlibrary{calc} + +\begin{document} +\maketitle + +\begin{abstract} +Taler is a new electronic online payment system which provides +anonymity for customers and, due to this design choice, also offers +significantly better usability. This paper describes the interaction +processes of online payment systems, and analytically compares their +usability for both customers and merchants. We then focus on the +resulting assurances that Taler provides, as---particularly for payment +systems---usability and security are intertwined. Web payment systems +must also face the reality of constraints imposed by modern Web +browser security architecture, so the analysis includes considerations of +how Web payment systems exploit the security infrastructure provided +by the modern Web. +\end{abstract} + +\section{Introduction} + +The future Internet needs a secure, usable and privacy-preserving +micropayment system that 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} + +As transactions on the Internet, such as sending an e-mail or reading +a Web site, tend to be of smaller value than traditional transactions +involving the exchange of physical goods, we are faced with the +challenge of reducing the mental and technical overheads of existing +payment systems to handle micropayments. Addressing this problem is +urgent: ad-blocking technology is eroding advertising as a substitute +for micropayments~\cite{adblockblocks}, and the Big Data business +model where 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 on Taler, a new free software payment +system designed to meet certain key ethical considerations. In Taler, +the customer remains anonymous, while the merchant is taxable. Here, +{\em anonymous} simply means that the payment system 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 the state can obtain the necessary information about the +contract to levy income, sales or value-added taxes. Taler uses blind +signatures~\cite{chaum1983blind} to create digital coins, and a new +``refresh'' protocol to allow giving change and refunds while +maintaining unlinkability. + +This paper will not consider the details of Taler's cryptographic +protocols\footnote{No citation given due to anonymous submission.}, as +for usability one needs to completely hide the cryptography from the +users. Thus, this paper will focus on an analytical description of +how to achieve usable and secure electronic payments. Our focus is to +show that existing {\em mental models} users have from existing +widespread payment systems will apply naturally. We leave a +usability study with actual users for future work, as we believe that +the basic architecture of such a system is sufficiently interesting by +itself. + +Key contributions of this paper are: +\begin{itemize} + \item A description of different payment systems using + common terminology, allowing us to analytically compare + these systems with respect to security and usability. + \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 ``secure'' browsers. + \item A publicly available free software + reference implementation of the proposed architecture. +\end{itemize} + + +\section{Existing payment workflows} + +Before we look at the payment workflow for Taler, we will sketch +the workflow of existing payment systems. This will establish +a common terminology, a baseline for comparison and crucially +also an indication as to how we can relate Taler's workflow to +existing {\em mental models} that users already have, thereby +allowing us to judge the mental adaptation costs required to +transition to transactions with Taler. + +\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 the both buyer and seller roles, merely 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 finally +{\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 by serial numbers +printed on bills.~\cite{pets2004kuegler} +% 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 may provide 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 limit their risks to the +amount of cash 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 steal their customer's +credentials. Authentication with an ATM can involve a special ATM +card, or more commonly the use of credit or debit cards. In all these +cases, these physical security tokens are issued by the customer's +bank of the customer. + + +% \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 3DS. (From: W3c Web Payments IG.)} +\label{fig:cc3ds} +\end{figure*} + +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, including both secret information, usually PINs, and +physical security devices like TANs~\cite{kobil2016tan} +(cards with an EMV chip~\cite{emv}), and + the customer's mobile phone~\cite{mtan}. +A typical modern Web payment process involves +{\bf (0)} 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}, the security +provided by TLS is at best questionable.} +{\bf (1)} selecting a {\em payment method}, +{\bf (2)} entering the credit card details like owner's name, + card number, expiration time, CVV code, and billing address, +{\bf (3)} (optionally) authorizing the transaction via mobile TAN, or + by authenticating against the customer's bank, +often on a Web site that is operated by the payment +processor and {\em not} the customer's bank. Figure~\ref{fig:cc3ds} +shows a typical card-based payment process on the Web today using the +UML style of the W3c payment interest group~\cite{pigs}. Most of the +details are not relevant to this paper, but the figure nicely +illustrates the complexity of the common 3-D secure (3DS) process. + +Given this process, there is an inherent risk of information leakage +of customers' credentials. Fraud detection systems attempt to detect +misuse of leaked credentials, and payment system providers handle +disputes between customers and merchants. As a result, Web payment +processes may finish with {\bf (4)} the payment being rejected for a +variety of reasons, from false-positives in fraud detection to 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 hence to shift dispute liability to the issuer of the card, who +may then shift it to the customer. +% +% 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, there are still risks customers incur from the card dispute +procedures, such as neither they not the payment processor noticing +fraudulent transactions, or them noticing fraudulent transactions past +the date at which their bank will refund 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 verifiable electronic +receipts for the customers, enabling malicious merchants to later +change the terms of the contract. Beyond these issues, customers face +secondary risks of identity theft from the personal details exposed by +the authentication procedures. In this case, even if the financial +damages are ultimately covered by the bank, the customer always has to +deal with the hassle of notifying the bank in the first place. As a +result, customers must remain wary about their card use, 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}[h!] +\includegraphics[width=0.45\textwidth]{figs/bitcoin.pdf} +\caption{Bitcoin payment processing. (From: W3c Web Payments IG.)} +\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(s) must know the corresponding private key, which in +turn is used 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 speculation. 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; the latter process is called {\em mining}. +% +The mining process is incentivised by transaction fees and mining +rewards, the latter also providing the process of initial accumulation +for BTC.~\cite{nakamoto2008bitcoin} Conversion to and from BTC from +and to other currencies 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. The +classical Bitcoin payment workflow consisted of entering payment +details into a peer-to-peer application. The user would access his +Bitcoin {\em wallet} and instruct it to transfer a particular amount +from one of his accounts to the account of the merchant, possibly +including additional metadata to be associated with the transfer and +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 wallet-based payments +significantly less browser-friendly than ordinary card payments, as +illustrated in Figure~\ref{fig:bitcoin}. + +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~\cite{nakamoto2008bitcoin}. As a result, customers and +merchants must either accommodate this delay, or incur fraud risks +during this indeterminate period. + +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. +In fact, ``a single Bitcoin transaction uses roughly enough +electricity to power 1.57 American households for a day''.~\cite{vice_btc_unsustainable} +These costs are largely hidden by speculation in BTC, +but that speculation itself contributes to BTC being +unstable.~\cite{lehmann_btc_fools_gold,jeffries_economists_v_btc,lewis_btc_is_junk}. % exacerbating risk + +% fees hit you 2-3 times with currency conversions +% more on massive transaction fees from blockchain.info + +There are several examples of Bitcoin's pseudononymity being broken +by investigators~\cite{BTC:Anonymity}. Mixnets afford protection +against this, but they require numerous transactions, exacerbating +Bitcoin's already high transaction costs. +% +Bitcoin's pseudononymity applies equally to both customers and +merchants, making Bitcoin highly amen\-able to tax evasion, money +laundering, and sales of contraband. As a result, anonymity tools +like mixnets do not enjoy particularly widespread support in the +Bitcoin community where many participants seek to make the currency +appear more legitimate. +% In addition, the Bitcoin protocol does not interact well with +% conventional anonymity networks like Tor \cite{BTC:vsTor} + +% dark pools? + +% mining suck0rs, + +% DDoS : wired article? + +% economic ideology + +\subsection{Walled garden payment systems} + +\begin{figure}[b!] +\includegraphics[width=0.45\textwidth]{figs/paypal.pdf} +\caption{Payment processing with Paypal. (From: W3c Web Payments IG.)} +\label{fig:paypal} +\end{figure} + +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 +(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 +customer and merchant 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 oligopoly. In this +paper, we will use PayPal as a representative example for our discussion +of these payment systems. + +As with card payments, these oligopolies are politically +dangerous~\cite{crinkey2011rundle} and the lack of competition can +result in excessive profit taking that may require political +solutions~\cite{guardian2015cap} to the resulting market failure. The +use of non-standard proprietary interfaces to the payment processing +service of these providers serves to reinforce the customer lock-in. + + +\section{Taler} + +Taler is a free software cryptographic payment system with an open +protocol specification that couples cash-like anonymity for customers +when they spend money with low transaction costs, signed digital +receipts, and accurate income information to facilitate taxation and +anti-corruption efforts. + +Taler achieves anonymity for buyers using {\em blind +signatures}~\cite{chaum1983blind}. Ever since their discovery thirty +years ago, cryptographers have viewed blind signatures as the optimal +cryptographic primitive for consumer level transaction systems. Our +goal is for Taler to become the first transaction system based on blind +signatures to see widespread adoption. Hiding the cryptography from +users and integrating smoothly with the Web are central components of our +technical strategy to achieve this. % ethical, privacy, etc. + +%\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 components of the Taler system (Figure~\ref{fig:system}): + +\begin{itemize} +\item +{\em Wallets} are software packages that allow customers to withdraw, +hold, and spend coins. Wallets also 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. + +\item +{\em Exchanges} enable customers to withdraw anonymous digital coins +and merchants to deposit digital coins, in exchange for +bank money. 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 for their regular currency value. Merchants consist of a +{\em frontend} which interacts with the customer's wallet, and a {\em +backend} that 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. +\end{itemize} + +The specific protocol between wallet and merchant depends on the +setting. For a traditional store, an 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. + +\begin{figure}[b!] +\includegraphics[width=0.45\textwidth]{figs/taler-withdraw.pdf} +\caption{Withdrawing coins with Taler.} +\label{fig:taler-withdraw} +\end{figure} + + +% \smallskip +\subsection{Web payment workflow} + +We explain how the actors in the Taler system interact by documenting +a typical payment. + +Initially, the customer must once install the Taler wallet extension +for his browser. Naturally, this step may become superfluous if +Taler is integrated tightly with browsers in the future. Regardless, +installing the extension involves one or two clicks to confirm the +operation once the user was pointed to the correct Web site. +Restarting the browser is not required. + +\paragraph{Withdrawing coins} + + +\begin{figure}[p!] +\begin{subfigure}[H]{0.5\textwidth} +\includegraphics[width=\textwidth]{figs/bank0a.png} +\caption{Bank login. (Simplified for demonstration.)} +\label{subfig:login} +\end{subfigure} +\begin{subfigure}{0.5\textwidth} +\includegraphics[width=\textwidth]{figs/bank1a.png} +\caption{Specify amount to withdraw. (Integrated bank support.)} +\label{subfig:withdraw} +\end{subfigure} +\begin{subfigure}{0.5\textwidth} +\includegraphics[width=\textwidth]{figs/bank2a.png} +\caption{Select exchange provider. (Generated by wallet.)} +\label{subfig:exchange} +\end{subfigure} +\begin{subfigure}{0.5\textwidth} +\includegraphics[width=\textwidth]{figs/bank3a.png} +\caption{Confirm transaction with a PIN. (Generated by bank.)} +\label{subfig:pin} +\end{subfigure} +\caption{Required steps in a Taler withdrawal process.} +\label{fig:withdrawal} +\end{figure} + +As with cash, the customer must first withdraw digital coins +(Figure~\ref{fig:taler-withdraw}). For this, the customer must first +visit the online banking portal of his bank. Here, the bank will +typically require some form of authentication, the specific method +used depends on the bank (Figure~\ref{subfig:login}). + +\clearpage +\newpage +The next step depends on the Taler support offered by the bank: +\begin{itemize} +\item If the bank does not properly integrate with Taler, the + customer needs use the menu of the wallet to create a {\em reserve}. + The wallet will ask which amount in which {\em currency} (i.e. 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, this is + exactly the kind of interaction we would like to avoid for + usability. +\item Hence, if the bank properly integrates with Taler, the + customer has a form in the online banking portal where he 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 may 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. + +\paragraph{Spending coins} +% \tinyskip + +\begin{figure}[b!] +\includegraphics[width=0.45\textwidth]{figs/taler-pay.pdf} +\caption{Payment processing with Taler.} +\label{fig:taler-pay} +\end{figure} + +\begin{figure}[p!] +\begin{subfigure}[H]{0.5\textwidth} +\includegraphics[width=\textwidth]{figs/cart.png} +\caption{Select article. (Generated by Web shop.)} +\label{subfig:cart} +\end{subfigure} +\begin{subfigure}{0.5\textwidth} +\includegraphics[width=\textwidth]{figs/pay.png} +\caption{Confirm payment. (Generated by Taler wallet.)} +\label{subfig:payment} +\end{subfigure} +\begin{subfigure}{0.5\textwidth} +\includegraphics[width=\textwidth]{figs/fulfillment.png} +\caption{Receive article. (Generated by Web shop.)} +\label{subfig:fulfillment} +\end{subfigure} +\caption{Required steps in a Taler checkout process.} +\label{fig:shopping} +\end{figure} + +% \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*}[h!] + \lstset{language=JavaScript} + \lstinputlisting{figs/taler-presence.js} + \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*} + + + +At a later point in time, the customer can spend his 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 should not matter for the customer, as we expect +most merchants to allow most accredited exchange providers, and for +exchanges to operate with transaction fees acceptable to most +merchants. If transaction fees are higher than what is covered by the +merchant, the customer may choose to cover them. + +\begin{figure*}[h!] + \lstset{language=JavaScript} + \lstinputlisting{figs/taler-contract.js} + \caption{Sample code to pass a contract to the Taler wallet. + 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, the customer first selects which +items he wishes 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}). As with card payments, +the Web shop may then allow the customer to select a payment method, +including Taler. Taler also allows the Web shop to detect +the presence of a Taler wallet (Figure~\ref{listing:presence}), so +that this step may be skipped (as it is in Figure~\ref{fig:shopping}). +If Taler was detected or selected, the Web shop sends a digitally +signed {\em contract proposal} to the wallet extension +(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. In the case that transaction fees need to be +covered by the customer, these are shown together with the rest of the +proposed contract. + +If the customer approves the contract by clicking the ``Confirm +Payment'' button (Figure~\ref{subfig:payment}), his 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 a +{\em fulfillment} URL provided by the merchant +(Figure~\ref{subfig:fulfillment}). The wallet cannot directly send +the payment to the merchant, as the page showing the contract is +provided as a background page controlled by the Web Extension\footnote{\url{https://developer.chrome.com/extensions}} and thus +submitting coins from the background would not use the HTTP-context +that the Web shop's page requires for session management. + +Instead, the server-side of the fulfillment page usually first detects +that the contract has not yet been paid by checking the merchant's +local database and the HTTP session state. {\bf (A)} If the state +indicates that this customer did not yet pay, the merchant generates a +page that shows the customer an indication that the payment is being +processed, and tries to interact with the wallet, requesting payment. +If the wallet is not detected after a few milliseconds, the page +transitions to the card payment process. If the wallet is present, +the page requests payment from the wallet. The wallet then determines +that the customer already confirmed the payment and immediately +transfers the coins to the JavaScript logic of the fulfillment page. +The fulfillment page then transfers the coins to the merchant, usually +using an asynchronous HTTP POST request. The request is controlled by +the merchant's JavaScript and not by the wallet. This ensures that the +merchant is in full control of the communication between the +merchant's server and the client-side scripts interacting with the +merchant's server. The interactions with the wallet are thus purely +local interactions within the browser. Upon receipt of the payment +information, the merchant confirms the payment with the exchange, +marks the payment as received, and notifies the JavaScript on the +client side of the result. + +\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 customer and merchant, the wallet + will try to recover control over the coins at the exchange by + effectively spending the coins first using Taler's special + ``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 later via the transaction history, 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 + % FIXME what about giving an example of an out-of-date DB? Put in + % this way, it appears that Taler has viable ways to fail. In other + % words, that it's normal to get such a failure. Instead, that failure + % can occur due to coins not spent for *years* (or some other corner case), + % that saves Taler from being "blamed" + been out-of-date, updates the database and allows the user to retry + the transaction. +\item If the payment succeeded, the JavaScript on the + client side triggers effectively a ``reload'' of the fulfillment + page, triggering case (B) detailed below. +\end{itemize} + +{\bf (B)} Upon subsequent visits, the server detects that the payment +has already been processed and directly generates a fulfillment page +either confirming the payment, or---in the case of payments for a +digital article---transmits the digital artifact to the client. + +\paragraph{Bookmarks and deep links} + +This particular architecture also enables smooth use of the payment +URIs on the contemporary Web. In particular, we need to consider the +possibility that a user may bookmark the fulfillment page, or forward +a link to the fulfillment page to another user. + +The given design supports {\em bookmarking}. If the merchant's +session management is still tracking the user when he returns via the +bookmark, the page generation detects that the user has already paid +and serves the final fulfillment page. If the session has been lost, +the merchant will generate a fulfillment page asking for payment. In +this case, the wallet will detect that it has already paid this +contract via a unique identifier in the contract, and will +automatically re-play the payment. The merchant confirms that this +customer already paid, and generates the final fullfilment page that the +user has previously payed for (and seen). All this still appears as +instantaneous to the user as it merely adds a few extra network round trips. + +In contrast, if the customer sends a link to the fulfillment page to +another user, thereby possibly sharing a {\em deep link} into the +merchant's shop, the other customer's wallet will fail to find an +existing payment. Consequently, the fulfillment page will not receive +the payment details and instead provide the user with the proposed +contract which contains a description of the item previously bought by +the other user. The recipient of the link can then decide to also +purchase the item. + +The design, in particular POSTing the coins asyn\-chro\-nous\-ly from +JavaScript, also ensures that the user can freely navigate with +the back and forward buttons. As all requests from all HTTP(S) +URIs ever seen by the user in the browser are fetched via HTTP +GET, they can be bookmarked, shared and safely reloaded. For +caching, the merchant needs to ensure that the fulfillment +page generated in case (A) is not cached by the browser, +and in case (B) is not cached in the network. + +As an aside, there are actually several distinct roles comprising the +merchant: shopping pages end their role by proposing a contract, while +a fulfillment page begins its life processing a contract. It is thus +possible for these components being 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 +resource sharing.~\cite{rfc6454,cors} + +% FIXME: for the above: add figures with code samples! +% \smallskip + +\paragraph{Giving change and refunds} % FIXME: maybe leave out change entirely? + +An important technical 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, this +is completely hidden from the user. In fact, the 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 technology also allows merchants to give refunds to +customers. For this, the merchant merely has to send a signed +message to the exchange confirming the refund, and notify the +customer's wallet that the respective transaction was refunded. +This can even be done with anonymous customers, as refunds are +given as additional change to the owner of the coins that were +originally spent to pay for the refunded transaction. + +Taler's protocol ensures unlinkability for both changes and refunds, +thus 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{NFC payments} + +We have so far focused on how Taler would be used for Web payments; +however, Taler can also be naturally 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. An NFC +application would be less restricted in its interaction with the +point-of-sale system compared to a browser extension; thus, running +Taler over NFC is largely a simplification. + +Specifically, there are no significant new concerns arising from an +NFC device possibly losing contact with a point-of-sale system. +Already for Web payments, Taler employs only 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 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 the +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 pretty trivial, 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, as after copying a private +key both parties could 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 exchanges would have to support +wire transfers among them. 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. Thus, in +terms of institutions, one would expect this setup to be offered most +easily by traditional banks. 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. + + +\subsection{Usability for merchants} + +Payment system security and usability is not primarily 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 (i.e. the card) and to guard a secret +(i.e. 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} + +Thus, we cannot ignore the usability at the merchant site when trying +to understand the usability of a payment system, especially as for +deployment we will have to convince millions of merchants that the +Taler system is advantageous. The high-level cryptographic design +already provides the first major advantage, as merchants do never +receive sensitive payment-related customer information. Thus, they do +% FIXME as *it* is ? +% CG: both are OK in English, ``it'' can be omitted here. +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 shop 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 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. + +Figure~\ref{listing:presence} shows how easy it is for a Web shop to +detect the presence of a Taler wallet. This leaves a few cryptographic +operations, such as signing a contract and verifying the customer's and +the exchange's signatures, storing transaction data as well as matching +sales with incoming wire transfers from the exchange. Taler simplifies this +for merchants by providing a generic payment processing {\em backend} for +the Web shops. + +\begin{figure*}[h!] +\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 (Figure~\ref{fig:system}) + 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 usual Web pages which are shown to the +user's browser client frontend. Once the order has been constructed, +the shop frontend gives 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 in Figure~\ref{listing:contract}). +Here, the wallet operates from a secure {\em background} on the client side, +which allows the user to securely accept the payment, and to perform +the cryptographic operations in a context that is protected from the +Web shop. In particular, it is secure against a merchant that +generates a page that looks like the payment page from the wallet +(Figure~\ref{subfig:payment}), as such a page would still not have +access to the private keys of the coins that are in the wallet. If +the user accepts, the resulting signed coins are transferred from the +client to the server, again by a protocol that the merchant can +customize to fit the existing infrastructure. + +Instead of adding any cryptographic logic to the merchant frontend, +the generic Taler merchant backend allows the implementor to delegate +handling of the coins 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, 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 rather trivially 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 let it know his wire +transfer routing details, such as an IBAN number. 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. + +Taler's contracts do 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 may receive in +physical stores, Taler's cryptographically signed contracts ought to +carry more weight in courts than typical paper receipts. + +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 to 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 translate {\it coins} +into real money and it's accomplished by a merchant after successfully +receiving coins by a wallet. In other words, it is the way merchants get +real money on their bank accounts}. 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 states}. The auditor can then verify that the incoming and outgoing +transactions and the current balance of the exchange match the logs +with the cryptographically secured transaction records. + + +% \smallskip +\subsection{Failure modes} + +There are several failure modes the user of 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, especially 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 that the coins were previously spent, so the +wallet can verify that the exchange and merchant are behaving honestly. +However, this gives rise to another subsequent failure mode, +namely that ... + +% 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 invariants. 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 the user that the balance was inaccurate due to +inconsistencies from recovery, and overall insufficient for payment. +For the user, this failure mode appears equivalent to an insufficient +balance or credit line when paying with cards. +\end{itemize} + +\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 selected 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). + +The 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 is able to withdraw funds once to +then facilitate many micropayments, while Taler is likely less usable +if for each transaction the customer first visits the bank to withdraw +funds. This is deliberate, as Taler can only achieve reasonable +privacy for customers if they do keep a balance in their wallet, +thereby breaking 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 is to enter (steps 7 to 11). +However, in contrast to Taler, here the Bitcoin wallet(s) are expected +to fetch the ``invoice'' from the merchant, while in Taler the browser +provides the Taler wallet with the proposed contract directly. 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 his +connections to the various Web sites are properly authenticated using +X.509, and to know that it is fine to providing his 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 fully wallet-generated pages, hence +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 now valid. In Taler, merchants +obtain a non-repudiable confirmation of the payment. With 3DS and +PayPal, the confirmation may be disputed later (i.e. 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, merchants have the cost maintaining change and depositing +the money earned. With Bitcoin, there is no definitive time until a +payment can be said to be confirmed (step 19, Figure~\ref{fig:bitcoin}), +leaving merchants in a bit of a tricky situation. + +\section{Conclusion} + +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 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. A key +question for the future is thus whether this data collection will be +done on behalf of the citizens and under their control, or on behalf +of the Reich of big data corporations. + +We encourage readers to try our prototype for Taler +at \url{https://demo.taler.net/}, 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} + +Removed for anonymous submission. + +%\newpage + +\bibliographystyle{abbrv} +\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. |