I helped engineer the systems behind Apple Private Access Tokens in advance of its announcement at Apple WWDC 2022. I also authored a relatively popular explainer on the subject, led integration of their use in production anti-fraud systems, and given various related talks.

Along the way I worked extensively with the related open standard, IETF PrivacyPass, and worked with Google’s version of the tech: Private State Tokens.

It’s been a while since I looked at the public ecosystem around these technologies, so I spent some time over the 2024 US winter holiday catching up on them.

These are my summary notes from that effort.

Warning: this is a very technical post, and may not be suitable for all audiences :).

image PAT iOS configuraton screen

Enabled by default

Apple Private Access Tokens (PATs): What are they?

Apple PATs provide privacy-hardened attestation of web clients to web servers. Principally, Apple supplies attestation that a given Apple client is not a bot. PATs use cryptographic techniques and separation of duties to provide some anonymity to clients. 

PATs supplement removal of mechanisms used to track users from the Apple ecosystem. Notably, disabling third-party cookies by default in Safari and deployment of Apple Private Relay (which hides client IP addresses from web sites). 

Google Private State Tokens (PSTs): differences and context

Google PSTs are available in supported versions of the Google Chrome browser. PSTs also provide privacy-hardened attestation of web clients to web servers. 

Google PSTs are distinct from Apple PATs.

Similarities:

  • Both PATs and PSTs aim to replace some use of third-party (third-party) cookies to track privacy-sensitive cross-domain attestations about web clients. For example, siteA.com signaling to siteB.com that a given client is not a bot.

  • PATs and PSTs both implement versions of the open IETF Privacy Pass API.

  • Both PATs and PSTs are enabled by default

    • PATs are automatically enabled for supported Apple OS versions and users (opt-out via OS user settings)

    • TODO: chrome://flags for PSTs?

Differences:

  • (Importantly) Apple supplies an attestation that a respective client is not a bot via PATs.

  • (Importantly) Google does not provide any attestations about clients via PSTs. Vendors must supply attestations.

  • PATs are integrated with the OS and apps. The PAT protocol is handled automatically in WebKit (Safari) and NSURLSession (apps) on supported MacOS and iOS.

  • PSTs are integrated with browsers (Chrome) only via an API. Android app usage would notionally be DIY.

  • PSTs provide slightly weaker client privacy guarantees than PSTs. 

  • Tokens from a given PAT issuer represents one bit of information. Tokens from a given PST Issuer can represent up to 6 bits of information.

  • Google PST issuer deployment is lower-friction. Apple PAT token issuer deployment requires approval from Apple and significant coordination with their engineering team. PST token issuer deployment requires approval from Google and can be deployed without significant engineering coordination.

  • The list of PAT token issuers is private; the list of Google PST issuers is public here.

PSTs were implemented as part of Google’s “Privacy Sandbox” and strategic third-party (third-party) cookie deprecation initiatives. The broader third-party cookie deprecation faced opposition from EU regulators and was halted in 2024 (EU IAB, Wired).

Privacy Pass logo

IETF Privacy Pass developments

Apple PATs and Google PSTs both implement distinct versions of the IETF Privacy Pass API (https://datatracker.ietf.org/doc/rfc9576/). Right now each Apple PAT token issuer can represent one bit of information (ex: token from issuer with domain “not-a-bot.token.vendor.com” means client is not a bot; absence implies it might be a bot). Google PSTs allow issued tokens to represent additional information (up to 6 bits). An update to Privacy Pass that allows for this is in development (IETF draft).

A distinct update to PATs (by Apple) that allows for encoding rates (for rate limiting and paywalls) has expired (expired IETF draft, retiring github commit).

Thoughts on the current state of the PrivacyPass ecosystem

Here are some editorial analysis thoughts based on the current state of the technology and ecosystem.

PATs

  1. The Apple attestation encoded in PATs is valuable. To bot/fraud management vendors and organizations implementing bot/fraud management on their own.

  2. Since third-party cookies are disabled by default, PATs are useful to convey information across sites in the Apple ecosystem

  3. PATs may also be useful for conveying information between sites and Apple apps

  4. Work on Rate Limiting via PATs seems to have stopped

PSTs

  1. Given Google’s third-party cookie deprecation has stalled, vendors may use third-party cookies instead of PSTs in Chrome indefinitely.

  2. Google seems to be continuing work on the ecosystem. Notably, they are standardizing conveying more data via tokens.

Conclusion

Given Apple’s ongoing investment and application of privacy-enhancing technology to meet their strategic business goals, PATs (and related technology) will likely continue to progress. Albeit within relatively opaque business processes. Given that Google’s corresponding strategic application has faltered, progress on PSTs may not be as quick.

That was a very technical post. To be honest I’m not sure if anyone will read it. But, I thought I would publish in case it might be helpful to someone out there. Thanks for reading!