UI automation is necessary for accessibility [LWN.net]

UI automation is necessary for accessibility

Posted Jul 13, 2026 12:04 UTC (Mon) by kleptog (subscriber, #1183)
In reply to: UI automation is necessary for accessibility by farnz
Parent article: An update on the scraper situation

I wouldn't expect the unit of transaction to be a "page". What does that even mean for a single page app?

I would think some kind of credit token system, where a token is valid for a single or group of sites for a fixed period. So you would go to wikipedia and it would ask for a credit token. Your browser would negotiate and then authenticate with a payment broker and you would get a token that would be (e.g) 5c for one day access under some reasonable rate limit. Your browser couldn't just start accessing random sites because the credit token is for one site only. I'm sure people could come up with something.

But there would have to be something in it for me. Like, no more ads.

The problem is, this infra would cost money which has to be paid for somehow. To get a micro-payments system off the ground it would require many open-source projects and commercial projects to stick in their own time and money to implement it. The operational cost is not that high, but the initial cost to build it is huge. At least for the open-source projects, the internet would have to literally fall apart before there's enough will to make a micro-payments setup happen, some groups will oppose it out of principle. Just like there are reasonable use-cases for being able to monitor HTTPS traffic without killing security but it is opposed out of principle.

to post comments

UI automation is necessary for accessibility

Posted Jul 13, 2026 12:08 UTC (Mon) by farnz (subscriber, #17727) [Link] (24 responses)

It's worse than your last paragraph implies, because the operational costs are huge, too. You have to handle allegations of fraud, both genuine and malicious, as well as actual fraud.

And that adds up to a huge cost for someone - you can simply refuse to handle fraud, and make it the payer's issue, but then, as has happened with things like eGold, you fall apart because you're a haven for crooks. Or, you end up being a broker like PayPal - but again, if someone can do payments brokering cheaper than PayPal, why haven't they taken over PayPal's market?

UI automation is necessary for accessibility

Posted Jul 13, 2026 22:13 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (12 responses)

OK, so someone hacks your account and steals 50 cents of your daily distributed tokens. Big deal. Or you're a site operator and you have to refund 5 cents for a page view.

UI automation is necessary for accessibility

Posted Jul 14, 2026 6:18 UTC (Tue) by kleptog (subscriber, #1183) [Link] (10 responses)

> Or you're a site operator and you have to refund 5 cents for a page view.

I dont see what that would ever be necessary. If the website was accessed then there is a payment required. The fact the site got the token proves there was an request. Where the token came from is not relevant.

If someone hacks my account and then uses that money to buy lotto tickets, the seller of the tickets is never obligated to refund them. It's only between me and my bank.

Suppose each token is worth one cent and that buys you one day of access to one site. Either the scanner has 1000 distinct tokens which means it cost €10, or they use the same token but then they identify themselves as the same actor and so the same rate limit.

UI automation is necessary for accessibility

Posted Jul 14, 2026 8:44 UTC (Tue) by farnz (subscriber, #17727) [Link] (7 responses)

If someone hacks my account and then uses that money to buy lotto tickets, the seller of the tickets is never obligated to refund them. It's only between me and my bank.

In the jurisdictions I'm aware of, that's not true - if someone uses my bank card to purchase lotto tickets, then the seller of the tickets either has to show that they required a second factor for authentication (e.g. a PIN), or they get to refund the bank. And this also applies with stolen cash; if I can show that the cash you accepted was stolen from me (unusual that anyone can do this, mind), you get to make me whole (since you accepted stolen property), and the person you gave the lotto tickets to has a debt to you that they've got to repay.

UI automation is necessary for accessibility

Posted Jul 14, 2026 16:02 UTC (Tue) by kleptog (subscriber, #1183) [Link] (6 responses)

> In the jurisdictions I'm aware of, that's not true - if someone uses my bank card to purchase lotto tickets, then the seller of the tickets either has to show that they required a second factor for authentication (e.g. a PIN), or they get to refund the bank.

At least here, it's the bank that is liable, and they have a contract with the merchant to shift the liability to them. You can't go after the merchant yourself. It's actually fairly evil that the CC company takes 3% but shifts the liabilities to the merchants, that's cartels for you.

But credit cards are one of the more cumbersome payment methods around. It's easier when the site shows a QR code, you scan it, and approve the payment, done.

> And this also applies with stolen cash; if I can show that the cash you accepted was stolen from me (unusual that anyone can do this, mind), you get to make me whole (since you accepted stolen property), and the person you gave the lotto tickets to has a debt to you that they've got to repay.

You're going to have to give me a citation here, because I can't find any examples of this. It appears many countries special case cash so that if you do a cash transaction in good faith you're in the clear. If it wasn't so, people wouldn't accept cash and commerce would fall apart.

(At least for the US it appears to be a common-law principle. For NL it's Article 3:86 BW which protects all good faith transactions in general.)

I really can't imagine any situation where someone stealing money (or equivalent) from you could lead to you having a claim against a third-party.

UI automation is necessary for accessibility

Posted Jul 14, 2026 16:06 UTC (Tue) by farnz (subscriber, #17727) [Link]

You, as the recipient of the cash, are handling stolen goods (at least in the USA and UK). That requires you, as the handler of stolen goods, to return them to the original owner once you become aware that they're stolen, in order for the transaction to count as a "good faith" transaction.

In practice, this is extremely hard to prove - it's not enough that I show that person A stole cash from me, and that they spent cash with you, but I also have to show that person A spent the cash they stole from me with you. But, in that circumstance, where you have the cash that was stolen from me, you're on the hook to return it to me, and you get a claim against the thief.

UI automation is necessary for accessibility

Posted Jul 14, 2026 19:48 UTC (Tue) by Wol (subscriber, #4433) [Link] (4 responses)

> You're going to have to give me a citation here, because I can't find any examples of this. It appears many countries special case cash so that if you do a cash transaction in good faith you're in the clear. If it wasn't so, people wouldn't accept cash and commerce would fall apart.

As far as I'm aware the only way the UK "special case"s cash is as "legal tender". That means, if I owe you money and I offer you legal tender, the OFFER is sufficient to wipe the debt. In law, you have to either accept the cash, or write off the debt.

The only reason cash is "special" is that - as farnz points out - it's incredibly difficult to prove it's stolen. Unless of course it's never officially entered circulation and there's a record of the serial numbers, or it's plastered all over with the ATM ink that explodes everywhere if there's an attempt to steal / break into the ATM.

Cheers,
Wol

Cash payments are special

Posted Jul 15, 2026 21:44 UTC (Wed) by kleptog (subscriber, #1183) [Link] (3 responses)

Which is why I asked for references, because all the ones I could find specifically say they cash is special. See for example [1] which specifically notes the situation was settled for banknotes in the UK in an important case in 1758 which I'm too lazy to look up.

In particular:

> When the identifiability of an asset falls toward zero, the owner’s incentive to search for it after a theft falls toward zero, the buyer’s incentive to investigate title falls toward zero, and the value of any title rule as a deterrent to theft falls toward zero. At that limit, the efficient legal rule is not a better-calibrated allocation between owner and purchaser. It is the abolition of the contest: the recipient in good faith and for value takes a fresh title good against the whole world, and the transaction is final.

If the hypothetical tokens for payment for web access are effectively anonymous and fungible, then every transaction is by definition in good faith and final.

See also the "Money has no earmark" rule.

[1] https://singulargrit.substack.com/p/the-asset-the-law-gav...

Cash payments are special

Posted Jul 16, 2026 8:42 UTC (Thu) by paulj (subscriber, #341) [Link]

> If the hypothetical tokens for payment for web access are effectively anonymous and fungible, then every transaction is by definition in good faith and final.

Just to thread that in with another sub-thread here (which I know Jon has indicated that it should be left to peter out) - this is why Monero (in addition to the much lower transaction fees) is better for online payments to something like Bitcoin. Monero's ledger is not transparent, and hence Monero is fungible - not so for Bitcoin.

Cash payments are special

Posted Jul 16, 2026 9:28 UTC (Thu) by farnz (subscriber, #17727) [Link] (1 responses)

I followed that link, and looked up the case law it references; the key to it is that there are two separate rules around the return of stolen goods:

Compensation for loss; someone stole a car from me, you took it in, failed to make adequate checks for whether it was stolen, and parted it out. I now have a claim against you for the value of the stolen car. The case law the site you reference references says that a good faith cash transaction definitionally cannot fall under this rule - not checking at all qualifies as "adequate checks" for cash, since otherwise it would be impossible for a cash economy to function.
Return of actual stolen property. This is impossible for coins (since any suitable identifying marks would make it not a coin), but is possible, if improbable, for bank notes; if the victim of theft can show that they scrupulously and accurately record the serial numbers of all bank notes of that value that they receive and lose (both spent and stolen), and you have a stolen note in your possession, then this is enough to establish that you must either return the stolen bank note or something of equal value.

Case law only deals with the first of those situations; the second is as-yet untested in court, but based on similar cases with postage stamp collections, it's plausible that the courts would rule that because I'd shown that you had the specific cash stolen from me, you have to return it to me.

Cash payments are special

Posted Jul 16, 2026 14:24 UTC (Thu) by kleptog (subscriber, #1183) [Link]

> Return of actual stolen property. This is impossible for coins (since any suitable identifying marks would make it not a coin), but is possible, if improbable, for bank notes; if the victim of theft can show that they scrupulously and accurately record the serial numbers of all bank notes of that value that they receive and lose (both spent and stolen), and you have a stolen note in your possession, then this is enough to establish that you must either return the stolen bank note or something of equal value.

Nope. That was the whole point of the Miller vs Race 1758 case. At the time cash notes were a sort of "bearer cheques" and so easily identifiable: they had a bank name and a person's signature on it. The judge ruled that, even though the bank note was easily identifiable, it had currency and as far as the law was concerned not identifiable (no earmark).

It has no Wikipedia article, but the equivalent case in Scotland is here: https://en.wikipedia.org/wiki/Crawfurd_v_The_Royal_Bank

> In a unanimous decision, the judges decided "that money is not subject to any vitium reale; and that it cannot be vindicated from the bona fide possessor, however clear the proof [of] the theft may be";

Who is on the hook

Posted Jul 14, 2026 13:08 UTC (Tue) by corbet (editor, #1) [Link] (1 responses)

If somebody buys an LWN subscription with a stolen credit-card number, we definitely end up having to refund it — and pay a chargeback fee as well. Merchants only get the credit-card guarantee in settings where the card itself is physically present. So I wouldn't assume that some future micropayment system would be more friendly to the selling side.

That said, solving the micropayment problem is a bit off-topic for LWN, unless, of course, you actually have the code to do it. So perhaps it's time to let this subthread wind down.

Who is on the hook

Posted Jul 14, 2026 15:45 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

If you _want_ to experiment with micropayments, there's an x402 project that you can deploy right now: https://www.linuxfoundation.org/press/linux-foundation-is...

And it's even on-topic, given that it's managed by our very own Linux Foundation!

UI automation is necessary for accessibility

Posted Jul 14, 2026 8:40 UTC (Tue) by farnz (subscriber, #17727) [Link]

For starters, it's not guaranteed to be 50¢; if I put in enough money to cover my likely use once a year (say when I get my tax return, if I'm US-based), it's potentially a lot more when you're looking at 0.02¢ for a page view.

And it's not just a 5¢ refund - it's the cost of determining if I'm legitimate (since if you refund upon request, all the people you want to block will automate demanding a refund), too, plus the cost of handling me if you decide my refund request is not legitimate, but I pursue you further.

UI automation is necessary for accessibility

Posted Jul 13, 2026 23:25 UTC (Mon) by quotemstr (subscriber, #45331) [Link] (10 responses)

If you're interested in this space, check out the Etherium ecosystem, its compute "juice", and various slashing strategies. You don't have to be some kind of "crypto bro" to appreciate the hardness of the problems you get when you try to simultaneously have 1) accountability, and 2) anonymity.

In the present discussion, we can model web fetches as "spends" of some token (whether it's monetary or not!). Accessing a web page? That's a spend. How do you prevent people just copying access credentials to 1,000 machines and spending them in parallel? That's the double-spend problem, which crypto people have given a ton of thought. How do you maintain rate limits tied to an actor? This problem is isomorphic to wallet management. How do you give humans some reasonable number of accesses per day without enabling crawlers to simulate 10,000 "humans" per box?

The solution is going to come down to some zero-knowledge identity attestation scheme. You just can't have regular people competing on an open market with big scrapers for access tokens, and the only way you can distinguish regular people (so they get free or cheap access tokens) and bots (who should pay market rate) is to remotely attest a unique human identity in such a way as to prevent creating infinity "humans" out of thin air but also reveal nothing about which human is doing want. Devilishly hard problem.

There *are* points in mechanism-design space where all this stuff works out, but it's *absolutely* not trivial, especially if you want to maintain privacy. All the people in this thread saying we should "just" rate-limit humans or machines or that we should "just" bootstrap a micropayments ecosystem are barely scratching the surface of how hard this problem really is. It's not so much even the cryptography (tons of recent progress here) but the social bootstrapping stuff.

What's worse is that our social structures aren't set up to incentivize solving the problem. No VC is going to get 1,000x returns on this stuff, academia and the state get distracted for various reasons, and on and on in ways I don't want to get into. It's a nasty chicken-and-egg problem that's important to solve.

UI automation is necessary for accessibility

Posted Jul 14, 2026 8:01 UTC (Tue) by taladar (subscriber, #68407) [Link] (9 responses)

Quite apart from the social and finance technical side there is also the issue that however you prefer to solve this problem you have just turned a simple stateless cacheable request into something that probably needs at least one database write or lookup or both and so it will both require a lot more resources to serve and be slower.

UI automation is necessary for accessibility

Posted Jul 14, 2026 15:48 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (8 responses)

This is not necessary, actually. You can do it statelessly via JWTs. Essentially, you just need to verify the asymmetric signature.

And given that all traffic now is served over encrypted HTTPS, we already need to do that for each request. In theory, this can even be folded into client TLS certificates.

UI automation is necessary for accessibility

Posted Jul 14, 2026 19:29 UTC (Tue) by NYKevin (subscriber, #129325) [Link] (6 responses)

How can you prevent double spending if the recipient does nothing with the JWT after validating it?

UI automation is necessary for accessibility

Posted Jul 14, 2026 22:05 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

A typical JWT access token expires within minutes. 10-15 minute expiration is very common.

A website would need to:

1. Validate that the token signature comes from a correct CA, and that the site is the correct audience for the token.
2. Check that it's not expired, with a reasonable clock skew window.
3. Rate-limit based on the token ID so that the bad actor can't DDoS your site during the token validity window.

This can all be done statelessly without any database. All the state can live in the token issuer that will also do all the billing-related stuff.

JWT as it exists now is not very suitable for this because of the privacy concerns. But there are multiple possible ways to fix them (and no, they don't require blockchain or ZKPs).

UI automation is necessary for accessibility

Posted Jul 15, 2026 15:02 UTC (Wed) by NYKevin (subscriber, #129325) [Link] (3 responses)

Step 3 is not stateless. You need to maintain a token bucket and update it with each request.

The state is ephemeral, which does make the problem easier. But it is very much "not free."

UI automation is necessary for accessibility

Posted Jul 15, 2026 17:23 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

Sure, but it doesn't need to be a global state. And realistically, it's not a problem to store a couple of megabytes of data. Assuming that each client ID is 128 bits, that's around 64k clients. If each one of them provides you with even 10 cents, that's a good problem to have!

Moreover, it won't even require a lot of local storage if you use random-based sampling. This was my interview question many years ago :)

The idea is to select a random number from 0 to N and if it's equal to N, you start tracking the requests for this user. Then a standard token bucket is sufficient. You can dynamically vary N depending on the overall load.

UI automation is necessary for accessibility

Posted Jul 16, 2026 8:13 UTC (Thu) by taladar (subscriber, #68407) [Link] (1 responses)

In what weird kind of dream world do you live in where people are willing or even able to pay 10 cents per request or even per day for every website they visit?

UI automation is necessary for accessibility

Posted Jul 16, 2026 17:28 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

10 cents is the upper limit per day for all the websites that you visit. The idea is that rate-limiting would only affect a visitor if they are already hammering the site with unreasonable number of requests.

UI automation is necessary for accessibility

Posted Jul 14, 2026 22:08 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

Sorry, misunderstood your question. The entity that mints the token should also do the crediting. The act of creating the token itself is the billable action. If you don't use the minted token, then too bad for you.

Proof of humanity or payment

Posted Jul 15, 2026 10:10 UTC (Wed) by farnz (subscriber, #17727) [Link]

This also feels like it combines nicely with quotemstr's proposal that you have some form of "proof of humanity" to bypass rate limiting. If I can prove my humanity to the token issuer (TLS client cert, JWT, whatever), I get a reduced rate, while someone who can't (or doesn't want to) can pay full rate for access tokens.