metaAug 12, 2026

How We’re Building Scam Alert on WhatsApp With End-to-End Encryption and Verifiability Guarantees (opens in new tab)

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.

end-to-end-encryptiondifferential-privacyconfidential-computingfederated-analytics+3

lineJul 10, 2026

One Million Events per Second: Implementing End-to-End Encryption with Apache Kafka in the LINE App (opens in new tab)

LINE handles billions of messages daily, including highly sensitive personal data. While Kafka already provides TLS, authentication, and authorization, those controls do not protect message contents stored in brokers from privileged access. LY Corporation therefore introduced Kafka client-to-client end-to-end encryption, keeping payloads encrypted from producers through consumers while supporting large-scale traffic, flexible consumers, and minimal overhead. ## Limits of Kafka’s Existing Security Model - TLS protects data in transit between clients and brokers. - SASL authenticates clients before they connect. - ACLs control which users or groups can publish to or consume from topics. - These mechanisms primarily control access and communication channels; broker-stored payloads may still exist in plaintext. - End-to-end encryption adds a defense-in-depth layer by encrypting data at production and decrypting it only at authorized consumers. ## Record-Level Encryption - LY Corporation chose record-level rather than batch-level encryption. - Batch encryption offers better compression and lower CPU overhead, but would require modifying Kafka client internals because standard extension points operate at the record level. - Record encryption works with Kafka interceptors, serializers, and deserializers without modifying existing Kafka clients. - Using standard APIs also improves compatibility with future Kafka upgrades, despite somewhat larger messages and reduced compression efficiency. ## DEK–KEK Key Architecture - Payloads are encrypted with a symmetric AES-GCM data encryption key (DEK). - The DEK is encrypted with an ECC-based key encryption key (KEK), using ECIES and the `secp521r1` curve. - KEKs are managed through a key management service (KMS). - Producers use the KEK’s public key, while authorized consumers obtain the private key from KMS. - This hybrid approach: - Avoids the high cost of encrypting large payloads with asymmetric cryptography. - Keeps message size effectively independent of the number of consumers. - Separates encryption and decryption permissions according to the least-privilege principle. ## Encrypted Kafka Message Structure - **Key:** The existing Kafka message key remains unchanged for partitioning. - **Header:** Contains the KEK identifier and the DEK encrypted with that KEK. - **Body:** Contains the payload encrypted with the DEK. - Embedding metadata directly in each message avoids dependencies on external databases or caches. - Consumers identify the appropriate KEK, decrypt the DEK, and then decrypt the payload. ## Producer and Consumer Architecture ### Producer Encryption - Interceptors generate or select the DEK and place the encrypted DEK in the message header. - A wrapper serializer encrypts the serialized payload with the DEK. - The interceptor and serializer share the DEK through `ThreadLocal`, since they run on the same thread. - DEKs are cached for a limited period rather than regenerated and re-encrypted for every message, reducing asymmetric cryptographic overhead. ### Consumer Decryption - Consumers retrieve authorized private KEKs from KMS. - The deserializer reads the encrypted DEK from the header, decrypts it with the private KEK, and decrypts the payload. - Consumers cache encrypted-DEK/plain-DEK pairs, allowing repeated messages from the same producer to bypass redundant DEK decryption. - The existing deserialization process is wrapped so decryption occurs before normal deserialization. ### KMS Operations - Topic owners generate and register KEK key pairs. - Producers retrieve public keys, while authorized consumers retrieve private keys. - New consumers must request access to the private key and receive approval from the topic owner. - KMS manages key distribution, access control, and key rotation. ## Scaling Optimizations ### Shared KEKs - Assigning a unique KEK to every consumer would cause message headers to grow with the consumer count. - This would reduce Kafka batch sizes and increase network, CPU, and memory usage, especially for topics reaching up to one million messages per second. - Multiple consumers therefore share a single KEK, keeping the header size constant. - The trade-off is reduced per-consumer key isolation, mitigated through: - KMS authorization controls. - Mandatory periodic key rotation. - Centralized key management by the topic owner. ### Zero-Downtime Migration - During migration, encrypted and plaintext messages must coexist. - The consumer deserializer checks whether encryption metadata exists: - If headers are present, it decrypts the message. - If headers are absent, it processes the message using the existing plaintext path. - The migration sequence is: - Deploy compatible consumers first. - Enable producer encryption after all consumers support both formats. - Monitor the plaintext-message ratio and complete the migration once it reaches zero. - Producer encryption is intended to be enabled progressively rather than switched to 100% immediately, reducing the risk of unexpected performance or cryptographic failures. ## Practical Conclusion Kafka’s built-in security controls should be supplemented with payload-level encryption when brokers handle highly sensitive data. A record-level AES-GCM design combined with DEK–KEK key wrapping, KMS authorization, caching, shared KEKs, fallback processing, and gradual rollout provides a practical balance between confidentiality, scalability, and operational continuity.

