Private Access Tokens

[martinthomson]

Request for Mozilla Position on an Emerging Web Specification

• Specification title: Private Access Tokens
• Specification or proposal URL (if available): https://datatracker.ietf.org/doc/html/draft-ietf-privacypass-auth-scheme
• Explainer URL (if available): https://developer.apple.com/news/?id=huqjyh7k
• Proposal author(s) (@-mention GitHub accounts): @tfpauly
• Mozillians who can provide input (optional): @martinthomson @bvandersloot-mozilla

Other information

I'm opening this issue so that we can track this feature here and record a public position on it. This is an important change to the Web platform that hasn't really received a whole lot of scrutiny and we're looking to rectify that.

[martinthomson]

Apple deployed the Privacy Pass protocols on the Web under the name “Private Access Tokens”, but this is largely a proprietary deployment of IETF protocols. We see several serious flaws in this deployment that mean that we have to take a “negative” position:

• Apple deployed based on incomplete specifications in IETF documents rather than develop a proper Web integration. The privacy properties of this deployment are essentially undocumented and not the product of a consensus process.

• The current deployment by Apple only includes a single attester, which is operated by Apple and tied to hardware-backed attestations in Apple hardware. This has serious privacy implications, as the ability to produce a token can be taken to mean something very specific.

• We are also very concerned that this might result in serious problems for equitable access to content and services if sites come to rely on the presence of this signal. If sites provide a worse experience — such as showing CAPTCHAs — if users are unable to produce a token, then we see that as adverse discrimination. See our position on WEI (link) for more on this point.

• The proposal currently insists that issuers register with Apple to use their attester. This process is likely necessary (see below) but it creates significant pressure to be large, which biases against new or smaller sites that might like to offer the service.

• There is also no means of engaging with alternative attesters or attestation methods.

In order for us to be confident that use of Privacy Pass on the Web does not adversely affect user privacy, a lot of trust is placed in attesters and issuers. For this to be practical, we would need controls on the actions of issuers (and transitively, attesters):

• Strong mechanisms for key consistency (link) so that the choice of key cannot be used to degrade privacy.

• Agreements about what the existence of a token can mean. For example, Apple’s intent seems to be to signal that a client is not abusive, which seems like it could be acceptable.

• A diversity of methods for determining this meaning so that offering a token does not also imply that a particular method was followed. That is, the token cannot mean that someone has Apple hardware.

• Some amount of inherent or client-enforced unreliability. This is to ensure that sites cannot become dependent on the presence of tokens, so that they might exclude users who cannot or will not produce a token.

• An open process for issuers (and attesters) to be able to participate, so that we do not encourage centralization. This should be a single system for all browsers, for similar reasons.

We recognize that there is an intent to do better here, but we see serious challenges without adequate mitigations. Some of these items are readily addressed or are actively being worked on, which is encouraging. However, we remain skeptical that it is possible to develop a comprehensive system of controls with the right incentives for all participants.

We understand that Apple intends to improve their deployment along the lines we describe, but we have to judge based on what is documented, implemented, and deployed. Our recent analysis goes into this in more depth.