The last example is a false narrative, that captchas will only happen if the "browser looks suspicious". Systems like Altcha put an end to this argument. They don't care if the browser looks suspicious, only that the browser can perform a proof-of-work to get past a captcha designed to slow down the request rate.

When applied consistently, it will effectively block and slow down AI crawlers, which is what this company wants to promote.

The solution is really a ton of different captcha like systems and anti spam solutions, all unpopular enough that an attacker may not even bother targeting them. If an attacker needs to target a few thousand different captcha style setups to get their spam through, then many of them won't bother.

It's like centralised vs decentralised communication systems. If everything is centralised, a bad actor (like a government, corporation, criminal group, etc) can go after one target to control the narrative. If it's decentralised, then suddenly they have to go after dozens or hundreds of different targets, many of which won't cooperate with them.

The game is shifting to a better ideal: how do you design a service knowing that any user/request might be automated?

Especially in place of the historical, easy solution/hack where you have some sort of gate that, once passed, puts the user in some trusted low-scrutiny tier, like a forum's registration page.

It's a similar question to designing a system so that it's resilient to account take-overs. (i.e. The user was a trusted human until now, and now it's a spammer)

Example: on a forum, run new posts through an LLM to classify it as spam which is a magic solution we always wish we had (remember akismet?) but was too rudimentary.

[1] https://www.browserbase.com/blog/cloudflare-browserbase-pion...

I haven't looked deeply into Web Bot Auth, but is identification tied to the agent (one identity per agent) or is it tied to the underlying person using the agent (the user)?

Hope that question makes sense, lmk if you need clarification