End To End Encryption - Meta

metaAug 12, 20263 min readCurated summary

How We’re Building Scam Alert on WhatsApp With End-to-End Encryption and Verifiability Guarantees

WhatsApp’s optional Scam Alert uses an on-device machine-learning model to identify likely scam messages without sending message content to WhatsApp, Meta, or third parties. The system is designed to preserve end-to-end encryption, give users control over warnings and reporting, and make its model and privacy safeguards independently reviewable. It is being introduced gradually in Beta while security researchers test its implementation. ## Design Principles - **On-device only:** The model and messages it analyzes remain on the user’s device. - **No automatic reporting:** WhatsApp receives message content or scam-detection information only if the user explicitly reports a chat. - **User control:** Users can enable or disable Scam Alert and decide how to respond to warnings. - Recent advances in mobile machine learning make it practical to run a small, reviewable text-classification model locally. ## How Scam Alert Works - After activation, the device downloads the model and analyzes incoming messages from non-contacts. - Classification is based on conversational structure, language signals, and patterns found in previously reported scam conversations. - When a message appears suspicious, the user sees a private warning visible only to them. - The user can: - Block the sender - Report the chat - Continue the conversation - Mark the chat as trusted - Trusted chats no longer receive Scam Alert warnings. Users may optionally share the last five received messages from a trusted chat to help improve accuracy. ## Foundational Safeguards - **Privacy-preserving analytics:** Only anonymous, aggregate warning and user-action counts are collected. - **Confidential computing:** Metrics are processed inside confidential virtual machines using trusted execution environments. - **No targeted model delivery:** WhatsApp cannot send a specific model to an individual user. - **Public transparency:** Every model version, including experimental versions, is recorded in a public transparency ledger before deployment. - **Verifiable behavior:** Model weights are published so researchers can confirm that the model is designed specifically to detect scams. ## Privacy-Preserving Analytics WhatsApp wants to measure whether Scam Alert catches scams accurately without collecting message content. The system therefore limits telemetry to two categories: - **Warning counts:** Approximate aggregate counts of how often the model displays warnings, helping measure detection rates and identify regressions. - **User action counts:** Aggregate counts of whether users trust, block, or report after receiving warnings, helping estimate false-positive rates. These metrics are protected using differential privacy, which adds carefully calibrated noise so that the presence or absence of one person’s data has negligible impact on the aggregate results. ## Confidential Federated Analytics - Devices aggregate local events before transmitting them; raw signals never leave the device. - Metrics contain no device identifiers, use coarse time intervals, and are sent at randomized times. - Data is encrypted between the device and the trusted execution environment. - Devices verify the environment’s software through hardware-backed attestations and a third-party record of approved binaries. - The confidential environment prevents WhatsApp, Meta, relays, and other intermediaries from accessing individual measurements. WhatsApp’s approach aims to provide scam detection without weakening message privacy: processing remains local, reporting remains user initiated, and system performance is measured only through minimized, privacy-protected aggregates. The feature is currently best viewed as an early Beta system whose effectiveness and security will depend on continued public review and bug-bounty testing.

Read original

End To End Encryption Differential Privacy Confidential Computing Federated Analytics+3

metaMay 11, 20262 min readCurated summary

Labyrinth 1.1: Making End-to-End Encrypted Backups Even More Reliable

Meta is rolling out Labyrinth 1.1, an updated encrypted storage protocol for Messenger. Its main improvement is more reliable end-to-end encrypted backups: messages can be backed up as they are sent, even when the recipient’s device is offline. This helps preserve message history after device loss, replacement, or long periods without signing in, while keeping messages unreadable to Meta and other parties. ## Labyrinth 1.1’s Backup Improvements - The new sub-protocol sends messages to the recipient’s encrypted backup immediately rather than waiting for their device to reconnect. - This addresses limitations in Messenger’s current encrypted backup process. - Backups remain protected by end-to-end encryption, so only the users involved in the conversation can access the message contents. ## How Message Encryption Works - Each message is wrapped with a message encryption key. - The sender places that key directly into the recipient’s encrypted backup. - The design is compared to putting a sealed envelope into a locked box that only the recipient can open. - Meta cannot read the stored messages or their encryption keys. ## Rollout and Results - Labyrinth 1.1 is being broadly rolled out across Messenger. - Meta reports that more messages are being backed up successfully. - More users are also restoring their complete message history when switching devices. The updated “Labyrinth Encrypted Message Storage Protocol” white paper provides the detailed technical specification.