end-to-end-encryptionapache-kafkazero-downtime-migrationkey-management-service+3

discordMay 18, 2026

Every Voice and Video Call on Discord Is Now End-to-End Encrypted (opens in new tab)

Discord now uses end-to-end encryption by default for nearly every voice and video call, without requiring users to opt in. The rollout, completed in March 2026, relies on the open DAVE protocol and spans desktop, mobile, browsers, consoles, bots/apps, and the Social SDK. Discord says encryption was introduced without reducing call quality or performance, though Stage channels remain exempt. ## Building DAVE Across Platforms - Discord began experimenting with voice and video E2EE in 2023. - The DAVE protocol was introduced in 2024 as an open, audited encryption system. - Support was expanded to: - Desktop and mobile - Web browsers - PlayStation and Xbox - Discord bots and apps - The Social SDK - The protocol and its implementation are publicly available and open source. - Trail of Bits externally audited the design and implementation. - Discord expanded its bug bounty program to cover DAVE. - The team collaborated with Mozilla to fix a Firefox issue that interfered with encrypted calls. ## Reaching Default Encryption - Since early March 2026, E2EE covers calls in: - Direct messages - Group DMs - Voice channels - Go Live streams - All clients must support DAVE before joining a call. - Discord is removing unencrypted fallback code, after which calls will no longer be able to downgrade to unencrypted connections. - Encryption operates transparently, preserving expected call quality and latency. ## Why Stage Channels Are Excluded - Stage channels are intended for large-scale broadcasts, AMAs, live events, and town halls. - Their broadcast-oriented architecture differs from personal voice and video conversations. - Discord therefore continues to exclude them from E2EE. ## Future Privacy Work - Discord will continue maintaining and improving DAVE, including its open protocol and bug bounty program. - The company has no current plans to add E2EE to text messages. - Many Discord text features depend on server-side access to messages, so supporting encryption would require substantial redesign. Discord’s recommendation is effectively to treat DAVE as an ongoing privacy foundation rather than a finished project: voice and video calls are now protected by default, while the protocol remains open to inspection and continued improvement.

end-to-end-encryptionopen-sourcebug-bountycross-platform+3

metaMay 11, 2026

Labyrinth 1.1: Making End-to-End Encrypted Backups Even More Reliable (opens in new tab)

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.

end-to-end-encryptionencrypted-backupsmessengercryptographic-protocol+1

metaMay 1, 2026

How Meta Is Strengthening End-to-End Encrypted Backups (opens in new tab)

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.

end-to-end-encryptioncloudflarehsmkey-distribution+3

metaMar 9, 2026

How Advanced Browsing Protection Works in Messenger (opens in new tab)

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.

end-to-end-encryptiondatabase-designprivate-information-retrievaloblivious-pseudorandom-function+4

cloudflareFeb 27, 2026

Bringing more transparency to post-quantum usage, encrypted messaging, and routing security (opens in new tab)

