095-captcha-100.rst (5187B)
1 DD 95: Captcha 100 2 ################## 3 4 Summary 5 ======= 6 7 One of the key applications we had always envisioned was the use of GNU Taler 8 for spam protection. A related application domain is Captcha's, where a server 9 needs some 'proof-of-humanity' to protect itself from handling expensive 10 requests on behalf of some out-of-control automated bot process. The key 11 insight is that here the operator is not necessarily interested in receiving 12 revenue from GNU Taler, but primarily in limiting their exposure to the attack 13 by increasing the cost to the initiator of the request. Furthermore, the 14 operator is often willing to inconvenience the sender, be it by various spam 15 filters (which have false-positives) or forcing the sender to solve Captcha's 16 or computational puzzles (Anubis). These existing methods are today often 17 failing, especially as LLMs enable bots to formulate messages that pass spam 18 filters or to solve Captcha's. In this context, forcing the sender to make a 19 Taler deposit becomes simply another form of imposing a cost, and one that 20 would cost an attacker more dearly. 21 22 We can quickly enable this use-case by setting the Taler fees to 100%. At 23 this point, the "merchant" never actually receives any money (and customers 24 that withdrew tokens cannot get money when they return them either), so the 25 operator would not be a payment service as they do not give money to anybody. 26 While this is less attractive to the recipient, it would still be effective at 27 blocking bots. At the same time, this model can be rolled out globally pretty 28 quickly because at 100% fees we do not need a money transmitter or e-money 29 issuer license, as we no longer transmit money -- we only accept money in 30 return for a digital service, like many other regular unregulated businesses. 31 32 Motivation 33 ========== 34 35 - globally launch first useful GNU Taler service without requiring a license 36 - protect users from DDoS / spam / phishing 37 38 Requirements 39 ============ 40 41 There are two high-level key requirements: 42 43 - global availability for consumers; few sites or e-mail recipients would be 44 happy if they cannot be contacted by a large fraction of their partners 45 anymore. Thus, we need to have bank accounts for major currencies (USD, 46 EUR, ideally more) and Bitcoin (BTC) as a stop-gap. It is probably OK 47 to exclude parts of Asia or Africa initially, as many individuals or 48 businesses would have few relevant global connections. Explanations for 49 consumers withdrawing tokens must also be crystal-clear, especially 50 that they do not get digital cash. We may want a new "bank dialect" 51 to change user-facing terminology in the wallets to use language that 52 is less payment-focused. 53 - the paywalls must be well-documented, scalable to high traffic volumes 54 and easy to deploy. Instructions given to the blocked humans must also 55 be clear. Whitelisting must be possible to give services an easy way 56 to unblock highly desireable users without forcing them to pay. 57 58 For the paywalls, we are mostly focusing on two: 59 60 - paivana-httpd: reverse proxy for HTTP that adds a paivana-style paywall 61 - pepsi: MTA/forwarder/proxy for SMTP that has a Taler payment gate and 62 logic to learn whitelisted senders from monitoring receivers of 63 outgoing traffic 64 65 This will cover the two main use-cases. 66 67 Proposed Solution 68 ================= 69 70 Business: 71 - Open bank accounts in various currencies 72 - Consider getting no-action letters from regulators 73 74 Wallets: 75 - Implement wallet dialect with non-payment captcha-oriented language 76 - Ensure wallets respect 'no deposit' and 'no-p2p' settings nicely 77 - Communicate special fee structure clearly on withdraw 78 79 Other development: 80 - Implement, test and document Pepsi 81 - update merchant backend to support wire method 'void' 82 (auto-configured bank account payto://void/) for some 83 particular settings. 84 85 Administration: 86 - Deploy a single exchange in CAPTCHAS and hook it up 87 to all of these accounts with some reasonable currency 88 conversion ratio 89 - Setup new web site explaining the solution 90 - Setup paivana-httpd in front of our Git Web 91 - Setup Pepsi in front of (some) of our e-mail accounts 92 93 94 Test Plan 95 ========= 96 97 - terms of service written and reviewed 98 - website explaining system live 99 - Operational exchange in USD, EUR, BTC converting to CAPTCHA 100 - merchant backend (single-instance) for testers with that exchange 101 - void account supported by merchant backend / SPA 102 - paivana-httpd works for git-www.taler.net 103 - pepsi works for say grothoff.org, other self-hosted team members 104 105 106 Definition of Done 107 ================== 108 109 - Exchange, Merchant backends and "demonstrators" (Git-Web, SMTP) live 110 111 112 Alternatives 113 ============ 114 115 - get a license first and share revenue; very difficult to do globally, 116 and without global operation very limited utility as users would be 117 excluded because they cannot pay due to unavailability of the payment 118 system 119 - even partial, deferred payments or incentives paid to operators would 120 likely move the solution towards being seen as *bad* creative ways to 121 try to side-step the need for a license, so only 100% fees are a good 122 choice here 123 124 Drawbacks 125 ========= 126 127 - harder to motivate deployments 128 129 Discussion / Q&A 130 ================ 131 132