Apple’s iOS 16 will give you an alternative to irritating CAPTCHA tests

iPhone and Mac owners could soon bid farewell to online CAPTCHA challenges that aim to test whether you’re a human. 

Instead, they’ll get ‘Private Access Tokens’. 

It looks like Apple will be the first to roll out the new technology, which is included in the first betas of iOS 16 and iPadOS 16, as enabled by default according to Mac Rumors. Apple detailed the technology at WWDC 2022 earlier this month along with Cloudflare. 

SEE: Every iOS 16 feature that’s coming to iPhones

Private Access Tokens (PATs) are coming to iOS 16 and macOS Ventura with the promise of reducing the need for CAPTCHAs: iOS 16 is currently in beta and will release later this year.

Google and many other companies uses CAPTCHAs, or the “Completely Automated Public Turing test to tell Computers and Humans Apart”, as a challenge-response authentication to prevent bots from signing up to new accounts or accessing services. 

It’s a useful service for helping to stop fake access requests, but spotting an object in grainy images can still be frustrating and inconvenient when signing up to a service.  

As Apple highlighted at WWDC, CAPTCHAs can also pose a privacy risk. To reduce the complexity of CAPTCHA challenges, web servers often use tracking or browser/device fingerprinting. It’s also an obstacle for accessibility and unnecessary when a person has already unlocked a device with a password or Face ID.    

Cloudflare, which has abandoned CAPTCHA already, estimates that “500 human years [are] wasted every single day – just for us to prove our humanity.”

Fortunately, Private Access Tokens (PATs) are not exclusive to Apple hardware. Apple and Google are shaping the authentication standard through the IETF Privacy Pass working group, which suggests it will come to Android at some point. But, PATs also require cooperation from hardware makers and Google hasn’t announced its plans for PAT in Android. The working group also includes members from Cloudflare and Fastly. 

“By partnering with third parties like device manufacturers, who already have the data that would help us validate a device, we are able to abstract portions of the validation process, and confirm data without actually collecting, touching, or storing that data ourselves. Rather than interrogating a device directly, we ask the device vendor to do it for us,” Cloudflare explains of PATs. 

On Apple’s side, PATs can help privacy measures for its Safari browser, Mail Privacy Protection and iCloud Private Relay. 

The PAT protocol allows developers to request tokens from user devices by using a cryptographically-signed authentication method called ‘PrivateToken’. A web server can only use a token to check their validity but can’t be used to discover the identities of the user or recognize a client device as its used to browse different websites, according to Apple. The service allows sites to verify a device and Apple ID account without you having to find every stop sign on a grid of grainy photos, for example.

“First, when the iOS or macOS client accesses a server over HTTP, the server sends back a challenge using the PrivateToken authentication scheme. This specifies a token issuer that is trusted by the server,” Apple explains.  

“When the client needs to fetch a token, it contacts an iCloud attester and sends a token request. This token request is “blinded” so it can’t be linked to the server challenge. The attester performs device attestation, using certificates stored in the device’s Secure Enclave, and verifies that the account is in good standing.”

SEE: Don’t let your cloud cybersecurity choices leave the door open for hackers

The iCloud attester also rate-limits requests to prevent bots, and once a client device has been validated, it sends a request for a new token to the issuer. 

“When the token issuer gets the request, it doesn’t know anything about the client. But since it trusts the iCloud attester, it signs the token,” Apple explains. 

“The client then receives the signed token, and transforms it in a process called “unblinding” so the original server can verify it. And finally, the client presents the signed token to the server. The server can check that this token is signed by the Issuer, but it cannot use the token to identify or recognize the client.”