This document explains what Private Access Tokens (PATs) are and how Google Cloud Fraud Defense uses them.
What are Private Access Tokens?
Fraud Defense uses a feature on iOS and macOS called PAT to reduce the number of CAPTCHAs that it shows to human users.
A PAT is an opaque token that some iOS and macOS devices
generate. The token serves as a privacy-preserving attestation of a device's
authenticity and integrity. PATs are an implementation of the Privacy Pass
protocol, which is a type of
WWW-Authenticate
scheme.
How Fraud Defense uses Private Access Tokens
Fraud Defense uses multiple factors to determine if a request comes from a human or a bot. The ability of a device to produce a PAT is one of these signals. Devices that can't produce a PAT aren't penalized.
The PAT protocol is designed to help preserve privacy. The token doesn't contain personally identifiable information that can be used to identify a specific device or user. Fraud Defense checks that the token is valid to confirm that the request comes from a genuine Apple device.
The Private Access Token request flow
You might see the 401 error https://www.google.com/recaptcha/api2/pat
or https://www.recaptcha.net/recaptcha/api2/pat. This error is an expected
part of the PAT protocol. To determine if a device can produce a PAT, Fraud Defense sends a special header in a response that rejects the initial request. On compatible Apple devices, this header triggers a flow that retries the request with a PAT.
This 401 error doesn't prevent Fraud Defense from working on the
page or cause other errors. When you click the checkbox or call execute,
the reCAPTCHA Enterprise API still generates a valid token.
What's next
To learn more about how Apple uses Private Access Tokens, see the post Featuring Private Access Tokens on the Apple Developer blog.