Private Access Tokens, also not great

I like Apple devices, but I don't want to have to have one

Posted by ekr on 29 Aug 2023

In my post on Chrome's Web Environment Integrity (WEI) proposal I briefly mentioned Apple's Private Access Tokens (PAT) mechanism, which, as Tim Perry observes, is already deployed. The stated use case for Private Access Tokens is to reduce the need for CAPTCHAs (the little puzzles you get asked to solve to prove that you are a human).

This is a good objective because (1) CAPTCHAs suck (I can never decide whether the post holding up the stoplight is part of the stoplight!) and (2) they increasingly don't work because captcha solving bots have gotten very good and humans aren't getting any smarter.

This is of particular relevance for Apple which is also leaning in hard to privacy technologies like iCloud Private Relay, which conceals your IP address. The problem here is that a lot of anti-abuse mechanisms rely heavily on IP address reputation. it's hard for those technologies to build up a reputation—either positive or negative—for your IP address. This is especially true if you are also browsing with settings that reduce the effectiveness of cookies, for instance if you are using Tor Browser or any regular browser in Private Browsing Mode/Incognito mode because it also prevents the site from building up reputation via the cookie. (See Matthew Prince's post on this for more background.)

One response by sites is just to show CAPTCHAs whenever they see a "new" user who doesn't have a cookie or with an IP address that doesn't have a reputation—or has a bad reputation— or is used by an anonymity service. This is obviously annoying to users and not really what sites want either, because they want people to visit their site, not bounce off the CAPTCHA. What you really want is some way to attach a positive reputation to someone without tracking them.

Privacy Pass #

When you look at the problem this way, the broad shape of a solution presents itself, at least if you're a cryptographer: you need anonymous tokens. The basic idea here is that you solve a CAPTCHA and in return get an anonymous token which lets you prove that you solved it so you can skip the CAPTCHA next time. This is what is specified in the IETF's Privacy Pass protocol. In Privacy Pass, tokens are issued by working with a pair of entities called the "Attester" and the "Issuer", and are consumed by the "Origin" (the Web server) as shown below:^[1]

[Source: Privacy Pass Draft]

In this scenario, the Attester is responsible for ensuring you solved the CAPTCHA—or enforcing whatever other properties one might be interested in, as we'll see shortly—and then conveys some kind of attestation to the the issuer that it has done so.^[2] The issuer then issues an anonymous token (see here for an overview of how this works) to the client. The client can then use the token to prove to the Origin (the actual site) that it is approved. It can also be used for other forms of anonymous authentication, for instance iCloud Private Relay uses a similar technique to allow users to anonymously prove that they are customers.

Obviously, I'm oversimplifying here and a huge amount of work has gone into trying to make Privacy Pass have the right security and privacy properties. There are also still some pieces which need work,^[3] but for the purpose of this post we can ignore the details and assume that it functions as advertised.

Private Access Tokens #

The important thing to realize here is that Privacy Pass is a generic technology which just transports the fact that you satisfied the attester. The important operational question, however, is what you had to do to satisfy the attester. The original design of Privacy Pass was built around the idea that what you did was solve a CAPTCHA, but Privacy Pass is agnostic on this point, and in principle the attester can demand anything. This brings us to Private Access Tokens, Apple's implementation of Privacy Pass using Apple as the attester, as shown below:

[Source: Apple]

Based on the description in the video, Apple is checking for the following properties:

• This is a valid piece of [Apple] hardware

• The user's iCloud account is in good standing (i.e., you have to be signed in with an Apple ID).

• [Optional] performs rate limiting to limit the use in bot farms

If these checks pass then you will be able to get a token from the issuer.

As I understand the situation, this will just work if you are on Safari but doesn't work on other browsers such as Chrome and Firefox, at least on desktop. This is partly because Apple doesn't seem to provide generic APIs that allow you to to use Private Access Tokens but instead only makes them available via their own networking APIs (WebKit and URLSession). This means every browser on iOS because Apple requires you to use their browser engine on iOS. However, on desktop Firefox and Chrome use their own networking stacks, so this doesn't work for them, really,^[4] though I suppose Apple could provide APIs that those browsers could use. Of course, those browsers could also negotiate their own deal with attesters.

Policy: Browsers, Issuers, Attesters, and Origins #

This is a complicated system with four separate players and that makes it hard to sort out the various policies in play:

• The Origin server (i.e, the Web site) gets to decide which Issuers they accept.

• The Issuer gets to decide what Attesters it trusts and which policies it expects them to enforce.

• The Attester gets to decide what policies they actually enforce.

• The Browser gets to determine which Attesters and Issuers they are actually willing to work with.

The result is that what policies you are actually subject to is determined by the interaction of the preferences of all of these parties, with the Browser and the Origin being the most important, because the Origins know what they are demanding and the Browser knows which Issuers and Attesters they will work with. The Origins can always find new Issuers/Attesters, and the Browsers can always blocklist them.

In the actual existing Apple system, the Attester and Browser Apple and Apple's policy is that you need to have an Apple device and an iCloud account. The current issuers they have announced are Cloudflare and Fastly. Moreover, Cloudflare and Fastly can also act as the origin servers (web sites) in this case, which means that if you use them to serve your Web site they can automatically consume PAT. Because of the way the crypto is designed, it's fine to have the Issuer and the Origin be the same, as they cannot link the client's behavior; in fact the Issuer, Attester, and Origin can all be the same.

The General Equilibrium #

From a technical perspective, this is all pretty reasonable stuff, but the thing to understand is that this is a generic system which is compatible with any policy the Attesters and Issuers want to enforce. As we saw with WEI, the question is then what policies they will choose to enforce. The policy enforced by the combination of Apple's attesters and the issuers they have chosen is that you paid Apple for a device and have an iCloud account. This is very different from "the person solved a CAPTCHA" because that policy works just as well for people who don't have Apple devices.

This is actually a pretty reasonable proxy for "is a person and not a bot", but the bigger picture consequences aren't great, as I don't really want to live in a world where everyone who hasn't bought an Apple device has to solve CAPTCHAs all the time. Of course, most people don't use Apple devices and many of those still use Chrome or Firefox, so that limits how aggressive sites can be about requiring repeated CAPTCHA solving for people who don't have those devices. But what happens if similar functionality gets added to Android^[5] and Windows and now suddenly the vast majority of devices have some kind of PAT-like functionality? In that case, sites will be able to be much more aggressive about requiring CAPTCHAs or just refuse to serve other users at all, as they will only be annoying a fairly small fraction of their users.

Of course, the situation will become even worse as AI gets better at solving CAPTCHAs. The basic problem here is that we don't really have a good, cheap, signal for "is a human" that doesn't require somehow buying into some bigco ecosystem, whether it's buying a device from a given manufacturer, having an account with some big service, or both. But the consequence of that is risking making using the Internet a lot harder for people who don't want to do one of those things.

Stepping back, I worry about the equilibrium steady state: the more that people are able to authenticate these technologies the more attractive it is for sites to basically require them, to increase the level of scrutiny (as in WEI), and provide a massively inferior experience to those who can't. Ironically, this is actually a direct consequence of Privacy Pass being well-designed so that it's seamless and provides a good level of privacy, because that makes it seem less objectionable to require, as opposed to (say) making everyone log in with a Google account.^[6] At the end of the day, though, the risk is further entrenching the existing big players.