Cloudflare Radar is expanding its security coverage with new visibility into post-quantum encryption, Key Transparency for encrypted messaging, and ASPA deployment for routing security. The updates extend monitoring from user-to-Cloudflare connections to origin servers, provide tools for testing individual websites, and expose verification data that users can independently inspect. Together, they aim to make emerging Internet security technologies more measurable and transparent. ## Measuring Origin Post-Quantum Support - Cloudflare has tracked browser and client support for post-quantum encryption since 2024, rising from below 3% to more than 60% by February 2026. - The monitored algorithm, `X25519MLKEM768`, combines: - Classical X25519 key exchange - NIST-standardized ML-KEM post-quantum cryptography - Radar now measures whether customer origin servers support the same hybrid key exchange. - Cloudflare’s automated TLS scanner probes TLS 1.3-compatible origins and aggregates results daily. - The data measures algorithm support, not necessarily algorithm preference; a server’s TLS configuration can still choose a classical exchange even when post-quantum support exists. - Approximately 10% of origins currently support post-quantum-preferred key agreement, up from less than 1% in early 2025. - Adoption has accelerated as newer versions of OpenSSL, GnuTLS, and Go enabled hybrid post-quantum support by default. - Origin readiness data is available through Radar, Data Explorer, and the Radar API. ## Website Post-Quantum Compatibility Testing - Radar now includes a tool for testing whether a publicly accessible hostname supports post-quantum encryption. - Users can enter a hostname and optionally specify a port, with HTTPS port 443 used by default. - Results show: - Whether the connection is post-quantum secure - The negotiated TLS key exchange algorithm - The tool uses Cloudflare Containers to run a Go-based TLS scanner. - Because Workers cannot inspect the underlying TLS handshake, the container uses Go’s `crypto/tls` package to perform the connection and report the negotiated algorithm. - Cloudflare has consolidated its client- and origin-facing post-quantum measurements into a dedicated Radar section. ## Key Transparency for Encrypted Messaging - End-to-end encrypted services such as WhatsApp and Signal depend on correct public-key distribution. - If a messaging provider’s key database were compromised, an attacker could replace a contact’s public key and potentially intercept messages without detection. - Key Transparency mitigates this risk through an auditable, append-only public-key log. - The model is comparable to Certificate Transparency: - Messaging services publish users’ public keys to a transparency log. - Independent auditors verify that the log is correctly built and remains consistent. - Radar now provides a public dashboard for Key Transparency Logs used by E2EE messaging services. - The dashboard shows when each log was last signed and verified by Cloudflare’s Auditor. - Users can also access an API to independently validate the Auditor’s proofs. ## Routing Security and ASPA - Radar’s routing security coverage now includes global, country-level, and network-level information about ASPA deployment. - ASPA is an emerging standard intended to help detect and prevent BGP route leaks. - The new data extends Radar’s broader monitoring of Internet routing security. Cloudflare’s additions make post-quantum readiness, encrypted-message key integrity, and routing protection easier to measure and verify. Organizations can use the Radar dashboards, API, and hostname testing tool to assess their own migration and security posture.

end-to-end-encryptionnetwork-securitypost-quantum-cryptographycryptography+4

metaNov 20, 2025

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-encryptioncloudflaresecuritycryptography+2

discordSep 1, 2025

Bringing DAVE to All Discord Platforms (opens in new tab)

