[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Taler] click jacking and asynchronously approving transactions

From: Florian Dold
Subject: [Taler] click jacking and asynchronously approving transactions
Date: Thu, 9 Mar 2017 15:40:57 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1

Hi all,

I thought a bit about how much click jacking would be a problem for
Taler, and how much it would be for the Web Payments API.

Both Taler and the Web Payments API display the payment confirmation
within the page, making it inherently vulnerable to click jacking.  Of
course the Web Payments API has the advantage here, since it's running
in the browser and not within the DOM (so the browser can make really
sure that the payment window isn't occluded by some other elements).
Also adding things like slow animations can make click jacking harder.

Another possible advantage that the Web Payments API has over native
Taler is that they can do payments on-page and asynchronously, with
Taler you need to navigate away from the page, making flatter-like
payment scenarios a bit more awkward.  Yes, we could remember scrolling
positions, but this doesn't work out with more JavaScript-heavy pages
that have lots of state that will be lost.

I wonder if it makes sense to have an alternative way to approve
transaction, that IMHO both improves security and usability on pages
where we need asynchronous payments (e.g. payments without navigating
away) and that use JavaScript.

The merchant would request a payment on the page in JavaScript, for
example by pressing a flattr-like button.  We now don't navigate away,
but instead some text close to the flattr-like button shows "please
approve payment".  The logo of the Taler extension button changes, when
you click it, above the balances there will be a button to approve or
reject the payment.  Once the user clicks this button, the payment is
made, and some JavaScript callback will be invoked on the merchant side
with the success/error status of the payment.

I'm not saying we need this right now, but I think it's interesting
because it adds some security benefits (payment approval happens in a
part of the browser UI that normal pages can't ever touch), it might be
interesting how well users understand/perceive this kind of interaction,
and it's beneficial for stateful JavaScript applications that can't
navigate away.  And the JavaScript version of our API then wouldn't
deviate as much from the Web Payments API.

- Florian

reply via email to

[Prev in Thread] Current Thread [Next in Thread]