1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
|
Supporting DDoS blockers with Taler
===================================
Overview:
In many IP reputation systems, CAPTCHAS are used to separate humans from
bots, allowing humans to access resources while blocking automated
attackers. However, especially complex modern Web sites require many
resources and thus can trigger a large number of CAPTCHAS, limiting
usability. The problem is compounded if users access the Web via
Tor or VPNs, as this means mechanisms to track users cannot be used to
reduce the number of CAPTCHAS.
We propose an alternative where we use Taler-style micropayments to
automatically pay for access to resources. The micropayments would
be done in a provider-specific currency, effectively turning Taler
payments into anonymous credentials or tokens. Tokens would be
provided by the provider in exchange for the user solving CAPTCHAS,
but instead of solving one CAPTCHA per request a user may be issued
thousands of tokens for one CAPTCHA, which could then be used across
multiple websites without creating anonymity/linkability issues.
Rationale:
Reducing the use of CAPTCHA's improves usability for everybody, and
by (re)using Taler we limit the need for security audits for custom
solutions. Furthermore, it also becomes conceivable to move from
CAPTCHAS to actual payments or other mechanisms to hand out tokens
(i.e. researchers that legitimately need to perform automated
requests may apply for a token grant).
Challenges:
To make this work, we need to address three issues:
1) Taler needs to add support for an 'auto-pay' flag that would be
associated with a currency. If the flag is present, the wallet
would not interactively ask the user to confirm the payment, but
just automatically pay (if funds are available; otherwise it
should redirect to the provider's "bank" where the user would
solve a CAPTCHA to obtain tokens). This is relatively trivial
and necessary for usability.
2) Right now, the Wallet-Web site interaction uses JavaScript. This
is not acceptable for some of the CAPTCHA-use case domains, as
Tor users may disable JavaScript and injecting Taler-specific
JavaScript into generic Web sites is messy.
3) The solution needs to work with embedded resources and POST requests,
where running a JavaScript interaction for each resource is both
too expensive and rather complicated. Instead, a page should indicate
that all resources associated with a DOM require payment, and then
payment should automatically and efficiently be provided with each
request.
Required changes to Taler:
We mainly need to make three changes:
1) Support for auto-pay (rather trivial), by tagging currencies, and
by redirecting to a "bank" page to withdraw tokens if funds are
insufficient.
2) In the 'withdraw' protocol, the bank should be able to specify the
payment system provider and tell the wallet to skip the interactive
selection/confirmation dialog (as there is only one provider and
thus no choice to be made). This change is also rather trivial.
3) Change Wallet to check for HTTP headers requesting payment for the
DOM, and then inject an HTTP header in all subsequent requests generated
by that page with the payment (i.e. signing the request's URL with
the coin/token). This change is non-trivial, and may require
browser-specific solutions.
Technical differences to captcha-plugin-draft.txt:
* both solutions use RSA blind signatures for privacy, my reading
of the draft is that 256-bits are proposed, while Taler leaves
the bit length variable (to the payment service provider).
* Taler uses Ed25519 for "tokens", while the draft proposes
random nonces as tokens. Taler can thus spend tokens using
EdDSA signatures, while the draft uses encryption (of the
nonce/Token) with the server's key and a keyed HMAC. I do not
attribute either design a significant performance advantage,
except with Taler the server could skip checking either signature
(to shard load if stressed), while the draft requires server-side
decryption to obtain the nonce.
Taler's use of an EdDSA signature is also more flexibile for other
applications, but in this particular context there is no
significant difference to the keyed HMAC with encrypted nonce.
* Instead of using the draft's scheme for withdrawing coins by
a magic HTML form attribute, Taler's bank API would be used,
where the bank (in this case the CAPTCHA-DDoS-protection provider)
signals to the wallet that a withdraw operation is being authorized
using a JavaScript signal. This is significantly more efficient,
as registering a signal handler is O(1) per page, while parsing
all DOMs to find a magic HTML form attribute is O(n) (where n is
the size of the DOM).
Scalability:
Given that DDoS-protection has weaker requirements, it would be
trivial to use regional double-spending detection instead of global
double-spending detection. Also, a custom exchange could use
probabilistic data structures to improve efficiency.
Alternatively, multiple currencies could be used; for this, the
HTTP header requiring auto-pay should simply specify the desired
currency, enabling further sharding of the load.
Benefits of integrated solution with Taler:
* significant re-use of expertise, code, auditing effort and
protocol design
* provider-independent free software solution
* possibility to trivially "upgrade" to payment or data grants
* solution that is not Tor-specific, plugin should work for
various browsers
* 1 bit information leakage (is plugin present), instead of 2 bits
(if there are two separate plugins)
* Tor wants to solve CAPTCHA problem, Tor wants to support
anonymous payments. This could solve both with 98%
shared code.
|