Read original

End To End Encryption Encrypted Backups Messenger Cryptographic Protocol+1

metaMay 1, 20262 min readCurated summary

How Meta Is Strengthening End-to-End Encrypted Backups

Meta’s HSM-based Backup Key Vault supports end-to-end encrypted backups for WhatsApp and Messenger by storing recovery codes in tamper-resistant hardware that Meta and third parties cannot access. The geographically distributed vault uses majority-consensus replication for resilience. Meta is strengthening the system with over-the-air fleet-key distribution for Messenger and public evidence of secure HSM fleet deployments. ## Over-the-Air Fleet Key Distribution - Clients verify HSM fleet authenticity using fleet public keys before establishing sessions. - WhatsApp embeds these keys directly in the application. - Messenger can receive keys over the air, allowing Meta to deploy new HSM fleets without requiring an app update. - Keys are delivered in validation bundles: - Signed by Cloudflare - Counter-signed by Meta - Recorded in a Cloudflare audit log - The complete validation process is documented in Meta’s *Security of End-To-End Encrypted Backups* whitepaper. ## Transparent HSM Fleet Deployment - Meta plans to publish evidence of the secure deployment of every new HSM fleet. - Users will be able to verify deployment evidence using the audit procedures in the whitepaper. - Deployments are expected to occur infrequently, generally no more than once every few years. - The transparency initiative is intended to demonstrate that Meta cannot access users’ encrypted backups. The system combines tamper-resistant HSMs, geographic replication, independently verifiable key distribution, and public deployment evidence. Readers seeking implementation details should consult the full whitepaper.

Read original

End To End Encryption Cloudflare Hsm Key Distribution+3

metaMar 9, 20263 min readCurated summary

How Advanced Browsing Protection Works in Messenger

Advanced Browsing Protection (ABP) extends Messenger’s Safe Browsing beyond on-device detection by checking links against a frequently updated database of millions of potentially malicious websites. Its central challenge is balancing effective URL matching with privacy: Messenger must identify unsafe links without revealing users’ exact queries or distributing the entire blocklist. ABP combines private information retrieval, cryptographic techniques, sharding, and client-side preprocessing to achieve this balance. ## Safe Browsing Within End-to-End Encryption - Messenger’s end-to-end encryption protects messages and calls, but it does not by itself protect users from malicious links. - Safe Browsing warns users when a link may lead to phishing, credential theft, or other harmful activity. - The standard feature uses on-device models. - Advanced Browsing Protection adds access to a continually updated watchlist containing millions of potentially malicious websites. ## Private Information Retrieval as the Foundation - Private information retrieval (PIR) allows a client to ask whether an item exists in a server-held database while revealing as little as possible about the query. - Sending the full database to each device is impractical because: - The database is large and frequently updated. - Exposing the complete list could help attackers evade detection. - Existing PIR approaches use oblivious pseudorandom functions (OPRFs) and divide the database into buckets or shards. - ABP had to address two limitations: - OPRFs are designed for exact matches, whereas URLs require prefix matching. - The client generally must identify which bucket to query, creating a privacy-versus-efficiency tradeoff. - More advanced lattice-based constructions may reduce the need for sharding, but they were not yet practical at ABP’s scale. ## Privacy-Preserving Prefix Matching for URLs - A database entry such as `example.com` should match a longer URL such as `example.com/a/b/index.html`. - Querying every prefix separately would work functionally: - `example.com` - `example.com/a` - `example.com/a/b` - `example.com/a/b/index.html` - However, each query can leak information about the original URL. If one query leaks `B` bits and there are `P` prefixes, the total leakage may reach `P × B` bits. - ABP instead groups URLs by domain so the client makes one bucket request and checks path prefixes within that bucket. - This reduces query leakage but creates uneven bucket sizes. - Domains such as link-shortening services may contain huge numbers of URLs, producing oversized buckets and potentially large padded responses. ## Preprocessing Rulesets to Balance Buckets - The server addresses bucket imbalance by generating a ruleset that tells clients how to process URLs before selecting a bucket. - Each rule maps an 8-byte hash prefix to a number of path segments that should be appended to the current URL before hashing again. - For example: - The client hashes `example.com`. - If the hash matches a ruleset entry, it appends specified path segments, such as `/a/b`. - It hashes the resulting URL again and repeats the process. - When no ruleset entry matches, the client uses the first two bytes of the final hash as the bucket identifier. - The server builds the ruleset iteratively: - It initially hashes URLs by domain. - It identifies the largest bucket. - It finds the most common domain in that bucket. - It adds rules that incorporate additional URL path segments to split the oversized bucket. - Clients receive the ruleset in advance and perform the same deterministic processing during lookups. ABP’s design demonstrates how privacy-preserving lookup can support real-world URL semantics without exposing users’ links. The combination of PIR, controlled sharding, prefix-aware processing, and adaptive rulesets allows Messenger to warn about malicious sites while limiting what the server learns about each user’s browsing query.

