How to enable Private Access Tokens in iOS 16 and stop seeing CAPTCHAs | Hacker News Reader

How to enable Private Access Tokens in iOS 16 and stop seeing CAPTCHAs

blog.cloudflare.com

I suspect this will just lead to crowdsourcing PATs or whatever mechanism is used to issue these things, just like it happens with proxies. In the beginning, God created IPs and the Earth. Then people figured that IPs could be "borrowed". Trust in IPs went down this really absurd path of people being pissed when they get blocked, subnet blocks, residential proxies and etc.

Can Private Access Tokens be used to track a user/device?

If not, what stops someone from setting up a system which generates lots of PAT’s from a small number of devices and sending those as fake PAT’s from other devices?

If it’s private, it shouldn’t allow anyone to associate my PAT with my device. If it’s private, how does the server know a PAT was generated by the device that is sending it?

It seems like you shouldn't be able to use a PAT from another device (thus creating a PAT fountain), as attestations are used, which chain back to a trusted issuer (device maker). This should be possible to do, through a simple thought experiment -

In essence, the PAT doesn't need to be tied to your device identifiably, but it could be considered as a certificate saying "I, the device maker, know that the holder of this public key is a real device". If the private key corresponding to that public key is held in a trustzone or other similar keystore, it can be used to sign an attestation containing a challenge/response, without revealing the private key.

If you can't liberate the private key, you can't reuse the PAT, as you can't include the challenge in your signature.

Presumably devices can generate (and get attested) multiple PATs and cycle through them, removing old ones.

Blind RSA signatures could also be used to do this, so that the device maker signing the attestation doesn't know what public key is being signed, just that it's a valid one generated on a protected key store.

The standard seems to confirm this [1]:

"Privacy Pass tokens are unlinkable authenticators that can be used to anonymously authorize a client. A client possessing such a token is able to prove that it was able to get a token issued by a token issuer -- based on some check from a token issuer, such as authentication or solving a CAPTCHA -- without allowing the relying party redeeming the client's token (the origin) to link it with issuance flow"

[0] https://blog.cloudflare.com/eliminating-captchas-on-iphones-...

[1] https://www.ietf.org/archive/id/draft-ietf-privacypass-auth-...

What confuses me is that at the end of the day the challenge and response need to be sent over HTTP.

Why can’t you copy the response from the real device and “play” (not replay) it from a fake device?

I believe you could do relaying like this, if suitably determined. You would need to do it in near real-time, and no doubt the endpoint giving PATs will be rate-limited.

At some point the amount of manual effort to automate this (do you have an API to retrieve the token programmatically from another app?) will exceed what it is worth to avoid a captcha!

I suspect you will find it is hard to gwt the real response out from the trusted browser.

What exactly is preventing bots from emulating this?

Reply on news.ycombinator.com