This design document discusses considerations for integrating the GNU Taler wallet with browsers and highlights difficulties with the implementation of a GNU Taler wallet as a cross-browser WebExtension.
GNU Taler is a payment system based on open standards with a free and open source reference implementation. The GNU Taler wallet is the main component used by end users to manage their electronic cash balance and payments.
Payments with GNU Taler are typically initiated via a QR code or link that
contains a taler://pay/{merchant}/{order_id}
URI. Navigating to such a
link should result in a context switch to the wallet, where the payment can can
be approved/declined, and the user is subsequently redirected to the merchant’s
website again.
Other taler://
URIs (for withdrawals, refunds, etc.) are also commonly
used, but not explicitly discussed in this document, as very similar
considerations apply.
There are multiple reference implementations available for multiple platforms (command line, Android, iOS, WebExtension).
While native applications can register themselves as a handler for the
taler
URI scheme, the story is different for WebExtensions: There is
currently no reasonable, cross-platform mechanism that allows a WebExtension to
register itself as the handler for the taler
URI scheme.
This is unfortunate, as a WebExtension could otherwise easily provide a Taler wallet implementation without requiring the user to install a native App, providing a better and safer user experience.
The problems with individual browsers are:
protocol_handlers
in the extension manifest.
However, this list only allows schemes with the prefix ext+
and
schemes that are included in an allowlist. The taler
URI scheme
is not part of this list yet.registerProtocolHandler
API. However, the same allowlist restrictions
apply. Furthermore, the registered protocol scheme is not listed as the
extension’s required/optional permissions. Instead, a different permission
prompt is dynamically shown to the user.registerProtocolHandler
nor the
protocol_handlers
mechanism.Another issue is that Websites can’t easily find out whether a browser
extension handling the taler://
protocol is installed. To avoid using this
information for fingerprinting, anchors could provide an alternative href
in case the main one is not handled, such as:
<a href="taler://pay/..." handler-unavailable-href="https://wallet.taler.net/">...</a>
taler://
URIs
or other mechanisms that Websites can use to interact with Taler
wallets.taler://
URIs by overriding the onclick handler of a
HTML elements.
This requires excessive permissions but would be a viable work-around,
at least on pages that opt in with a special <meta name="taler-support" content="uri">
tag.
It does not work in all use-cases, for example when a navigation
to a taler://
URI is initiated programmatically or by pasting
the URI in the browser’s address bar.taler://
URI in a Taler:
HTTP
header. This approach would allow browsers with native Taler support
(or a WebExtension) to handle payment/withdrawal initiations directly,
without rendering a page that shows the QR code or link.
However, the WebExtension APIs do not allow extensions to
read particular headers without excessive permissions. Furthermore,
more recent versions of Chrome/Chromium do not allow blocking
processing of headers, leading to flickering when the extension
redirects based on the presence of the Taler:
header.ext+taler
URIs instead of taler
URIs. This is not a viable
solution, as it requires a lot of extra and brittle logic on merchants’
Websites.ext+taler
URIs. This would help with Firefox.
Bad for forward compatibility, as we have already provisionally registered the
taler
URI scheme.taler://withdraw
URIs).