Read original

End To End Encryption Database Design Private Information Retrieval Oblivious Pseudorandom Function+4

metaNov 20, 2025Original article

Key Transparency Comes to Messenger (opens in new tab)

Messenger has enhanced the security of its end-to-end encrypted chats by launching key transparency, a system that provides an automated, verifiable record of public encryption keys. By moving beyond manual key comparisons, this feature ensures that users can verify their contacts' identities without technical friction, even when those contacts use multiple devices. This implementation allows Messenger to provide a higher level of assurance that no third party, including Meta, has tampered with or swapped the keys used to secure a conversation. ## The Role of Key Transparency in Encrypted Messaging * Provides a verifiable and auditable record of public keys, ensuring that messages are always encrypted with the correct keys for the intended recipient. * Prevents "man-in-the-middle" attacks by a compromised server by making any unauthorized key changes visible to the system. * Simplifies the user experience by automating the verification process, which previously required users to manually compare long strings of characters across every device their contact owned. ## Architecture and Third-Party Auditing * Built upon the open-source Auditable Key Directory (AKD) library, which was previously used to implement similar security properties for WhatsApp. * Partners with Cloudflare to act as a third-party auditor, maintaining a public Key Transparency Dashboard that allows anyone to verify the integrity of the directory. * Leverages an "epoch" system where the directory is updated and published frequently to ensure that the global log of keys remains current and immutable. ## Scaling for Global Messenger Traffic * Manages a massive database that has already grown to billions of entries, reflecting the high volume of users and the fact that Messenger indexes keys for every individual device a user logs into. * Operates at a high frequency, publishing a new epoch approximately every two minutes, with each update containing hundreds of thousands of new key entries. * Optimized the algorithmic efficiency of the AKD library to ensure that cryptographic proof sizes remain small and manageable, even as the number of updates for a single key grows over time. ## Infrastructure Resilience and Recovery * Improved the system's ability to handle temporary outages and long delays in key sequencing, drawing on two years of operational data from the WhatsApp implementation. * Replaced older proof methods that grew linearly with the height of the transparency tree with more efficient operations to maintain high availability and real-time verification speeds. * Established a robust recovery process to ensure that the transparency log remains consistent even after infrastructure disruptions. By automating the verification of encryption keys through a transparent, audited directory, Messenger has made sophisticated cryptographic security accessible to billions of users. This rollout represents a significant shift in how trust is managed in digital communications, replacing manual user checks with a seamless, background-level guarantee of privacy.

End To End Encryption Cloudflare Security Cryptography+2