UI automation is necessary for accessibility [LWN.net]

UI automation is necessary for accessibility

Posted Jul 13, 2026 9:34 UTC (Mon) by farnz (subscriber, #17727)
In reply to: UI automation is necessary for accessibility by nhippi
Parent article: An update on the scraper situation

There's a huge social problem with frictionless anonymous micropayments (and one that's hard to solve via technical means): how do you stop bad actors from being the primary users of the system?

For the system to be useful, it has to be able to transfer large sums of money to the sites; if you're collecting 0.02¢ per page render, you need to be able to collect $20 million if you're hit by 1 billion accesses. That creates two social problems:

If I'm a bad actor, what makes it not worth my while infecting millions of clients with malware to collect 0.02¢ per client via my dodgy network of apparently legitimate (but actually not) sites?
If I'm a payer, how do I recover my money if a bad actor infects my device and causes it to access billions of pages? How do you distinguish "payment made due to bad actor" from "payer had buyer's remorse"?
If I'm a bad actor, how do you stop me accessing millions of pages to copy, then using the money recovery mechanism to ensure that I don't actually pay, without preventing legitimate payers from having access to the money recovery mechanism?

These are all really hard problems to solve - and our current systems don't solve them particularly well, but they just about manage on the basis that no-one in the network is truly anonymous, and thus you can use the courts to recover your money. That stops working if, instead of a small number of large cases, you have a truly large number of "de minimis" cases.

to post comments

UI automation is necessary for accessibility

