Remember back to EME, an Open standard doesn't necessarily mean Open implementation.

The actual workflow here is an open standard, but I'm having a hard time understanding why sites won't just require that you use Mediators/Issuers that were written by one of the big tech companies and then block everything else.

Not saying that will absolutely be the case, I'm just saying that I don't understand why I shouldn't be concerned -- I've seen these exact arguments get used in the past for systems that absolutely shut out independent browser/hardware/OS/ROM development.

I mean... CAPTCHA is effectively an Open Standard, even if it doesn't have a draft that I'm aware of. But that doesn't mean much when so much of how it works is rolled up in an unstandardized implementation and when website operators are ultimately in charge of choosing CAPTCHA providers, not users. Is the same thing going to happen with PATs?

Apple attests that some iOS device is being operated by a real human. They accomplish this attestation through device heuristics; I believe the plan is, to run these heuristics on-device, then communicate them to Apple for signing/validation/whatever. Or, maybe it all happens on device, its not really relevant.

Its not relevant because: Apple devices only run "trusted" code. Cloudflare then says "hey, any PAT which originates from Apple is probably generated by trusted code, we know what heuristics we use, we trust those heuristics, lets approve it."

But extend the same theory to more open devices. There are two outcomes:

(1) Services trust the PAT itself. This would be pointless from a bot-mitigation angle, because anyone could just mint and submit a PAT. But, it would be "open".

(2) Services trust the PAT issuer. Implicitly, this means, they trust all the code which the issuer uses to generate the PAT, probably using device heuristics of some kind.

The second outcome is far more likely. Conways Law: these systems were built by teams with one goal: to stop bots. (1) wouldn't actually stop bots. Similar to SSL certs: We don't just trust any valid SSL cert; we only trust ones that are issued by known trustworthy third parties.

But there's no way to trust code running on open systems. They can't trust the heuristics, because they could be faked. Even if a solution evolved which looked like "the linux kernel has this built in" or "canonical distributes a known good binary which contains good heuristics algorithms", it doesn't matter, because there's no way to cryptographically validate it. We can modify the code, run whatever, and suddenly that Issuer (Linux, Canonical, whoever) can't be trusted. Only issuers which operate their heuristics in locked-down environments can be trusted.

Also similar to SSL certs: they'll say "we'll always have captchas as a fallback"; "you don't need HTTPS, HTTP is always there". It's bullshit scrying from people who can't think more than one quarter ahead. In the case of SSL, its reasonable bullshit, there's strong arguments for it, it made deploying websites slightly harder but not insurmountably. PAT is another step beyond that, and I don't see a situation where this technology is both Useful and Open. I really hope we decide to sacrifice its usefulness; but the Powers That Be probably won't.

You appear to be writing that it would be a good thing if browsing most of the web was not possible from Linux. If that's not what you meant, please clarify.

If it is what you meant, I don't quite know how to respond except that I disagree vehemently.

It's a good thing only if you are Apple, Google or Microsoft, or a shareholder of them.

You'll note that no-one from Mozilla has their name attached to that RFC draft.

So I can just write a linux kernel module to assert I'm a Real Person™ and all will be fine?