20.95. DD 95: Captcha 100#
20.95.1. Summary#
One of the key applications we had always envisioned was the use of GNU Taler for spam protection. A related application domain is Captcha’s, where a server needs some ‘proof-of-humanity’ to protect itself from handling expensive requests on behalf of some out-of-control automated bot process. The key insight is that here the operator is not necessarily interested in receiving revenue from GNU Taler, but primarily in limiting their exposure to the attack by increasing the cost to the initiator of the request. Furthermore, the operator is often willing to inconvenience the sender, be it by various spam filters (which have false-positives) or forcing the sender to solve Captcha’s or computational puzzles (Anubis). These existing methods are today often failing, especially as LLMs enable bots to formulate messages that pass spam filters or to solve Captcha’s. In this context, forcing the sender to make a Taler deposit becomes simply another form of imposing a cost, and one that would cost an attacker more dearly.
We can quickly enable this use-case by setting the Taler fees to 100%. At this point, the “merchant” never actually receives any money (and customers that withdrew tokens cannot get money when they return them either), so the operator would not be a payment service as they do not give money to anybody. While this is less attractive to the recipient, it would still be effective at blocking bots. At the same time, this model can be rolled out globally pretty quickly because at 100% fees we do not need a money transmitter or e-money issuer license, as we no longer transmit money – we only accept money in return for a digital service, like many other regular unregulated businesses.
20.95.2. Motivation#
globally launch first useful GNU Taler service without requiring a license
protect users from DDoS / spam / phishing
20.95.3. Requirements#
There are two high-level key requirements:
global availability for consumers; few sites or e-mail recipients would be happy if they cannot be contacted by a large fraction of their partners anymore. Thus, we need to have bank accounts for major currencies (USD, EUR, ideally more) and Bitcoin (BTC) as a stop-gap. It is probably OK to exclude parts of Asia or Africa initially, as many individuals or businesses would have few relevant global connections. Explanations for consumers withdrawing tokens must also be crystal-clear, especially that they do not get digital cash. We may want a new “bank dialect” to change user-facing terminology in the wallets to use language that is less payment-focused.
the paywalls must be well-documented, scalable to high traffic volumes and easy to deploy. Instructions given to the blocked humans must also be clear. Whitelisting must be possible to give services an easy way to unblock highly desireable users without forcing them to pay.
For the paywalls, we are mostly focusing on two:
paivana-httpd: reverse proxy for HTTP that adds a paivana-style paywall
pepsi: MTA/forwarder/proxy for SMTP that has a Taler payment gate and logic to learn whitelisted senders from monitoring receivers of outgoing traffic
This will cover the two main use-cases.
20.95.4. Proposed Solution#
Business:
Open bank accounts in various currencies
Consider getting no-action letters from regulators
Wallets:
Implement wallet dialect with non-payment captcha-oriented language
Ensure wallets respect ‘no deposit’ and ‘no-p2p’ settings nicely
Communicate special fee structure clearly on withdraw
Other development:
Implement, test and document Pepsi
update merchant backend to support wire method ‘void’ (auto-configured bank account payto://void/) for some particular settings.
Administration:
Deploy a single exchange in CAPTCHAS and hook it up to all of these accounts with some reasonable currency conversion ratio
Setup new web site explaining the solution
Setup paivana-httpd in front of our Git Web
Setup Pepsi in front of (some) of our e-mail accounts
20.95.5. Test Plan#
terms of service written and reviewed
website explaining system live
Operational exchange in USD, EUR, BTC converting to CAPTCHA
merchant backend (single-instance) for testers with that exchange
void account supported by merchant backend / SPA
paivana-httpd works for git-www.taler.net
pepsi works for say grothoff.org, other self-hosted team members
20.95.6. Definition of Done#
Exchange, Merchant backends and “demonstrators” (Git-Web, SMTP) live
20.95.7. Alternatives#
get a license first and share revenue; very difficult to do globally, and without global operation very limited utility as users would be excluded because they cannot pay due to unavailability of the payment system
even partial, deferred payments or incentives paid to operators would likely move the solution towards being seen as bad creative ways to try to side-step the need for a license, so only 100% fees are a good choice here
20.95.8. Drawbacks#
harder to motivate deployments