UI automation is necessary for accessibility [LWN.net]

UI automation is necessary for accessibility

Posted Jul 14, 2026 8:01 UTC (Tue) by taladar (subscriber, #68407)
In reply to: UI automation is necessary for accessibility by quotemstr
Parent article: An update on the scraper situation

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.

to post comments

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.