Authenticating telemetry without the identity

WhatsApp has completed a global rollout of a new telemetry collection method — De-identified Telemetry (DIT), formerly known as PrivateStats — designed to gather usage, reliability, and performance data without tying that data to a specific person or phone number. The system, currently in testing, is built on a proprietary Anonymous Credential System (ACS) that authenticates data submissions without the server learning where the data originated.

The motivation is straightforward: operating a network handling over 100 billion messages and 1 billion calls per day requires visibility into service health — message delivery rates, operating system distributions, app versions. Historically, WhatsApp has relied on data deletion and secure storage to prevent usage information from being linked back to individuals. DIT aims to go further by making the link between identity and telemetry data nonexistent at collection time.

The two-step logging workflow

DIT splits logging into two phases to achieve authenticated yet de-identified collection. A client first obtains anonymous credentials over an authenticated connection; later, it submits logs over an unauthenticated connection, presenting the credential as proof of legitimacy.

The token acquisition works as follows:

  1. The WhatsApp client requests a batch of tokens from servers using a Verifiable Oblivious Pseudorandom Functions (VOPRF) scheme. Each token is the VOPRF evaluation of a random string the client chooses as input.
  2. The client sends a network request carrying a token.
  3. The authentication server verifies the request's legitimacy, and the ACS — which manages keys for multiple applications — evaluates the VOPRF using its secret key.
  4. The resulting credential is returned to the client via the application server.

When the client later logs telemetry:

  1. The client attaches the original token input to the logging request and binds the request using an HMAC over the data, with the key derived from the token.
  2. The application server forwards the request to the ACS, which validates the token, enforces its usage limit, derives the HMAC secret, and returns it to the application server.
  3. The application server verifies the log's integrity and decides whether to accept it.
De-identified Telemetry (DIT) logging workflow
The logging workflow of the De-Identified Telemetry (DIT) system

The pseudo-randomness of the VOPRF evaluation ensures tokens cannot be linked across the two steps, decoupling identity from log data. Verifiability lets clients confirm they are using valid keys rather than maliciously crafted ones. The design draws on the Privacy Pass protocol and blind signatures — while Privacy Pass uses VOPRFs to prevent third-party browser abuse, WhatsApp has adapted the construction for first-party data minimization.

Deployment considerations at scale

Testing DIT at production scale surfaced several engineering tradeoffs.

Curve selection

After comparing RSA and elliptic curve (EC)-based VOPRF algorithms, WhatsApp chose an EC-based approach similar to Privacy Pass, largely due to its path toward standardization. The initial plan was to use Ristretto for EC-VOPRF instantiation, but the team switched to Curve25519 — already bundled in the app for end-to-end encryption — to respect WhatsApp's stringent app size requirements. To mitigate potential static Diffie-Hellman attacks against Curve25519, additional protections such as more frequent key rotations were added.

Pseudonymity and token reuse

DIT includes a pseudonymous identifier for each client, rotated periodically and sent with log payloads. This allows aggregation — such as crash counts — without identifying affected individuals, while letting clients control their own pseudonymity. Tokens are also reusable a limited number of times before being invalidated: currently 64 times per day, which lets most clients operate a full day without fetching a new token. Token reuse does not affect the keys that protect end-to-end encryption.

Re-identification risk

WhatsApp actively measures the re-identification and joinability potential of collected data, raising an alert if the potential exceeds a set threshold and halting telemetry collection for data with high re-identification risk. Additional mitigations include stripping IP addresses from anonymous requests at edge servers, so the logging server never sees them. These measures remain under evaluation as DIT testing continues.

Rate limiting without identities

Since anonymous token redemption cannot be rate limited per person, key rotation serves that role — limiting how many tokens a single client can request per public key and expiring tokens when the key is rotated. For redemption, the logging server also tracks how often a unique credential has been used and rejects requests beyond the threshold.

Communication overhead

DIT's workflow introduces extra round trips compared to WhatsApp's existing procedures: fetching credentials before logging and communicating with the ACS mid-request. Token reuse reduces these trips, and ACS servers are deployed locally relative to WhatsApp application servers to reduce cross-region latency.

Next steps

DIT is currently in testing across the global WhatsApp client base. Additional privacy-preserving techniques — including local and global differential privacy — could further strengthen the system's guarantees, whether applied at collection time or afterward. The path from testing to fully relying on DIT without existing redundancies remains long, and refinements are expected as testing continues.

The engineering team has published a detailed whitepaper documenting the current form of DIT and the ACS, with the intention that the underlying techniques could be applied to products beyond messaging.