Browser Extension vs Payment Handler API

There are two fundamental requirements to satisfy while implementing Web Monetization natively in browsers:

• ability to make cross-site authenticated payments in the background, and
• provide some context to the WM Agent to guide a payment decision (whether to pay, how much to pay etc.).

Both requirements must be fulfilled while preserving the user's privacy.

At a technical level, two strategies become apparent: Browser Extension and Payment Handler API. In this article, I'll weigh the pros and cons of each.

Browser Extension

Extensions have been around in web browsers almost since forever. So, their existence is arguably known to most users.

Extensions run the most privileged user-land code and have access to powerful APIs not available to regular web pages, which can come in handy with Web Monetization:

• Authentication: An extension can access cookies at the payment provider's website to authenticate.
• Browser Sync: An extension can synchronize payment decision models and stats on various devices for a user without sending the user's data to a third-party.
• Browsing history and payment decision: Having some access to a user's browsing history and behavior can help understand whether they would be happy to pay a website more or less, ensuring money goes where the user prefers. Partial access to history (i.e., metrics like how often the user visits the current website) can help with payment decisions without disclosing what website the user is viewing - a big win for privacy.

It's also a bit easier to support browser-specific extension APIs than adding features to the Web Platform.

The biggest roadblock in the adoption of Web Monetization as a browser extension is requiring users to install the extension in the first place. This is difficult as browser extensions appear to be more of a power user thing. The most popular Firefox add-on has 4.5M users compared to total 210M Firefox users. That's 2% of total users. The next most popular extensions have 2M and 1M users each. Chrome has around 0.3% extension users (10M of 3B). These numbers aren't very encouraging.

It's also essential to educate the users of the cost and benefits of the extension. Does the extension have too broad permissions? Is there enough incentive to learn about and install a browser extension, compared to viewing an ad that required nothing to install? Privacy-aware users agree, but what about the rest?

Also, Chrome, the most used browser, doesn't support extensions on mobile at all. Though not all hope is lost as Firefox on Android supports extensions very well. Samsung Internet and iOS Safari also have partial support.

A natural approach to removing the friction above could be adding a default built-in Web Monetization extension in the browser. It could be similar to how browsers let users choose search engines.

Payment Handler API

Payment Handler API is a proposed API that enables WebApps to handle payment requests. Technically, it lets a service worker (a kind of background worker script) of a website handle payment at another site. Presently, the API is experimental and only supported in Chrome and Edge.

As a first impression, a website can conveniently request the user to install a payment handler - in a way, it's as simple as visiting a website. The browser extension certainly requires more clicks. Also, using Payment Handler and Payment Request APIs means reusing the Web Platform, and preventing an entirely new standard.

It's relatively less work for a payment provider to create and publish a payment handler when compared to a browser extension. There will be the same API across all browsers, unlike extensions (though extensions should also be standardized). Publishing is as straightforward as hosting a JavaScript file on their own website.

Authentication in a payment handler is smoother as the service worker runs on its website as a first-party, hence can authenticate requests on the same origin easily. It's also safer as a payment handler by some website X cannot authorize requests for some other website Y (unlike allowing an extension made by website X to access cookies on another site Y).

Though, as a payment handler doesn't have access to a user's browsing history, it becomes difficult to model payment decisions. A workaround could be to provide additional context in the PaymentRequest call. Nevertheless, determining what context is needed by a handler, and how more or less information can be requested is difficult, and could quickly lead to privacy concerns. With extensions, browsers can provide some primitive context, and extensions can ask for more permissions if needed. Also, once added, removing things from the web platform becomes difficult.

Also, the lack of a browser-sync capability in a payment handler means user details will need to be sent to the payment provider's website if they're to be shared across devices.

My initial thoughts for using the Payment Handler API were to treat the browser as an intermediary and not expose the payment handler method to the website. That is, the browser invokes the PaymentRequest instead of the website. This allows the browser to supervise payments (and not the website) and provide the additional context needed for the payment decision.

The way forward

Initially, I wanted to prototype the native Web Monetization implementation using the Payment Handler API because that meant reusing the Web Platform. Unfortunately, Firefox does not support the Payment Handler API, nor they intend to implement it any time soon. So, I went with the next best approach: a browser extension API. (It would be great if someone gets to experiment with the Payment Handler approach also!)

You might wonder we can already use Web Monetization with Coil's browser extension, so what benefit does adding an extension API add?

The most significant benefit is privacy. Presently, any extension will require complete read-write access to every website you visit. Read access is required to find the payment pointer on the current website. A malicious extension can read more than just the payment pointer. Write access is required to notify the website of the monetization progress. A malicious extension can write a lot more than monetization progress. With an extension API, the browser acts as an intermediary between the extension and a website. It provides the extension with details like whether to pay and where to pay in a privacy-preserving manner. It also provides secure communication of monetization progress to the website.

Secondly, as the browser is acting as an intermediary, it can consistently inform the user of payment status and record, and allow the user more control over which sites get paid and how much.

Additionally, fundamental logic can be handled by the browser, demanding less effort from extension authors.

Summary

I have already created a working implementation of the Web Monetization with the extension API in my fork on Firefox. Shortly, I'll share with you a Firefox release that you can test and provide feedback on. I'll also try to work with Coil folks so we can have a working extension that uses the native APIs.

---

Edit (Jan 18, 2021): Came across a Firefox Data Dashboard, that shows the most popular add-on has 3.9% users (my 2% calculation was incorrect). Even better, around 35% Firefox users worldwide have at least one add-on installed. Now that's more encouraging!