Discord is making DAVE, its end-to-end encryption protocol for audio and video calls, mandatory across all platforms. Browser support required solving WebRTC compatibility issues, designing an efficient Web Worker architecture, and reusing proven C++ cryptography through WebAssembly. Clients without DAVE support will be unable to join calls starting March 1, 2026. ## DAVE Becomes the Standard - DAVE already protects tens of millions of Discord calls daily. - Support is expanding to browsers, consoles, and the Social SDK. - Non-DAVE clients and applications will lose access to Discord calls on March 1, 2026. ## Browser Support and Firefox Compatibility - Discord uses the WebRTC Encoded Transform API to encrypt audio and video inside the WebRTC pipeline. - Firefox initially failed during real calls because its encryption Web Worker received no media data. - Discord engineers identified a recursive mutex deadlock in Firefox’s `FrameTransformerProxy`, triggered when video arrived too early. - Mozilla merged Discord’s fix, which is available in Firefox 142.0—the minimum Firefox version required for DAVE. ## Web Workers and Call State - Dedicated Web Workers encrypt and decrypt media: - One worker handles call audio and camera video. - Separate workers handle screenshare and game-stream audio and video. - Each media stream has a unique SSRC, allowing workers to select the correct symmetric encryption key for each frame. - Workers retain only essential call state, including SSRC-to-user mappings and encryption keys. - The main thread manages WebRTC connections, participants, and media tracks. - MLS membership changes are also handled on the main thread, preventing encryption work from delaying users joining or leaving calls. - Cryptographic state changes are sent asynchronously to workers. ## WebAssembly for Proven Cryptography - Discord compiled its existing, battle-tested C++ DAVE implementation to WebAssembly. - Reusing the same implementation across platforms reduces platform-specific security and reliability risks. - DAVE must selectively encrypt media while preserving metadata needed by WebRTC packetization and depacketization. - Since encrypted output cannot be modified in transit, byte-level parsing must be precise. - WebAssembly provides near-native performance while avoiding a more error-prone JavaScript reimplementation. ## WebAssembly Versus Browser Cryptography APIs - WebAssembly introduces a small performance cost compared with native browser APIs such as `SubtleCrypto`. - Discord’s benchmarks evaluate this trade-off against the benefits of shared, mature cryptographic code. - The post indicates that WebAssembly remains practical because frame parsing and selective encryption are computationally complex, while the security and portability benefits outweigh the minor cryptographic overhead. Discord’s platform transition means developers maintaining Discord clients, integrations, or SDK-based applications should add DAVE support before March 1, 2026. Browser users must also use Firefox 142.0 or newer when connecting through Firefox.

end-to-end-encryptionwebassemblywebrtccpp+2

discordFeb 26, 2025

Discord Update: September 26, 2024 Changelog (opens in new tab)

Discord’s September 2024 update centers on transforming the platform into a more interactive entertainment hub while significantly hardening its security infrastructure. By centralizing third-party integrations through a new App Launcher and implementing end-to-end encryption for audio and video, the platform aims to balance expanded developer functionality with robust user privacy. ### The App Launcher and Interactive Activities * The newly launched App Launcher is now available across desktop and mobile, allowing users to search, browse curated collections, and add thousands of apps directly to their accounts for use in chats and voice calls. * Four new Activities have been integrated: *Arena Kingdoms* for cross-server battles, *Echo Chess* for daily puzzles, the Viking-themed *Battletabs*, and the social-focused *Magic Circle*. * New image-editing capabilities allow users to hover over chat images to access the App Launcher for quick modifications, such as adding captions or using Viggle’s “Animate” command to generate motion from static photos. * The developer ecosystem has been expanded to allow third parties to build, launch, and monetize their own Activities, with options to opt-in to platform-wide discovery via the launcher. ### Security and Privacy Enhancements * End-to-End Encryption (E2EE) is being introduced for all audio and video communication, including DMs, Group DMs, voice channels, and Go Live streams, ensuring that stream data is accessible only to participants. * Support for Passkeys has been implemented, allowing users to replace traditional passwords with biometric authentication such as Face ID or Touch ID. * Passkey technology remains localized to the user's device, ensuring that Discord does not have access to sensitive biometric data. ### Platform Performance and Community Resources * Discord’s engineering team reported a significant performance milestone, reducing iOS application crashes by 84%. * The "Discord Dojo" initiative has launched to provide educational content, including videos and blogs focused on message formatting and advanced keybinds for power users. * A new partnership with *Street Fighter 6* introduces themed shop items and a specific Quest that rewards users with a "Battle Field" decoration for their profiles. To maintain the highest level of account safety, users should consider migrating to Passkeys and verifying the encryption status during their next voice or video call. For those looking to increase engagement within their servers, the App Launcher provides a low-friction way to introduce collaborative games and media tools directly into existing conversations.

end-to-end-encryptioniosperformance-optimizationpasskeys+3