Posted Jul 13, 2026 11:04 UTC (Mon) by paulj (subscriber, #341) [Link] (17 responses)

Perfect is the enemy of good enough perhaps.

There are distributed payment systems in fairly wide use today, 1 in particular which is viable for micro-payments down to about a ¢. They just don't do recovery. So the answer to "but recovery is hard" quite possibly is that you can not solve it and the resulting system may still be adequate for use - if not as perfect as you'd advocate for.

Indeed, a number of people would argue that some centralised 'recovery' authority able to reverse transactions at a network level would be a *malfeature* in any distributed, online, (micro)-payments system. Non-reversability (at a network level), they would argue to be an essential feature (and this would *not* preclude availing of legal action to recover funds).

UI automation is necessary for accessibility

Posted Jul 13, 2026 11:59 UTC (Mon) by farnz (subscriber, #17727) [Link] (16 responses)

Your last paragraph is self-contradictory; legal action involves a centralized "recovery" authority (the legal system) getting involved to force the reversal of a payment, but you're also saying that the existence of that authority is a malfeature that should not exist. It can't be both.

Without it, though, you face the fraud problems; sophisticated users can avoid being bitten too badly by fraud, but you're going to have to solve the mass-market chicken-and-egg problem somehow. Most people won't risk their money without a decent chance of a high reward, and without most people being willing to use whatever "fraud is your problem" payments network you create, sites have no incentive to require people to use it (since by doing so, they lose all their users).

And that, in a nutshell, is the issue that any micropayments system has to solve somehow. How do you bootstrap popularity of a micropayments system if payees won't come on board en-masse until there's a significant number of people willing to pay with it, and payers won't come on board until there's either very low risk of fraud, or payees have signed up en-masse?

After all, if there is a system that is completely viable for small payments, there would be a site like Patreon, Ko-fi, Substack, or similar that accepts it - but none of the big "pay your content creator" sites do accept alternatives to cards.

UI automation is necessary for accessibility

Posted Jul 13, 2026 12:14 UTC (Mon) by paulj (subscriber, #341) [Link] (15 responses)

To be clear, I wrote in reply to the possibility /micro-payment system/ must have some kind of recovery mechanism, even though (as you stated) that is technically very hard to solve, which kind of falls out of your comment.

I agree, it is technically hard to solve, and I agree with you it is a social problem. So I'm pointing out that there are micro-payment systems which just ignore that problem, and it is indeed left as a social problem to solve. In which case problem #3 is solved - it can't happen. Problem #2 is potentially solvable, depending on context. Problem #1 is partly solved - the resources were paid for, and the server of the resources was not (financially) harmed.

The implication in your comment was there was a problem that the micro-payment system itself had to solve somehow, even though it was hard to solve / unsolvable at the technical level. I'm saying micro-payment systems definitely already exist, with reasonably non-trivial use, and they do so without having tried to tackle the problem you (possibly) implied needing solving.

I.e., the micro-payment system can go ahead and be used, and that social issue of recoverability can be left for later solving (by probably a plethora of different social solutions, which may evolve). It's not an obstacle as such.

I can pay for a variety of things (digital services particularly) with said micro-payment system. I can buy (e)SIMs, VPNs, email hosting, VPs, Proton accounts and other similar services, AI hosting, contract developors, donate to various orgs (inc. FSF), etc., etc.. It's already bootstrapped and being used. Maybe it's not perfect enough for you, but it's good enough for a chunk of users.

UI automation is necessary for accessibility

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

If you don't solve these problems to a point where, as an unsophisticated user, my funds are not at risk if I'm hacked, then you're limited to being something for sophisticated users, which means that the web as a whole can't use the system, since most users aren't sophisticated.

Any such system that's good enough for mass adoption would be in a good position to replace PayPal, Venmo, Patreon and Ko-fi; once you've done that, then you've got a system that's viable for the mass market. Until then, you have a minority use system that's suitable for sophisticated users, but excludes most of the world.

UI automation is necessary for accessibility

Posted Jul 13, 2026 12:52 UTC (Mon) by paulj (subscriber, #341) [Link] (13 responses)

Nothing would stop a PayPal like entity acting as a gateway to whatever underlying micro-payment system. If a PayPal like frontend is what is needed for "normal" users, nothing technical stops that.

The fundamental issue, as you already stated, is that the blocker is a social issue. Though, it's just /not/ the one you stated. Rather, the reason we can't have a global, ubiquitous, universal access, distributed micro-payments systems is the same reason that the existing PayPals, Venmos, etc., can't act as a gateway to such a system: The governments of the world do not want it - they only want something they can control.

And so long as there are different and unaligned blocks of states in the world, we can never have that global, ubiquitous, universal access system.

And even if all were aligned, they would not allow us to have a /private/ system, and quite probably also not a universal-access system.

However, at the technical level, the micro-payments system(s) are built and are in-use. I wish LWN would integrate something with the accounts system, so I could add "Pay for LWN subscription" to my list of digital stuff I can pay for with distributed Internet money.

UI automation is necessary for accessibility

Posted Jul 13, 2026 13:00 UTC (Mon) by daroc (editor, #160859) [Link] (1 responses)

There are almost certainly complications on our end to receiving payment in that way, but I don't think we would be opposed in principle — letting people pay us is always a good idea. The difficult part would probably be integrating things with our payment processor.

Could I ask what form of distributed internet money you prefer, just so that I know what to look for when investigating the possibility?

UI automation is necessary for accessibility

Posted Jul 13, 2026 14:33 UTC (Mon) by paulj (subscriber, #341) [Link]

My preferred one would be Monero. It's technically beautiful. It's private. Transaction fees are low enough to be viable for ¢ level payments. BTC is obviously the big one - but higher fees.

I don't know about your payment processor. There are open-source distributed Internet money payment processing platforms you can self-host, and integrate yourself into your site. E.g., BTCPayServer, MoneroPay (moneropay.eu) - I don't know how good those are. There are also service providers, like mixpay.me. Some of the big payment processors are starting to get into accepting some crypto payments - but usually heavily constrained by jurisdiction, which may make it less attractive for the payer even if it might be more convenient for the payee.

UI automation is necessary for accessibility

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

But that in turn is the core of the problem - there's nothing unsolved in the technical arena there.

What we lack is the PayPal-like frontends that make it usable for the ordinary person - and I don't buy your "government blocks it" conspiracy theory, given that entities like Coinbase, Crypto.com, Binance, Kraken and others are perfectly permitted to trade in various cryptocurrencies, and there exist entities like MetaMask on top that also supply cryptocurrency wallets in the open and legally.

UI automation is necessary for accessibility

Posted Jul 13, 2026 13:59 UTC (Mon) by paulj (subscriber, #341) [Link] (9 responses)

It's not a conspiracy theory. Governments will not allow global, universal-access distributed payments system to integrate easily with their own financial systems (inc. the kinds of retail-user friendly entities you gave examples of). Firstly, because there are a number of unaligned blocks of states, and at least 2 of those blocks wish to heavily limit (if not entirely block) access to/integration with the payments system in their own blocks to certain other blocks/states. Secondly, because nearly all are implacably opposed to entities/people within their blocks having access to distributed, universal-access payments systems.

Those are not conspiracy theories, those are basic facts of regulations that governments have brought in and are bringing in more and more regulations to strengthen.

All the entities you mention are legally or de facto unavailable to many people across the world. MetaMask is open-source and can't be stopped even if Consensys disappeared tomorrow, but it does not integrate with the traditional financial system either (AFAIK).

We can not have a global, universal access, distributed micro-payments because of those social reasons. What we have today are a number of 'islands' of gated-access micro-payments systems, with high-friction or even fully-blocked channels between them; and running in parallel alongside those systems are a couple of much smaller - but growing - truly distributed, universal-access micro-payments systems. At best, if somehow all those blocks were aligned, we could have a global, semi-distributed, *gated-access* micro-payments system, given the stance of many governments; but then we'd still have the truly distributed, universal-access micro-payments systems running alongside them.

UI automation is necessary for accessibility

Posted Jul 13, 2026 14:02 UTC (Mon) by farnz (subscriber, #17727) [Link] (8 responses)

But, while we have these entities, they're worse for unsophisticated users than things like PayPal (which is also not a "global, universal-access payments system" by your standard, since it's blocked in some states).

And I'm saying that unless you can displace at least one of PayPal, Ko-fi, Patreon or Venmo, you've not got a system that's suitable as a micropayments system; you've got something that sophisticated users who can manage their own fraud risk can use, but not something suitable for the mass market.

UI automation is necessary for accessibility

Posted Jul 13, 2026 15:12 UTC (Mon) by paulj (subscriber, #341) [Link] (7 responses)

> unless you can displace at least one of PayPal, Ko-fi, Patreon or Venmo, you've not got a system that's suitable as a micropayments system;

The point is we have no universal micropayments system because we have high regulatory friction.

A universal micropayments system would not displace the examples you give, rather those examples would become gateways to such a universal system - in addition to allowing those who wished to directly interact with said universal micro-payments system with software under their own control.

That none of those examples you give easily be integrated with (and are not universally accessible - e.g., I don't think I can use Venmo, and possibly you can't either if I remember correctly about where you're based), is because of a lack of a suitable universal micro-payments system. Which is cause of high regulatory friction (including severe fragmentation). Which is a social problem. ;)

UI automation is necessary for accessibility

Posted Jul 13, 2026 15:19 UTC (Mon) by paulj (subscriber, #341) [Link]

And to be clear: I can't buy an eSIM with Venmo - cause I can't access Venmo. Even if I have access to something like PayPal, many other people do not and it could well be that the person/entity I want to make a financial transaction with does not have access.

For a large chunk of the world, it is very difficult to conclude financial transactions with them, via the "retail friendly" way - and the methods available are not suitable for micro-payments (and are not recoverable either!). For a certain section of the world there is no available method.

*Other* than the distributed Internet money methods - those work well. And the friction of the other methods is such that even many "normal users" will be willing to overcome the UI-overheads. We /could/ easily have the retail friendly UIs, and integration with the types of entities you list, if not for the high regulatory friction.

So it's all social, as far as I'm concerned.

UI automation is necessary for accessibility

Posted Jul 13, 2026 15:31 UTC (Mon) by farnz (subscriber, #17727) [Link] (5 responses)

You're looking too far into the future - I'm saying that if there exists a system that's suitable for micropayments, there would be a Ko-fi, PayPal (friends and family only - I'm not expecting the full gamut of PayPal services to be taken over by it), Venmo, Zelle, or similar service competitor built around that system, and demonstrating that the system is suitable by being a friend-to-friend money transfer system for people in the USA (only - I'm not expecting this to be a global system) that outcompetes the existing payment systems.

If you can't build a system that's better than the existing payment systems for one country, then your assertion that your system is better than the existing payment systems is suspect; why hasn't someone used the network to outcompete the existing players?

UI automation is necessary for accessibility

Posted Jul 13, 2026 16:10 UTC (Mon) by paulj (subscriber, #341) [Link] (4 responses)

Well,

a) even within a country there is very high regulatory friction (true for at least 2 of the biggest blocks in the world)

b) despite that friction, there are a number of places that do accept universal, distributed, micro-payments. And I find it as easy, if not easier, to use than the "retail friendly" stuff.

E.g., I topped up my kid's eSIM and I can just open the app on my Linux desktop, type my password (optional - my desktop is already obviously secured, but belt and braces), copy the address and amount from the payer's site (or the payer's processor) and send the payment. And it clears within a few minutes.

With the "retail friendly" stuff you prefer, the flow is similarish, but I type stuff (CC card) into the processor form, plus I have to type more stuff to satisfy algorithms, then I have to wait while it redirects through 1 or more websites - which sometimes fails - then I have to open an app on my Android phone, so I have to authenticate to my phone, then open the app and authenticate on it with another PIN, then I have to confirm the push notification - which sometimes will have failed to arrive. Then I have to go back to the website and click on a button there, and then wait for it to redirect back from the processor iframe or page to the original site. Also, sometimes, for whatever reason, the bank decides something is suspicious and blocks stuff and I have to phone them - sometimes that can take quite a while. Sometimes I'm abroad, and this can be a real PITA because of timezones (plus, cost of international phone calls - maybe I was buying the eSIM cause that was my Internet and phone access!).

I don't really see the major UI win for the "retail friendly" thing, the distributed Internet money micro-payments thing is actually a /lot/ easier and _far more reliable_ for me. But YMMV.

Also, because I want to have a phone that isn't a complete blob of god-knows-what crap from some big mobile company and all the companies that paid them to push their crap into said blob, and instead run a bit-more-open/far-fewer-blobs OS on my phone, this "retail friendly" app sometimes has failures after updates and I have to spend an hour on the phone to the bank to get them to clear some weird failure condition that so I can reauthenticate my phone. But that's another discussion.

Finally, the internet, distributed micro-payments thing is still very young. It is kind of normal that early technology still doesn't have optimal UI or adoption. If "it must have optimal UI and UX" is a precondition for believing anyone should use it, then... it's catch-22 (esp. if a great part of the UX hinges on adoption).

Again, perfect is the enemy of good. Despite the lack of perfection, there are many use-cases where distributed Internet money beats the "retail friendly" stuff. And in time, it can go from "good enough for these use-cases" to "good enough for more", and with enough time, maybe we see enough adoption that the regulatory friction becomes unsustainable (particularly as our generation, which is driving the regulation because of vested interests, ages out of holding the reins of power).

UI automation is necessary for accessibility

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

You are, however, by definition a "sophisticated user" taking responsibility for your own fraud and security risks.

The whole point of regulation is that unsophisticated users demonstrably don't have the knowledge and experience to take care of those risks, so we push them to the payment networks to handle. And that's why I'm focusing on the "why isn't there a retail platform suitable for unsophisticated users?" - because if you can't do that, you've not got a solution to the hard problems in payments, just to the easy ones.

UI automation is necessary for accessibility

Posted Jul 16, 2026 6:32 UTC (Thu) by raof (subscriber, #57409) [Link] (2 responses)

And, to amplify that point, the “regulatory friction” preventing this hypothetical universal payment system from becoming mainstream is the technical solution to the fraud and security risks that a mainstream system requires. I am, in fact, reasonably convinced that it is approximately the only feasible technical solution — that any solution to these problems will look a lot like the current regulatory environment, perhaps with some actors shuffled around.

I've certainly never seen a serious attempt to solve these problems which would not rapidly devolve into something looking like the current arrangement (but generally worse).

UI automation is necessary for accessibility

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

> I've certainly never seen a serious attempt to solve these problems which would not rapidly devolve into something looking like the current arrangement (but generally worse).

The growing ecosystem of digital services using various kinds of decentralised, distributed Internet money would disagree with that.

UI automation is necessary for accessibility

Posted Jul 16, 2026 10:53 UTC (Thu) by pizza (subscriber, #46) [Link]

> > I've certainly never seen a serious attempt to solve these problems which would not rapidly devolve into something looking like the current arrangement (but generally worse).

> The growing ecosystem of digital services using various kinds of decentralised, distributed Internet money would disagree with that.

"that growing ecosystem of digital services" has _never _ seriously attempted to solve those problems. Quite the opposite, in fact.

UI automation is necessary for accessibility

Posted Jul 13, 2026 12:04 UTC (Mon) by kleptog (subscriber, #1183) [Link] (25 responses)

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.

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.

UI automation is necessary for accessibility

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

There probably needs to be a daily limit. E.g. a million pages, that's more than a human can reasonably do, yet not really an issue for any real CDN/server.

I'd love for Scroll to be resurrected. There are also cryptocrap versions, but they're DoA as all cryptocrap is.

UI automation is necessary for accessibility

Posted Jul 13, 2026 22:04 UTC (Mon) by quotemstr (subscriber, #45331) [Link] (1 responses)

> There probably needs to be a daily limit.

How do you determine the principal? A daily limit *for who*?

> E.g. a million pages

A million pager per, what, person? How is individual personhood established? What prevents a scraping outfit identifying as a small town's worth of people? The whole concept of rate-limiting per-person per-day sounds easy at first but is fiendishly hard if you think about it and care about privacy.

UI automation is necessary for accessibility

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

> How do you determine the principal? A daily limit *for who*?

A subscriber. Feel free to create multiple ones, you just have to pay (for example) $10 a month for each one.

> What prevents a scraping outfit identifying as a small town's worth of people?

Nothing. And that's the goal. No Kafkaesque attestations, no complicated surveillance state. Each time you request a page, the page's operator gets credited (with obvious sanity checks).

Want to scrape my Git by following all the links recursively? Be my guest. You'll just have to pay for it.

UI automation is necessary for accessibility

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

A million requests is a lot for most servers. Certainly more than even most unreasonable individual scrapers do on most pages in a day and, depending on which rarely called (and thus uncached) pages they dig up to request, possibly more than a server can handle in total in a day.

UI automation is necessary for accessibility

Posted Jul 14, 2026 13:11 UTC (Tue) by daroc (editor, #160859) [Link] (9 responses)

Your comment made me curious about how the numbers being thrown around compare to LWN's average, sustainable traffic. So I went and poked at the logs, and found that LWN.net served 1,380,129 page requests yesterday, which was not a particularly heavy day. When there's an active scraper attack that number can be significantly higher.

Even so, only 722,949 of the requests were for actual pages that we have; 657,180 were either 404s or redirections, mostly from HTTP to HTTPS.

UI automation is necessary for accessibility

Posted Jul 14, 2026 15:31 UTC (Tue) by quotemstr (subscriber, #45331) [Link] (8 responses)

Why not get lwn on the HSTS preload list? And set up a HTTPS DNS record while you're at it?

UI automation is necessary for accessibility

Posted Jul 14, 2026 16:37 UTC (Tue) by daroc (editor, #160859) [Link] (7 responses)

Most of the traffic still requesting HTTP is from bots or other automated processes that are unlikely to respect the HSTS preload list. Note that we do serve a HSTS header with a duration of one year, so in theory any client that loads a single page from LWN.net should not try HTTP again for at least a year. In practice, we see plenty of clients that do, in fact, ignore the permanent redirects and HSTS header and continue to request the HTTP version of the site first.

As for the HTTPS DNS record — I didn't know that kind of record existed, so I've learned something new today. It probably doesn't make sense to set it up without getting our DNSSEC situation sorted out, but it's a good idea.

UI automation is necessary for accessibility

Posted Jul 14, 2026 16:47 UTC (Tue) by quotemstr (subscriber, #45331) [Link]

FWIW, given how many scrapers are headless Chromium, I'd be a bit more optimistic about the preload list.

UI automation is necessary for accessibility

Posted Jul 14, 2026 20:21 UTC (Tue) by zdzichu (subscriber, #17118) [Link] (4 responses)

Maybe disable plain HTTP? Browsers default to HTTPS connections if I'm not mistaken. Port 80 is legacy.

UI automation is necessary for accessibility

Posted Jul 14, 2026 20:43 UTC (Tue) by daroc (editor, #160859) [Link] (3 responses)

We've considered it. We only started redirecting HTTP to HTTP around ... two years ago, I think? So we wanted to give it time for people to update their bookmarks, feed readers, and so on. It might be worth taking another look at whether it's really worth continuing to listen on port 80, though.

UI automation is necessary for accessibility

Posted Jul 15, 2026 12:49 UTC (Wed) by daroc (editor, #160859) [Link]

Correction: we've redirected HTTP to HTTPS for many years, but changed how that was accomplished in our backend relatively recently, and it is that change that I was remembering.

UI automation is necessary for accessibility

Posted Jul 15, 2026 13:12 UTC (Wed) by Wol (subscriber, #4433) [Link] (1 responses)

Or just serve a page that says "waiting 10 secs to redirect to https ..."

That'll slow down any crawler that waits for previous requests to complete, and will make real humans update their links :-) without inconveniencing said humans *that* much.

Cheers,
Wol

UI automation is necessary for accessibility

Posted Jul 15, 2026 13:16 UTC (Wed) by daroc (editor, #160859) [Link]

Well, there are two problems with that:

1. Scrapers often don't complete requests on real time; they receive the redirection, and the redirected URL goes on a queue that gets processed minutes or hours later, often by a different IP address.

2. I don't think there's an elegant way to redirect after a timeout without using JavaScript (which we try to keep to a minimum) or tying up server resources with an open connection.

Honestly, clients hitting port 80 isn't a huge problem. Those redirects are relatively cheap to serve compared to serving a page with dynamic content on it. It's annoying, clutters the logs, and they should really take the hint, but it isn't the end of the world.

UI automation is necessary for accessibility

Posted Jul 15, 2026 5:25 UTC (Wed) by PhilippWendler (subscriber, #126612) [Link]

AFAIU the HTTPS DNS record is useful for telling browser to use HTTPS (and potentially HTTP2), independently of DNSSEC. It is not like TLSA or SSHFP, which contain certificates and need to be authenticated in order to make sense.

UI automation is necessary for accessibility

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

A million requests is just about 12 requests per second over the course of the day. That's just not a lot even for dynamic content. And what I meant is the total _daily_ limit for a user for all the sites.

Suppose that we have a Scroll-like service for $10 a month, so around 30 cents per day spread proportionally over visited sites. My poor Forgejo was able to serve around 250 requests per second so that 1 million requests would have been exhausted in little more than 1 hour, getting me 30 cents. During that time, my server would consume about 0.6kWh of electricity rendering all that data. So I would get a small profit given my low local prices.

Anyway, the numbers can be tweaked in either direction, with different pricing tiers.

UI automation is necessary for accessibility

Posted Jul 15, 2026 12:14 UTC (Wed) by taladar (subscriber, #68407) [Link] (3 responses)

It is extremely rare that you get the luxury of having the requests a day equally distributed across every second of the day.

PHP on a cloud server likely has a single digit or small double digit number of workers and for something not cached it can easily take a second to generate a page.

Sure, if you only count compiled languages your 250 requests/s might be realistic but the reality is that there are plenty of PHP, NodeJs, Python, Ruby or even Perl based websites that will never reach that and aren't deployed on huge servers because their normal traffic is nowhere near that high.

UI automation is necessary for accessibility

Posted Jul 15, 2026 16:51 UTC (Wed) by NYKevin (subscriber, #129325) [Link] (2 responses)

> It is extremely rare that you get the luxury of having the requests a day equally distributed across every second of the day.

Just to clarify for folks who haven't done this before: If you graph queries-per-second against time, for the vast majority of web-related services, you get a sinusoid with a period of 1 day, a fairly significant amplitude (relative to the average), and in most cases, the graph looks completely different on the weekend. You must provision for the daily peak and not the average, or else you will fall over. Load balancing, caching, and other middlebox technologies can make the graph a bit flatter (at the origin server), but it will still have a daily peak and you will still need to deal with it.

This is not only true for the origin server, but also for most if not all of its backends (and their backends recursively). You really only get flat QPS from batch jobs running continuously, and even those are often spiky in practice.

UI automation is necessary for accessibility

Posted Jul 15, 2026 16:57 UTC (Wed) by paulj (subscriber, #341) [Link] (1 responses)

> You must provision for the daily peak and not the average,

Well, for January 3rd (boxing day / St. Stephen's day sales) / FA Cup final / $INSERT_APPROPRIATE_ANNUAL_EVENT_HERE.

UI automation is necessary for accessibility

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

With most sites you can probably get away with some flakyness on the busiest day of the year (unless that is specifically what the site is designed to serve of course if it is an event related website) but you certainly won't get away with it on every daily peak.

Proof-of-Donation a compromise between Proof-of-Work and Micro-payments

Posted Jul 15, 2026 13:54 UTC (Wed) by gmatht (subscriber, #58961) [Link] (11 responses)

To serve an HTTPS page we already have to negotiate mutually trust CertAuthorities. It does not seem to be any harder to negotiate mutually trusted charities. Like Micropayments, Proof-of-Donation isn't just digging holes to fill them up again*. As to 1-3:

1. A bad-actor could transfer microcash that already been earmarked for charity to one of the wallet's owner's trusted charities, but it is not clear what this would achieve other than annoying people. A bad-actor who just wanted to be annoying could be much more annoying than that.
2. Like Proof-of-Work, you don't get your microcash/microwatts back. Just hope that "donating" a few bucks of your microcash was the worst the bad-actor did. Charities tend to be heavily regulated so it seems unlikely a "trusted charity" would be the bad actor, and they wouldn't be "trusted" for very long in any case.
3. N/A

In case people can't negotiate trusted authorities, can't be bothered setting up a microcash wallet (or it has been drained for some reason), one could still fall back on Proof-of-Work.

* It should be noted that in principle Proof-of-Work could involve asking users to solve problems that you are genuinely interested in the answer to (E.g. protein folding perhaps). However solving an interesting problem is probably too much work just to download a webpage, and might be better used as a way to bootstrap some sort of microdonation wallet rather than something you do for each random webhost you access.

Proof-of-Donation a compromise between Proof-of-Work and Micro-payments

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

The challenge is that most people don't negotiate certificate authorities; your browser author picks some for you, and you just expect HTTPS to work.

Asking people to set up a wallet is already a big deal; if that wallet's not one they're using anyway (which micropayments assume they will have), it's likely that they'll refuse. And for any "anti-scraper" measures to make a big difference, they need to become a social norm that everyone engages in, otherwise people will simply stop going to the sites that have anti-scraper measures, in favour of ones that don't.

Proof-of-Donation a compromise between Proof-of-Work and Micro-payments

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

It is not even just non-technical people who wouldn't. I know I would boycott sites like that out of principle unless they are extremely crucial (think government or health insurance services I can't avoid crucial) to my life.

Proof-of-Donation a compromise between Proof-of-Work and Micro-payments

Posted Jul 16, 2026 9:16 UTC (Thu) by gmatht (subscriber, #58961) [Link] (8 responses)

Well, there is no reason the browser couldn't pick a default set of charities either.

Manually Setting up a wallet is a pain. It might be easier to set up some sort of alt-coin mining wallet or some way of "spending" Folding@Home certificates etc (assuming they are fraud proof or can be made so, e.g. only giving certs for work than improves on an existing folding.) etc. This would seem nicer than being made to wait for several seconds of Proof-of-Work every other time I click on a webpage. (Hmm, in the meanwhile, would getting a Static IP help with that I wonder? CGNAT IP are probably treated like trash by webmins.)

Proof-of-Donation a compromise between Proof-of-Work and Micro-payments

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

How, exactly, do you expect the browser to force me to donate to a set of charities, given that there are multiple open source options where someone can remove the "forced donation" code and re-release the browser without it?

With CAs, it's trivial - the browser picks trusted CAs, and I get the benefits of trusted CAs automatically, simply because the browser chose them. In a "proof of donation" situation, however, the thing I need is not a charity, but a donation - and unless the browser makes the donation on my behalf (from what fund of money, for example, and how does it ensure that it only donates for unique users), it doesn't work.

The hard part of all of the possible solutions is getting it past the apathetic and opposed so that it becomes part of the social norms. The easy part is the technical bits of showing that you've done something (a microtransaction, proof of work, mining a cryptocurrency, whatever).

Proof-of-Donation a compromise between Proof-of-Work and Micro-payments

Posted Jul 17, 2026 8:42 UTC (Fri) by gmatht (subscriber, #58961) [Link] (6 responses)

'How, exactly, do you expect the browser to force me to donate to a set of charities, given that there are multiple open source options where someone can remove the "forced donation" code and re-release the browser without it?'

You absolutely could do that, assuming the browser even tried to force you. Then the web would fallback to work the way it does now, with many important websites regularly freezing up for a few seconds while forcing your browser to do Proof-of-Work, (or other nonsense like forcing you to do a Captcha just to view a single public facing webpage). Websites could instead deny you service entirely, but I imagine that would be rare. The webmaster might find Proof-of-Work wasteful, but if their goal is to rate-limit requests it may not make much difference to them whether they are limited by Proof-of-Donation, Proof-of-Work or Captcha.

Proof-of-Donation a compromise between Proof-of-Work and Micro-payments

Posted Jul 17, 2026 8:45 UTC (Fri) by farnz (subscriber, #17727) [Link] (5 responses)

But why would I bother doing proof of donation/work/payment if websites don't accept it yet? And why would websites move to proof of donation/work/payment if browsers don't do it yet?

There's a deep chicken-and-egg problem to solve here first, which is that when no user does the new thing, there's no incentive for websites to move away from what they do today; but when no website does the new thing, there's no incentive for users to put time and effort into a thing that does nothing for them. How do you break that cycle?

Proof-of-Donation a compromise between Proof-of-Work and Micro-payments

Posted Jul 17, 2026 9:10 UTC (Fri) by gmatht (subscriber, #58961) [Link] (4 responses)

Well, the chicken and egg problem is common to every new feature, and many browsers support versions of HTML past 1.0.

The only real challenge is how do we make setting up a wallet trivially easy (as in a user shouldn't even have to know it is there; for proof-of-donation the webmaster doesn't even need a wallet). I guess the first stage would be to just have sort of proof-of-work coin so that you could save up proof-of-work so that the next dozen or so webpages you load start instantly. I guess most coin miners would work for this, though they are a little heavyweight (and they tend to be flagged by virus scanners). Blockchain probably isn't really necessary anyway. Getting paid for proof-of-useful-work (protein folding, random useful medium size NP problems, cold-storage), or getting a couple of bucks of Proof-of-Donation coin off your ISP are possible options.

Proof-of-Donation a compromise between Proof-of-Work and Micro-payments

Posted Jul 17, 2026 9:47 UTC (Fri) by taladar (subscriber, #68407) [Link] (2 responses)

It is not common to any new feature, just to features you need to force on the user for the user to be interested in them at all.

Proof-of-Donation a compromise between Proof-of-Work and Micro-payments

Posted Jul 17, 2026 10:20 UTC (Fri) by gmatht (subscriber, #58961) [Link] (1 responses)

I don't see anyone suggesting that we force anyone to use Proof-of-Donation. Are you responding to me, or viewpoint you have seen elsewhere?

Proof-of-Donation a compromise between Proof-of-Work and Micro-payments

Posted Jul 20, 2026 7:22 UTC (Mon) by taladar (subscriber, #68407) [Link]

I am talking about the users of your particular website, you won't exactly make your users jump through hoops to adopt a system to give you a micropayment for every request unless you refuse requests without that proof attached, i.e. force your users to use it.

The chicken-and-egg problem for any solution

Posted Jul 17, 2026 10:34 UTC (Fri) by farnz (subscriber, #17727) [Link]

The chicken-and-egg is the significant problem here, though. Everything else is a solved technical problem, and you can copy pre-existing solutions to build your system.

But, as the developers of CLNP found, just because you have a technical solution to a problem doesn't mean that you can get it adopted, even with significant support. In the case of new versions of HTML, adoption happened because the browsers could unilaterally adopt new features without user involvement; once browsers had adopted the feature, websites could use it, and once websites used it, users could move to new browsers without significant cost to get the features they needed to see the latest and greatest websites.

Even then, though, the existence of sites like Can I Use points to the fact that the chicken-and-egg problem remains - some features are barely supported at all even if they'd be useful for some sites, while others are widely available and can be relied upon.

It's worth noting, in that context, that there's basically been two routes to features becoming widely available in the Can I Use tables of recent years:

Apple or Google implement it, force it on all Safari or Chrome (including Android WebView) users as a compulsory feature, and then sites start using it because there's enough users to make it worthwhile. However, at this point, I don't see that as plausible; Google and Apple are both big enough to just ride out scrapers, and therefore won't speculatively implement it.
Websites use it, with a fallback to a lesser option, and browsers implement it because their developers really like the idea of avoiding the fallback or because users clamour for the improvements they get by avoiding the fallback.