095-captcha-100.rst (5190B)
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 72 - Open bank accounts in various currencies 73 - Consider getting no-action letters from regulators 74 75 Wallets: 76 77 - Implement wallet dialect with non-payment captcha-oriented language 78 - Ensure wallets respect 'no deposit' and 'no-p2p' settings nicely 79 - Communicate special fee structure clearly on withdraw 80 81 Other development: 82 83 - Implement, test and document Pepsi 84 - update merchant backend to support wire method 'void' 85 (auto-configured bank account payto://void/) for some 86 particular settings. 87 88 Administration: 89 90 - Deploy a single exchange in CAPTCHAS and hook it up 91 to all of these accounts with some reasonable currency 92 conversion ratio 93 - Setup new web site explaining the solution 94 - Setup paivana-httpd in front of our Git Web 95 - Setup Pepsi in front of (some) of our e-mail accounts 96 97 98 Test Plan 99 ========= 100 101 - terms of service written and reviewed 102 - website explaining system live 103 - Operational exchange in USD, EUR, BTC converting to CAPTCHA 104 - merchant backend (single-instance) for testers with that exchange 105 - void account supported by merchant backend / SPA 106 - paivana-httpd works for git-www.taler.net 107 - pepsi works for say grothoff.org, other self-hosted team members 108 109 110 Definition of Done 111 ================== 112 113 - Exchange, Merchant backends and "demonstrators" (Git-Web, SMTP) live 114 115 116 Alternatives 117 ============ 118 119 - get a license first and share revenue; very difficult to do globally, 120 and without global operation very limited utility as users would be 121 excluded because they cannot pay due to unavailability of the payment 122 system 123 - even partial, deferred payments or incentives paid to operators would 124 likely move the solution towards being seen as *bad* creative ways to 125 try to side-step the need for a license, so only 100% fees are a good 126 choice here 127 128 Drawbacks 129 ========= 130 131 - harder to motivate deployments 132 133 Discussion / Q&A 134 ================ 135