Moving de-identification upstream with anonymous credentials

Meta’s data minimization strategy has historically been reactive: collect data, then de-identify or aggregate it through post-processing. At Meta’s scale, that approach becomes expensive and resource-intensive. The Anonymous Credential Service (ACS) flips the model—de-identifying information at the point of authentication, before data ever reaches a server.

ACS is a highly available, multitenant service built on anonymous credentials, a privacy-enhancing technology developed collaboratively across industry and academia. It lets clients authenticate without revealing a user ID, protecting against scraping, spam, and DDoS while keeping the identity of the requester hidden. ACS is already serving several high-volume production use cases at Meta.

de-identified authentication

Splitting authentication into two untraceable phases

Anonymous credentials enable de-identified authentication by separating the process into token issuance and token redemption:

  1. Token issuance: The client contacts the server over an authenticated channel, sends a token, and receives it back signed.
  2. De-identified authentication (redemption): The client submits data over an anonymous channel, authenticating with a mutated form of the signed token rather than a user ID.

The signed token from the issuance phase and the redeemed token in the authentication phase cannot be linked. This unlinkability lets the server authenticate a client in the second phase without knowing which specific client the token belongs to.

Under the hood: VOPRFs and blind signatures

The protocol builds on two cryptographic primitives: VOPRFs (verifiable oblivious pseudorandom functions) and blind signatures. VOPRFs let clients learn verifiable pseudorandom function evaluations on custom inputs; blind signatures prevent the signer from seeing the message contents.

Beyond the two operational phases, there is a setup phase where the client obtains the server’s public key and other public parameters. In issuance, the client:

  • Creates a random token and a blinding factor.
  • Blinds the token and sends it to the server.
  • Receives the signed blinded token and unblinds it.
  • Computes a shared_secret—a function of the original token and the server signature.

At no point does the server see the original token value. In the redemption phase, the client sends the original token, the business data, and an HMAC of that data keyed with the shared_secret. The server verifies that this HMAC matches one computed locally from the token and its own signature. If it passes, the request is accepted. Full protocol details are in the paper “De-identified authenticated telemetry at scale.”

Production use cases

De-identified Telemetry on WhatsApp

WhatsApp’s De-identified Telemetry (DIT) is the first large-scale ACS deployment. Previously, WhatsApp relied on secure storage and data deletion policies to keep log data unassociated with users. With ACS integrated into its systems, certain client-side logs authenticate without collecting identity—WhatsApp can report performance metrics that keep the app crash-free and responsive while eliminating user ID from the authentication path. This deployment requires ACS to handle hundreds of thousands of requests per second across the WhatsApp family.

de-identified authentication

Federated learning

ACS also has a role to play in federated learning, where a global ML model is trained while sensitive data stays on-device. Devices share model updates rather than raw data; servers aggregate updates and optimize the global model. ACS fits here by blocking fraudulent model updates from malicious actors while letting legitimate clients submit their updates de-identified.

Architecture and multitenancy

ACS is a C++ service running on Twine, Meta’s container orchestration framework. Traffic is load-balanced across global regions, with each region scaling dynamically with demand. The service exposes Thrift APIs for token issuance and redemption.

Because ACS is multitenant and serves use cases with different authentication mechanisms (e.g., Facebook vs. Instagram users), token scope isolation is critical. A token issued for one use case must not be redeemable for another. Each API request therefore specifies a use case name, and separation is enforced with use case–specific key material. Security keys are rotated routinely via Meta’s asynchronous job infrastructure, with keys stored in Meta’s keychain service. A separate job publishes updated ACS public keys after rotation so clients can fetch them.

Three scaling lessons

Scaling ACS surfaced three reliability challenges: linear cost growth, artificial traffic spikes, and onboarding friction.

Avoiding 1:1 capacity growth

Every new use case initially meant new hosts and server capacity in lockstep with onboarded traffic—unsustainable during a global supply chain crunch. The fix was permitting use cases to configure a credential reuse limit within a reasonable threshold. A credential reuse counter, backed by ZippyDB, tracks how many times a token has been redeemed and rejects over-redemption. Sensitive use cases can set a redeem limit of one; others can reuse tokens and reduce the number of tokens issued to serve the same traffic.

Dithering against self-inflicted DDoS

Traffic dashboards revealed short, overwhelming spikes from one large use case. The client teams had cached data on mobile and sent batched requests at the same time each night—effectively DDoSing the server. The fix had two parts: dithering for that particular client to spread requests over time, and a global rate limiter integrated with Meta traffic teams to selectively drop ACS traffic above a configurable threshold.

Self-service onboarding

Initially, a small ACS team manually onboarded every new use case, requiring deep protocol knowledge and close collaboration. That changed with three investments:

  • A self-service onboarding portal built in React, serving as a one-stop shop for ACS across Meta.
  • Client SDKs for Android and iOS providing crypto primitives and protocol implementations. High-level methods like fetch-acs-token handle the entire exchange—contacting ACS APIs, unblinding tokens, and any other operations—so clients write minimal code.
  • Rewamped onboarding documentation and codegen tooling, removing the need for expert-level cryptography knowledge.

De-identification is a core safeguard for user data, and ACS shifts it upstream—from post-processing into the authentication layer itself. Meta plans to extend ACS further into its data infrastructure and beyond authentication use cases.