Skip to content

SYSTEM Cited by 1 source

WhatsApp Private Processing

Private Processing is Meta's confidential-computing infrastructure that lets WhatsApp users invoke AI features (initially message summarisation + writing suggestions) over end-to-end-encrypted conversations without Meta, WhatsApp, or any third-party intermediary seeing the plaintext. Announced 2025-04-30, with launch projected "in the coming weeks" from that date.

Architecture (six-phase session flow)

Private Processing's wire architecture chains four independent primitives so that breaking any single one still fails closed:

  1. Authentication — the device obtains anonymous credentials via Meta's Anonymous Credential Service (ACS) that prove the caller is an authentic WhatsApp client without identifying the user.
  2. Third-party routing + load balancing — the device fetches HPKE public keys from a "third-party CDN" to enable Oblivious HTTP (OHTTP).
  3. Wire session — device establishes an OHTTP connection to a Meta gateway via a third-party relay. The relay sees the client IP but not the inner request; the gateway sees the inner request but not the client IP — this is the core non-targetability primitive.
  4. Application session (RA-TLS) — device and the target CVM establish a Remote Attestation + TLS session. The TEE attestation is cross-checked against a third-party ledger of acceptable CVM binary digests before the client releases its session key (patterns/attestation-before-session-key-release).
  5. Request — the device encrypts its payload (e.g. the messages to summarise) end-to-end between device and Private Processing with an ephemeral key only the device and the pre-selected CVM hold. Neither Meta, WhatsApp, nor the relay/CDN can decrypt.
  6. Response — processed output is returned under the same ephemeral key. After the session completes, Private Processing "does not retain access to messages"; CVMs do not persist to disk or external storage.

CVM-to-CVM calls (when one CVM must call another to complete the work) ride the same RA-TLS primitive that clients use.

Foundational requirements (five stacked)

  1. Confidential processing — no other system (Meta / WhatsApp / third party) sees data in processing or in transit.
  2. Enforceable guarantees — modification attempts fail closed or become publicly discoverable via the transparency log.
  3. Verifiable transparency — external researchers can audit: CVM image binary will be published; attestation-verification + load-bearing code open-sourced; Bug Bounty expanded to Private Processing; detailed security engineering design paper promised at launch.
  4. Non-targetability — an attacker cannot target a particular user without attacking the entire Private Processing system.
  5. Stateless processing + forward security — no retained access after the session, so a later CVM compromise cannot recover historical messages.

Threat model (Meta's canonical structure)

Assets — messages (in-flight + draft), the CVM's Trusted Computing Base, underlying hardware, cryptographic keys in transit. Threat actors — (1) malicious/compromised insiders with infrastructure access; (2) third-party / supply-chain vendors with component access; (3) malicious end users targeting other users. Named scenarios — (a) external actors exploit the product attack surface or compromise services inside CVMs (incl. prompt injection); (b) observability side-channels leak messages; (c) insiders tamper with the CVM at boot or runtime.

Disclosed operational controls

  • Hardened containerised binaries inside the CVM (cap blast radius on exploit).
  • Log-filtering system — only allow-listed log lines (e.g. error logs) exit the CVM; addresses the observability-vs-confidentiality tension.
  • Restricted-environment multi-party-reviewed CVM build — supply-chain defence.
  • Third-party log of CVM binary digests + published CVM image binary — transparency-side companion to attestation.
  • Encrypted DRAM + standard physical datacentre controls — hardware / physical-access defence.
  • Remote shell access prohibited (including from the host machine).
  • OHTTP relay for routing — non-targetability.
  • Enhanced host monitoring — abuse detection outside the CVM without observing its contents.
  • Novel-vulnerability tracking + continuous internal + external audits.

Three user-level principles (above the infrastructure)

  • Optionality — all AI features including Private Processing are optional.
  • Transparency — features that use Private Processing are identified as such.
  • User control — WhatsApp's Advanced Chat Privacy feature lets users disable AI features per-chat (e.g. the @Meta AI mention).

What's not disclosed

  • TEE vendor (AMD SEV-SNP / Intel TDX / Arm CCA not named).
  • Confidential-GPU vendor/mode ("Confidential Compute mode GPUs" only; NVIDIA Hopper CC is the obvious candidate but is not named).
  • Specific attestation protocol (RA-TLS is named; underlying attestation claims format is not).
  • Third-party relay + CDN + ledger operators are unnamed (only "a third-party…").
  • Production numbers (latency, throughput, CVM fleet size) — this is an architecture preview, not a retrospective.
  • Prompt-injection-specific defences — flagged as a threat class, but only generic TEE mitigations are listed.

Positioning

Private Processing is the canonical wiki instance of the TEE-for-private-AI-inference architectural pattern: a structural alternative to both on-device inference (too constrained for large models) and standard server-side inference (breaks E2EE). It composes the concepts/confidential-computing primitive with the OHTTP + anonymous-credential unlinkability stack and a published binary ledger so that the trust statement "Meta cannot see your messages" is backed by mechanism, not just policy.

Seen in

Last updated · 319 distilled / 1,201 read