misc edits based on Neal's comments
This commit is contained in:
parent
35acc3dcf9
commit
2199a539c3
@ -1106,10 +1106,10 @@ usually only happen if the wallet is unaware of a backup operation
|
|||||||
voiding its internal invariants. If a payment fails in-flight due to
|
voiding its internal invariants. If a payment fails in-flight due to
|
||||||
insufficient funds, the wallet can use Taler's refresh protocol to
|
insufficient funds, the wallet can use Taler's refresh protocol to
|
||||||
obtain a refund for those coins that were not actually double-spent,
|
obtain a refund for those coins that were not actually double-spent,
|
||||||
and then explain the user that the balance was inaccurate due to
|
and then explain to the user that the balance was inaccurate due to
|
||||||
inconsistencies from recovery, and overall insufficient for payment.
|
inconsistencies, and insufficient for payment.
|
||||||
For the user, this failure mode appears equivalent to an insufficient
|
For the user, this failure mode appears equivalent to an insufficient
|
||||||
balance or credit line when paying with cards.
|
balance or credit line when paying with debit or credit cards.
|
||||||
\end{itemize}
|
\end{itemize}
|
||||||
|
|
||||||
\subsection{Comparison}
|
\subsection{Comparison}
|
||||||
@ -1129,7 +1129,7 @@ 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
|
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
|
with the bank (Figure~\ref{fig:taler-withdraw}). With PayPal, the
|
||||||
shop redirects the customer to the PayPal portal (step 5 in
|
shop redirects the customer to the PayPal portal (step 5 in
|
||||||
Figure~\ref{fig:paypal}) after the user selected PayPal as the payment
|
Figure~\ref{fig:paypal}) after the user selects PayPal as the payment
|
||||||
method. The customer then provides the proof of payment to the
|
method. The customer then provides the proof of payment to the
|
||||||
merchant. Again, this is reasonably natural. The 3DS workflow
|
merchant. Again, this is reasonably natural. The 3DS workflow
|
||||||
(Figure~\ref{fig:cc3ds}) has to deal with a multitude of banks and
|
(Figure~\ref{fig:cc3ds}) has to deal with a multitude of banks and
|
||||||
@ -1155,11 +1155,11 @@ especially given that the digital wallet is likely to only contain a
|
|||||||
% he has.
|
% he has.
|
||||||
small fraction of the customer's available funds. As a result, Taler
|
small fraction of the customer's available funds. As a result, Taler
|
||||||
improves usability if the customer is able to withdraw funds once to
|
improves usability if the customer is able to withdraw funds once to
|
||||||
then facilitate many micropayments, while Taler is likely less usable
|
then facilitate many micropayments while Taler is likely less usable
|
||||||
if for each transaction the customer first visits the bank to withdraw
|
if for each transaction the customer first visits the bank to withdraw
|
||||||
funds. This is deliberate, as Taler can only achieve reasonable
|
funds. This is deliberate, as Taler can only achieve reasonable
|
||||||
privacy for customers if they do keep a balance in their wallet,
|
privacy for customers if they keep a balance in their wallet,
|
||||||
thereby breaking the association between withdrawal and deposit.
|
which breaks the association between withdrawal and deposit.
|
||||||
% FIXME the sentence above can be in contrast with how the exchange
|
% FIXME the sentence above can be in contrast with how the exchange
|
||||||
% actually deposits funds to merchants, that is through 'aggregate
|
% actually deposits funds to merchants, that is through 'aggregate
|
||||||
% deposits' that may add unpredictable delays (but that doesn't affect
|
% deposits' that may add unpredictable delays (but that doesn't affect
|
||||||
@ -1168,9 +1168,9 @@ thereby breaking the association between withdrawal and deposit.
|
|||||||
|
|
||||||
Bitcoin's payment process (Figure~\ref{fig:bitcoin}) resembles that of
|
Bitcoin's payment process (Figure~\ref{fig:bitcoin}) resembles that of
|
||||||
Taler in one interesting point, namely that the wallet is given
|
Taler in one interesting point, namely that the wallet is given
|
||||||
details about the contract the user is to enter (steps 7 to 11).
|
details about the contract the user enters (steps 7 to 11).
|
||||||
However, in contrast to Taler, here the Bitcoin wallet(s) are expected
|
However, in contrast to Taler, Bitcoin wallets are expected
|
||||||
to fetch the ``invoice'' from the merchant, while in Taler the browser
|
to fetch the ``invoice'' from the merchant. In Taler, the browser
|
||||||
provides the Taler wallet with the proposed contract directly. In
|
provides the Taler wallet with the proposed contract directly. In
|
||||||
PayPal and 3DS, the user is left without a cryptographically secured
|
PayPal and 3DS, the user is left without a cryptographically secured
|
||||||
receipt.
|
receipt.
|
||||||
@ -1186,14 +1186,14 @@ credentials to the legitimate
|
|||||||
auto-completion.} However, relying on users understanding their
|
auto-completion.} However, relying on users understanding their
|
||||||
browser's indications of the security context is inherently
|
browser's indications of the security context is inherently
|
||||||
problematic. Taler addresses this challenge by ensuring that digital
|
problematic. Taler addresses this challenge by ensuring that digital
|
||||||
coins are only accessible from fully wallet-generated pages, hence
|
coins are only accessible from wallet-generated pages. As such
|
||||||
there is no risk of Web pages mimicking the look of the respective
|
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.
|
page, as they would still not obtain access to the digital coins.
|
||||||
|
|
||||||
Once the payment process nears its completion, merchants need to have
|
Once the payment process nears its completion, merchants need to have
|
||||||
some assurance that the contract is now valid. In Taler, merchants
|
some assurance that the contract is valid. In Taler, merchants
|
||||||
obtain a non-repudiable confirmation of the payment. With 3DS and
|
obtain a non-repudiable confirmation of the payment. With 3DS and
|
||||||
PayPal, the confirmation may be disputed later (i.e. in case of
|
PayPal, the confirmation may be disputed later (e.g. in case of
|
||||||
fraud), or accounts may be frozen arbitrarily~\cite{diaspora2011}.
|
fraud), or accounts may be frozen arbitrarily~\cite{diaspora2011}.
|
||||||
Payments in cash require the merchant to assume the risk of receiving
|
Payments in cash require the merchant to assume the risk of receiving
|
||||||
counterfeit money.
|
counterfeit money.
|
||||||
@ -1201,7 +1201,7 @@ counterfeit money.
|
|||||||
% about maintaining change and depositing the money earned
|
% about maintaining change and depositing the money earned
|
||||||
% CG: No, it's not optional, ``should'' doesn't come into the equation
|
% CG: No, it's not optional, ``should'' doesn't come into the equation
|
||||||
% here. It's a mandatory business expense.
|
% here. It's a mandatory business expense.
|
||||||
Furthermore, merchants have the cost maintaining change and depositing
|
Furthermore, merchants have the cost of maintaining change and depositing
|
||||||
the money earned. With Bitcoin, there is no definitive time until a
|
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}),
|
payment can be said to be confirmed (step 19, Figure~\ref{fig:bitcoin}),
|
||||||
leaving merchants in a bit of a tricky situation.
|
leaving merchants in a bit of a tricky situation.
|
||||||
@ -1210,7 +1210,7 @@ leaving merchants in a bit of a tricky situation.
|
|||||||
|
|
||||||
Customers and merchants should be able to easily adapt their existing
|
Customers and merchants should be able to easily adapt their existing
|
||||||
mental models and technical infrastructure to Taler. In contrast,
|
mental models and technical infrastructure to Taler. In contrast,
|
||||||
Bitcoin's payment models fail to match common expectations, be it in
|
Bitcoin's payment models fail to match common expectations be it in
|
||||||
terms of performance, durability, security, or privacy. Minimizing
|
terms of performance, durability, security, or privacy. Minimizing
|
||||||
the need to authenticate to pay fundamentally improves usability.
|
the need to authenticate to pay fundamentally improves usability.
|
||||||
|
|
||||||
@ -1227,7 +1227,7 @@ of the Reich of big data corporations.
|
|||||||
|
|
||||||
We encourage readers to try our prototype for Taler
|
We encourage readers to try our prototype for Taler
|
||||||
at \url{https://demo.taler.net/}, and to ponder why the billion dollar
|
at \url{https://demo.taler.net/}, and to ponder why the billion dollar
|
||||||
e-commerce industry still relies mostly on TLS for security, given
|
e-commerce industry still relies mostly on TLS for security given
|
||||||
that usability, security and privacy can clearly {\em all} be improved
|
that usability, security and privacy can clearly {\em all} be improved
|
||||||
simultaneously using a modern payment protocol.
|
simultaneously using a modern payment protocol.
|
||||||
|
|
||||||
|
Loading…
Reference in New Issue
Block a user