Research · Published 2026-04-27

Messenger Privacy Report 2026 Q2

A snapshot of the messaging industry, sourced from public records. Twenty platforms. Twenty-four months. Primary sources only. We do not editorialize. We do not rank. We collect.

20
platforms profiled
49
verified events
478
primary sources
24
months covered
TL;DR Click to collapse

We examined twenty messaging platforms — what they tell users in their own privacy policies, what they tell governments in their own transparency reports, and what is documented in public court records. Below is what we found, in numbers.

14 / 4 / 1 / 1
Of the 20 platforms, 14 are centralized, 4 are federated, 1 operates a decentralized service-node network, and 1 is peer-to-peer.
11 / 4 / 3 / 2
End-to-end encryption by default: 11 cover all chats, 4 only direct chats, 3 are opt-in, and 2 do not offer E2EE in their main consumer service.
9 / 6
9 platforms publish full client source code under recognized open-source licenses; 6 publish full server source code.
15 / 11
15 publish a transparency report or law-enforcement disclosure document of any kind; 11 of those publish periodic numerical reports with request-volume figures.
20 / 20
Every one of the 20 platforms had at least one verified in-window event between 2024-04 and 2026-03 — incidents, audits, regulatory actions, policy changes, or legal proceedings.
9 / 3 / 8
At registration: 9 require a phone number, 3 require email, and 8 support neither. Five of the latter accept fully anonymous account creation by design.

This is an aggregation of public facts, not an evaluation. Each claim links to a primary source. We do not say a platform is "good" or "bad", "secure" or "insecure". The reader draws their own conclusions.

The data, visualized

Three views of the industry.

Architecture
How user data is structurally exposed.
20 platforms
14Centralized
4Federated
1Decentralized (Session)
1Peer-to-peer (Briar)
End-to-end encryption
Default behavior in main consumer service.
All chats 11
Direct only 4
Opt-in 3
Not offered 2
"Direct only" platforms reduce or omit E2EE for groups, channels, business chats, or RCS-to-non-RCS recipients.
Event density
49 verified events across 24 months.
2024 Q2
5
2024 Q3
6
2024 Q4
11
2025 Q1
7
2025 Q2
6
2025 Q3
4
2025 Q4
6
2026 Q1
4
Spike in Q4 2024 driven by Pavel Durov's indictment, multiple GDPR fines, and the EU Council's first CSAR vote.

Messenger Privacy Report — 2026 Q2

A snapshot of the messaging industry, sourced from public records.

Published by Catyonic OÜ · Tallinn, Estonia Date of publication: 2026-Q2 Document version: 1.0

This report is published under the Creative Commons Attribution 4.0 International licence (CC BY 4.0). The full dataset underlying every figure — messengers.csv, messengers_sources.csv, and timeline.json — is available on request from contact@catyonic.com for journalists, researchers, and academic use. Corrections are processed under the terms described in Appendix A.

Introduction

This report aggregates publicly available information about twenty messaging platforms that collectively serve billions of users. It is not an evaluation. It is a snapshot. Each fact in this document is sourced from the platforms' own disclosures — their privacy policies, transparency reports, security whitepapers, and publicly acknowledged incidents. Where this report cites third-party sources, it uses court records, regulator filings, peer-reviewed academic publications, or the published work of named independent security researchers. This report does not editorialise. It does not rank. It collects.

What this report is

A reference compilation of factual claims about the architecture, encryption, identification requirements, data-retention practices, transparency reporting, and publicly disclosed incidents of twenty messaging platforms over the period 2024-04-01 to 2026-03-31. Each claim is attributed to its source. Each operator's claims about its own product are presented as that operator's claims. Where independent verification exists, the verification is cited. Where verification does not exist, the claim is presented with that limitation noted.

What this report is not

This report does not evaluate platforms. It does not designate winners or losers. It does not assign ratings, scores, or rankings. It does not recommend that the reader use or avoid any platform. It does not pass judgement on the privacy practices of any operator, except by recording what those practices are as the operator itself describes them and as third parties have publicly documented them.

How to read this report

Begin with the Executive Summary for the headline figures. The Industry-wide Timeline records every in-window event admitted under the verification criteria in Appendix A. The Architecture Primer provides the conceptual vocabulary for reading the platform profiles; readers unfamiliar with terms such as "end-to-end encryption", "metadata", "federation", or "reproducible builds" should read the primer before the profiles. The Platform Profiles that follow occupy one page per platform in a uniform template; comparison across platforms is left to the reader. Appendix A describes the methodology in full. Appendix B lists the sources cited throughout.

Methodology in brief

Every factual claim in this document carries a primary source citation. Primary sources include operators' own published documents (privacy policies, terms of service, transparency reports, security whitepapers, source-code repositories), regulator filings, court records, peer-reviewed academic publications, and the published work of named independent security researchers. Personal social-media statements by founders, executives, or other interested parties are not accepted as primary sources. Tier-one news reporting is admitted only in combination with at least one other verification source. The full methodology — including source hierarchy, verification thresholds, dating and archival conventions, language standards, the corrections process, and conflict-of-interest disclosures — is documented in Appendix A.

Executive Summary

This snapshot of twenty messaging platforms reflects the state of public documentation as of 2026-04-21. All figures below are derived from the platforms' own privacy policies, transparency reports, security whitepapers, source-code repositories, regulator filings, court records, and peer-reviewed publications cited throughout this report. Where a platform does not publicly document a given attribute, that attribute is recorded as "Not publicly documented" in the underlying dataset and excluded from positive counts.

Of the 20 messaging platforms examined:

  • 14 operate on centralized infrastructure. 4 federate across multiple servers (Matrix/Element, SimpleX, XMPP). 1 operates over a permissionless decentralized service-node network (Session). 1 operates peer-to-peer with no operator-run server (Briar).
  • 9 publish full source code for their clients under recognised open-source licenses. 6 publish full source code for their servers. 6 have undergone an independent third-party security audit or peer-reviewed cryptographic analysis whose results were published between 2024-04-22 and 2026-04-22 (iMessage, Discord, LINE, Signal, Session, SimpleX). Where a platform's last published audit predates this 24-month window, the most recent audit date is recorded in the platform profile.
  • 15 publish a transparency report or equivalent law-enforcement-disclosure document of any kind. 11 of those publish periodic numerical reports with request-volume figures; the remaining 4 publish aperiodic subpoena disclosures, legal-framework statements, or law-enforcement guidelines without comparable numerical data.
  • 20 of the 20 platforms have at least one in-window entry in the industry timeline covering 2024-04-01 to 2026-03-31, spanning publicly disclosed security incidents, protocol vulnerabilities, transparency-report releases, policy changes affecting user privacy, regulatory actions, legislative milestones, platform blockings, or legal actions against operators or personnel.
  • End-to-end encryption behaves differently across platforms: 11 enable end-to-end encryption by default for all chats and calls (WhatsApp, iMessage, Viber, Signal, Wire, Threema, Wickr, Session, Matrix/Element default for new chats, SimpleX, Briar). 4 enable end-to-end encryption by default only for direct/personal chats with reduced or absent coverage for group chats, group calls, business chats, channels, or RCS-to-non-RCS recipients (Facebook Messenger, Google Messages, Discord, LINE). 3 offer end-to-end encryption only as an opt-in feature (Telegram Secret Chats, KakaoTalk Secret Chat, XMPP via OMEMO at client discretion). 2 do not offer end-to-end-encrypted messaging as a product feature in their main consumer service (Snapchat, WeChat/Weixin).

Additional countable observations:

  • 9 platforms require a phone number at registration. 3 require an email address. 9 support registration without a mandatory phone number — among them, several still link some optional identifier (email, Apple Account, social account, work email) at registration, while five require neither phone nor email and accept anonymous account creation by design (Threema, Wickr, Session, SimpleX, Briar; Matrix/Element and XMPP also support this on operator-permitting homeservers).
  • 9 platforms are headquartered in the United States. 6 are headquartered in EU member states, Switzerland, or the United Kingdom (Viber in Luxembourg; Wire, Threema, and Session in Switzerland; Matrix/Element and SimpleX in the United Kingdom). 3 are headquartered in East Asia (WeChat/Weixin in China and Singapore; LINE in Japan; KakaoTalk in South Korea). 1 operates from the United Arab Emirates with parent company in the British Virgin Islands (Telegram). 1 is an unincorporated community project with no declared headquarters jurisdiction (Briar). The XMPP Standards Foundation is registered in the United States; XMPP itself is a protocol with operators worldwide.
  • 7 platforms offer a self-hosting path for organisations that wish to operate their own server infrastructure (Wire, Threema via OnPrem, Wickr via Wickr Enterprise/RAM, Session via community service nodes, Matrix/Element, SimpleX, XMPP). The remaining 13 do not publicly document a self-hosting option for the consumer service.
  • Across the platforms in this report that publish comparable numerical transparency data and that issued reports covering periods overlapping the 2024-04-01 to 2026-03-31 window, government/law-enforcement requests disclosed include — selected indicative figures from each platform's own most recent published report — Threema 423 requests in calendar year 2025 (422 complied with, data produced in 402 cases), and aggregate disclosures from Meta, Apple, Google, Snap, Discord, Viber, LINE, KakaoTalk, and AWS published in their respective transparency portals. Aggregation across platforms is not meaningful given differences in scope, methodology, and reporting period; readers are referred to each platform's own report for like-for-like comparison.

The complete dataset, including per-field source URLs, archive snapshots, and the full incident timeline, accompanies this report. For the methodology used to assemble these figures, see Appendix A. For the full source list, see Appendix B.

Industry-wide timeline — Messenger Privacy Report 2026 Q2

Reporting window: 2024-04-01 → 2026-03-31.

Q2 2024

The reporting window opens with China's CAC ordering Apple to delist four encrypted messengers from its mainland storefront, while India's Delhi High Court hears WhatsApp's first on-record statement that it would exit the country rather than break encryption.

2024-04-19 — China App Store removal of four messengers. Apple removed WhatsApp, Threads, Telegram and Signal from its mainland-China storefront at CAC order.

2024-04-25 — WhatsApp tells Delhi HC it would exit India if compelled under Rule 4(2) of the 2021 IT Rules to identify the first originator of messages.

2024-05-23 — PIPC Korea fines Kakao KRW 15.1 billion over KakaoTalk open-chat ID exposure affecting ~65,710 users.

2024-05-28 — Belgian Presidency CSAR compromise ST 9093/24 circulated with a user-consent scanning construction.

2024-06-20 — Belgian Presidency withdraws CSAR from COREPER II. No qualified majority reached.

Q3 2024

Telegram's CEO is detained in France, triggering the first major Western criminal proceeding against an encrypted-messenger operator; within 26 days Telegram rewrites its Privacy Policy. Russia blocks Signal.

2024-07-01 — LY Corporation reports to Japan's MIC on measures following the 2023 NAVER-originating intrusion.

2024-08-09 — Roskomnadzor restricts Signal in Russia — first national-level restriction per Freedom House 2025.

2024-08-28 — Pavel Durov mis en examen in Paris on twelve counts including refusal to communicate lawful-interception information. Travel ban fully lifted 2025-11-13; no indictment or trial date as of window close.

2024-09-09 — Hungarian Presidency CSAR compromise ST 12406/24 circulated; no Council vote followed.

2024-09-23 — Telegram expands Privacy Policy to permit IP and phone disclosure on valid judicial orders in general criminal investigations.

2024-09-27 — Ireland DPC fines Meta €91M for plaintext password retention.

Q4 2024

CISA and FBI publicly recommend Signal by name — the first US federal written guidance to name a specific encrypted messenger. Russia extends to Discord and Viber. A US court grants summary judgment against NSO Group.

2024-10-08 — Roskomnadzor restricts Discord in Russia.

2024-10-09 — Turkey blocks Discord following an Ankara criminal-court order.

2024-10-24 — Linker, Sasse, Basin publish TAMARIN formal verification of iMessage PQ3 (USENIX Security 2025). No practical break; complements Stebila's reduction-based analysis.

2024-10-24 — EU Commission preliminary DSA findings against Meta and TikTok on Article 40 researcher-access and Article 16 notice-and-action. WhatsApp/Messenger not in scope.

2024-10-23 — Wire moves MLS (RFC 9420) to general availability. Wire Swiss GmbH announces GA of Messaging Layer Security across Wire clients, replacing Proteus for new conversations; Wire's CTO Alan Duric co-authored the original IETF MLS charter in 2016.

2024-11-18 — India CCI fines Meta/WhatsApp INR 213.14 crore over the 2021 privacy-policy update.

2024-12-03 — CISA and FBI recommend E2EE messaging on Salt Typhoon press call.

2024-12-13 — Roskomnadzor restricts Viber (~17M Russian daily users prior).

2024-12-16 — Ofcom Illegal Harms Codes of Practice published under the UK Online Safety Act.

2024-12-18 — CISA Mobile Communications Best Practice Guidance names Signal by name.

2024-12-20 — Meta/WhatsApp summary judgment against NSO Group on CFAA, CDAFA and ToS claims.

Q1 2025

Apple withdraws iCloud Advanced Data Protection in the UK following a Home Office Technical Capability Notice — the first publicly documented messenger-adjacent confidentiality downgrade executed by a major provider in response to a Western democracy's compelled-access order.

2025-01-07 — Telegram bot discloses 900 US requests / 2,253 users for CY2024, a >60× jump after the September 2024 policy change.

2025-01-31 — PIPC Korea sanctions Kakao Pay (KRW 5.9B) and Apple Distribution International (KRW 2.4B) for undisclosed cross-border transfer to Alipay; algorithm erasure ordered.

2025-02-01 — AWS publishes first EU DSA Transparency Report; Wickr aggregated within AWS totals.

2025-02-13 — Wire Swiss GmbH publishes SHAB notice of €24M Series B funding round to expand secure collaboration offerings for enterprise and public-sector customers.

2025-02 — Polish Presidency CSAR compromise removes detection orders; only 11 MSs supportive (~42.43% of EU population).

2025-02-21 — Apple withdraws iCloud Advanced Data Protection in the UK. "We have never built a backdoor or master key to any of our products or services."

2025-03-17 — Ofcom Online Safety Act enforcement powers take effect. Fines up to 10% of global turnover or £18M.

Q2 2025

The Commission formalises the ProtectEU agenda. Citizen Lab forensically confirms the first Paragon Graphite zero-click infections via iMessage. Vietnam joins the list of states ordering Telegram blocks.

2025-04-01 — ProtectEU Communication COM(2025) 148 commits to a Technology Roadmap on encryption by Q2 2026.

2025-04-07 — UK IPT rejects Home Office secrecy request in Apple TCN case (IPT/25/68/CH).

2025-05-21 — Vietnam orders ISPs to block Telegram.

2025-06-04 — Apple H1 2024 Transparency Report published after ~20-month delay; push-token compliance 77%→59% globally; US 88%→28%.

2025-06-11 — CVE-2025-43200 / iMessage zero-click disclosed after Feb patch; Citizen Lab confirmed infection of two European journalists via ATTACKER1 account delivering Paragon Graphite.

2025-06-24 — ProtectEU Lawful Access Roadmap COM(2025) 349 published.

Q3 2025

The second major zero-click messenger exploitation event of the window — CVE-2025-55177 chained with CVE-2025-43300 — underscores targeted interception as the dominant practical threat vector.

2025-07-01 — Danish Presidency CSAR compromise reintroduces mandatory detection orders.

2025-08 — Roskomnadzor begins phased restriction of WhatsApp/Telegram voice/video; ~34 regions by October.

2025-08-19 — DNI Gabbard states UK dropped backdoor demand for US citizens' Apple data. Scope for non-US users not confirmed.

2025-08-29 — CVE-2025-55177 / WhatsApp linked-device-sync zero-click chained with Apple CVE-2025-43300; <200 users threat-notified by Meta; CISA KEV with 2025-09-23 federal patch deadline.

Q4 2025

The Danish Presidency's October push for a mandatory-detection CSAR vote collapses; the Council settles on a voluntary-only General Approach in late November. Russia extends to Snapchat and FaceTime.

2025-10-07 — LY Corporation publishes first EU DSA Transparency Report alongside H2 2024 Transparency Report.

2025-10-10 — Roskomnadzor restricts Snapchat in Russia.

2025-10-14 — Danish Presidency cancels CSAR Council vote. Blocking minority of 11 MSs (>35% EU population).

2025-11 — Signal publishes redacted D.D.C. subpoena covering 37 phone numbers after ACLU obtained non-disclosure-order modification; only Unix timestamps retained and disclosed.

2025-11-26 — Council adopts partial General Approach on CSAR — voluntary-only framework. CZ/NL/PL/SK against; IT abstained. Trilogue opened 2025-12-09.

2025-12-04 — Roskomnadzor restricts FaceTime in Russia.

Q1 2026

The Commission formally designates WhatsApp Channels as a VLOP — the first VLOP designation of a messenger-embedded broadcast product. Parliament rejects clean extension of Chat Control 1.0.

2026-01-26 — WhatsApp Channels designated VLOP. 46.8M (H2 2024) / 51.7M (H1 2025) average monthly EU recipients. Private messaging remains explicitly outside the DSA definition of an online platform.

2026-03-11 — EP adopts position on Chat Control 1.0 conditional extension (458/103/63), excluding E2EE from scope. Council rejected.

2026-03-11 — Meta transitions Transparency Center to semiannual reporting. H2 2025 Government Requests report deferred.

2026-03-26 — EP rejects clean extension of Chat Control 1.0 derogation (311/228/92). Regulation (EU) 2021/1232 expired 2026-04-04 (outside window).

Transparency-report cadence — window snapshot (aggregated)

Platform 2024 H1 2024 H2 2025 H1 2025 H2 Notable anomaly
Apple (iMessage/FaceTime) Published Jun 2025 (delayed ~20mo) Published Published Pending Push-token compliance 77%→59% globally; US 88%→28%
Google (Google Messages/RCS) Published Published Published Published Sept 2025 correction to UK CLOUD Act IPA CDR figures
Meta (WhatsApp, Messenger) Published Published Published Deferred (cadence change 2026-03) Global requests peaked H1 2024 at 323,846 then -0.5%
Signal Legal-process publication only — — One new posting: D.D.C. 37-number subpoena Only Unix timestamps retained
Snap (Snapchat) Published + proactive metrics Published Published Published Proactive-enforcement disclosure from H1 2024
Discord Published Quarterly→semiannual shift Published Published Cadence change in-window
Telegram Bot-only, per-region, account-gated Bot-only Bot-only Bot-only CY2024 US: 900 requests / 2,253 users (>60× jump)
LY Corporation (LINE) May 2025 Oct 2025 Published Pending First EU DSA Transparency Report (Oct 2025)
Kakao (KakaoTalk) Published Published Published Published "Illegal Products & Services" added June 2025
Rakuten Viber Not public Not public First DSA report Feb 2025–Dec 2025 First DSA report First-ever DSA disclosure in-window
Threema Annual — Annual — CY2023 figure (170 requests) last highlighted
Amazon (Wickr aggregated) Published Published Published Published Zero non-US-stored content disclosures to USG held constant
Wire Not publicly documented Not publicly documented Not publicly documented Not publicly documented —
Session Not publicly documented Not publicly documented Not publicly documented Not publicly documented —
Matrix.org Foundation LE Guidelines only LE Guidelines only LE Guidelines only First Public Annual Report (FY2025) Mar 2026 First-ever Foundation Annual Report

"Not publicly documented" reflects absence of a publicly published aggregated transparency report meeting tier-1 peer standards — it does not assert the platform received zero requests.

Architecture Primer

This section provides the conceptual vocabulary used throughout the platform profiles. It does not name any commercial product. It describes classes of architectures, the privacy properties those classes do and do not provide, and the technical and legal vocabulary required to read each platform's profile critically.

1.1 What end-to-end encryption does, and what it does not do

End-to-end encryption (E2E or E2EE) is a property of a communication system in which the cryptographic keys required to decrypt a message exist only on the endpoints participating in the conversation. The operator of the intermediate transport infrastructure — the message-relay server, the federation hub, the routing network — does not possess the keys and cannot decrypt the content of messages in transit or at rest on its servers. The Internet Engineering Task Force's standard for end-to-end-encrypted group messaging, Messaging Layer Security (MLS), defines this property in RFC 9420; the Signal Protocol's Double Ratchet construction, described by Marlinspike and Perrin in 2016, provides the most widely deployed two-party instantiation. Modern protocols typically combine an asymmetric key-agreement step (X25519, X448, or — increasingly — a hybrid combining a classical curve with a Module-Lattice-based Key Encapsulation Mechanism such as ML-KEM, standardised by the United States National Institute of Standards and Technology as FIPS 203 in 2024) with a symmetric ratcheting construction (typically AES-256-GCM or ChaCha20-Poly1305 keyed by per-message values derived from a continuously evolving root key).

End-to-end encryption protects the content of messages from the operator, from passive network observers, and from anyone who later compromises the operator's servers. It does not protect metadata: who sent a message to whom, when, from which device, from which IP address, in which session, of what approximate size, against what schedule. Metadata is generally produced as a by-product of the routing function itself and is, in most architectures, visible to the operator. Several published surveys — notably Unger et al., "SoK: Secure Messaging" (IEEE Symposium on Security and Privacy, 2015, DOI 10.1109/SP.2015.22) — distinguish "confidentiality of content" from "metadata privacy" and show that achieving both simultaneously requires architectural choices well beyond E2E itself.

End-to-end encryption is also not a protection against compromised endpoints. A device infected with commercial spyware (for example, the families documented by Citizen Lab including Pegasus and Predator) can read decrypted content directly from the screen buffer, the messaging application's memory, or the local message database. End-to-end encryption is a guarantee about who can read messages in transit; it is not a guarantee about who can read messages once they are decrypted at the destination.

The "encrypted but recoverable" tension arises whenever a system must offer message backup, multi-device synchronisation, or account recovery without a human-memorised secret. If a backup is encrypted with a key the operator can derive or possesses, the backup is not, in cryptographic terms, end-to-end-encrypted from the operator's perspective. If a backup is encrypted with a key the user holds — typically a recovery code, a hardware-security-module-stored key, or a passphrase used only locally — then the operator cannot decrypt the backup, and the user bears full responsibility for not losing the key. Most consumer messaging products choose a hybrid: an opt-in backup tier that is end-to-end-encrypted with a user-held key, and a default tier that is server-side encrypted with operator-held keys to enable seamless recovery. The two tiers have very different privacy characteristics against adversaries with legal authority over the operator. When reading a profile, "backup encryption" should always be read together with the question: who holds the key.

1.2 Metadata versus content: the legal and operational distinction

Major data-protection frameworks treat content data and metadata under different rules. Article 4(1) of the European Union's General Data Protection Regulation defines "personal data" to include any information relating to an identified or identifiable natural person; metadata fields such as IP addresses, account identifiers, device identifiers, and connection logs typically qualify. The Stored Communications Act (Title II of the Electronic Communications Privacy Act, 18 U.S.C. §§ 2701–2713) in the United States distinguishes "contents" (subject to a higher legal threshold) from "non-content records" (obtainable on a lower standard, often a §2703(d) order or a subpoena). The Personal Information Protection Law of the People's Republic of China (in force 2021-11-01) and the Personal Information Protection Act of the Republic of Korea (most recent comprehensive amendment in force 2023-09-15) likewise establish categorical distinctions affecting how metadata is collected, retained, and disclosed.

Operationally, metadata is what makes the system function. Routing requires that the server know where to send a packet. Delivery confirmation requires that the server know whether a packet arrived. Account recovery requires that the server be able to recognise a returning user. Federation requires that one server know which other server holds the recipient's account. These are not optional features that can be removed by a privacy policy; they are properties of the architecture. A platform's "metadata retained" disclosure is best read as a list of the data categories the operator's architecture necessarily generates and that the operator's policy then chooses to either retain on disk, log temporarily, or discard immediately after use.

The Electronic Frontier Foundation's "Surveillance Self-Defense" guides (eff.org/sls) provide an accessible introduction to how metadata enables deanonymisation and relationship mapping without ever accessing message content. Academic work going back at least to Edman and Yener, "On Anonymity in an Electronic Society: A Survey of Anonymous Communication Systems" (ACM Computing Surveys, 2009), and more recent surveys on traffic analysis, demonstrate that even modest metadata — pairs-of-endpoints with timestamps, message-size distributions, and timing patterns — is often sufficient to reconstruct social graphs, identify clusters of related users, and distinguish broadcast from one-to-one communication. The "business records" doctrine in United States jurisprudence, established in Smith v. Maryland, 442 U.S. 735 (1979), and partially reconsidered in Carpenter v. United States, 138 S. Ct. 2206 (2018), treats certain categories of metadata held by third-party service providers as obtainable without a warrant; messaging providers fall within the scope of the doctrine for many forms of metadata, with carve-outs for cell-site location information and certain other categories.

The practical implication is that a platform may simultaneously offer strong end-to-end encryption of content and retain enough metadata to satisfy a wide range of law-enforcement requests without ever decrypting a single message. When reading a transparency report, the question to ask is not whether the operator decrypted content — almost always, with end-to-end-encrypted services, the answer is no — but rather what categories of non-content information were produced.

1.3 Centralized architectures

A centralized messaging architecture has a single operator (or a small number of operators acting as one entity) that runs the message-relay infrastructure, the directory service for account discovery, the push-notification gateway, the storage layer for offline messages, and any media-attachment store. All traffic between users transits the operator's infrastructure; in principle, the only routes between two users are through that infrastructure.

Centralised architectures present a single point of compliance. A regulator, court, or law-enforcement agency in a jurisdiction with authority over the operator (or its corporate parent, or its key personnel, or its banking relationships) can serve a single legal demand and receive — depending on the demand and the operator's policies — every category of non-content data the operator holds, plus assistance in identifying users, plus, in jurisdictions with relevant interception laws, the obligation to participate in the technical surveillance of specific accounts. The operator is the only entity that needs to receive such a demand.

The user's trust model in a centralised architecture is summarised by the question: do I trust this operator? End-to-end encryption answers a narrower version of that question — do I trust this operator with the content of my messages — but does not answer the broader version. The user must trust the operator (or trust the legal regime that constrains the operator) with respect to metadata retention, response to legal demands, defence against unauthorised access, software supply-chain integrity, and the operator's own continued willingness to operate the service on the user's behalf.

Common metadata-retention patterns in centralised architectures include: account creation date, last-connectivity timestamp, registered identifier (typically a phone number or email address, sometimes a username), device identifiers and platform information, IP addresses observed at connection, friend or contact lists and their hashed forms, group membership and group metadata, server-side encrypted message queues for offline delivery (typically time-limited), media-attachment storage with operator-held keys (typically until the recipient downloads the attachment or a fixed retention period elapses), and session-level diagnostic logs. Specific retention periods vary by operator and are usually documented in the operator's privacy policy under headings such as "Data Retention" or "How Long We Keep Your Information".

Jurisdictional exposure follows the operator's choice of corporate domicile and the locations of its servers. A platform headquartered in the European Union faces GDPR-driven data-subject access rights and the EU's evolving regulatory framework (the Digital Services Act for platforms above the very-large-online-platform threshold, the Digital Markets Act for designated gatekeepers, and proposed regulations on child sexual abuse material that have remained under negotiation through 2024–2026). A platform headquartered in the United States faces the Stored Communications Act and the CLOUD Act, which extends the reach of US legal process to data held by US companies regardless of where the data resides. A platform headquartered in the People's Republic of China is subject to the Cybersecurity Law (in force 2017-06-01), the Data Security Law (in force 2021-09-01), and the Personal Information Protection Law (in force 2021-11-01), all of which establish data-localisation and security-review obligations administered by the Cyberspace Administration of China.

1.4 Federated architectures

A federated architecture distributes the operator role across many independent servers ("home servers", "instances", "hosts") that interoperate via a common protocol. The closest familiar analogue is electronic mail: any operator running a mail server can exchange messages with any other operator's mail server using SMTP (RFC 5321) and a small family of related protocols, without any central authority. The two best-known federated messaging protocols today are XMPP (RFC 6120 and the Extensible Messaging and Presence Protocol family of XEPs maintained by the XMPP Standards Foundation) and the Matrix protocol (specified at spec.matrix.org). MLS (RFC 9420) is increasingly being layered on top of federated transports for end-to-end-encrypted group messaging.

In a federated architecture, compliance is distributed. A legal demand served on the operator of one server reaches only the users whose accounts are hosted on that server. Users whose accounts are on a different server are reachable only through a second demand served on that server's operator, in that operator's jurisdiction, under that jurisdiction's law. This complicates compliance for both the regulator (more parties to serve) and for the user (the user must understand which server hosts their account and what jurisdiction governs that server's operator).

Federation generates an additional category of metadata: which server talked to which. When a user on home server A sends a message to a user on home server B, server A typically transmits the message to server B over a federated transport. Server B's operator learns that an account on server A is communicating with a specific account on server B, even where the message content is end-to-end-encrypted between the two users. Server A's operator learns the converse. Federation-level metadata is in principle visible to both operators of each pair of federating servers, and to network observers between them, in a way that does not arise in a centralised architecture. The Matrix specification's room-state and event-graph design makes some of this metadata particularly persistent in encrypted rooms with many participants.

The home-server trust model is more granular than the centralised model: a user trusts a chosen home-server operator (which the user may have selected, or may have been assigned by virtue of employer or institution), and trusts each remote home server only to the extent of the metadata that federation exposes to it. Self-hosting one's own home server is a common option in federated systems and shifts the trust calculation accordingly: the self-hoster trusts only their own infrastructure for accounts hosted there, but still relies on remote home servers for federation with users elsewhere.

A federated architecture is not, by virtue of being federated, a private architecture. The operator of the home server that a user chose still observes the same categories of metadata that a centralised operator would. The user has gained the ability to choose that operator (and to change operators, with effort), but has not eliminated the operator role.

1.5 Peer-to-peer architectures

A peer-to-peer (P2P) messaging architecture has no operator-run server in the message path. Each user's device communicates directly with each other user's device — sometimes over the public internet, sometimes over an overlay network such as Tor (torproject.org), I2P (geti2p.net), a Distributed Hash Table such as Kademlia (Maymounkov and Mazières, 2002), a dedicated mix network, or an ad-hoc local-area transport such as Bluetooth or Wi-Fi Direct.

P2P architectures eliminate the central operator's logs entirely. There is no operator to serve a subpoena on, because there is no operator. The trade-off is that the functions an operator would perform must be either performed by the network as a whole (with corresponding distributed-systems complexity), performed by the user's device (with corresponding device-state requirements), or omitted from the system. In practice, the omitted or device-resident functions include: account discovery (the user must obtain a contact's identifier through an out-of-band channel, often a QR code or a manually entered string); offline delivery (messages addressed to a peer that is not currently online must either be queued by the sender's device until the peer reconnects, relayed by intermediate volunteer nodes with the corresponding metadata exposure, or dropped); multi-device synchronisation (the user must arrange for keys and message history to be shared between their own devices, often manually); and large-group performance (broadcast in a P2P system without a central relay scales differently than in a centralised system, with corresponding constraints on group size and message rate).

Network-level metadata in a P2P system is mitigated, but not eliminated, by the choice of overlay network. A P2P system that runs over Tor inherits Tor's anonymity properties and its limitations: low-bandwidth, higher-latency, and susceptibility to traffic-correlation attacks by global passive adversaries. A P2P system that runs directly over IP exposes both endpoints' IP addresses to each other and to network observers between them. A P2P system that uses DHT for discovery exposes the discovery queries to whoever can observe DHT traffic.

P2P architectures are rarely suitable as a default product for non-technical users because the trade-offs above (account-discovery friction, multi-device-synchronisation friction, offline-message limitations) directly affect the user experience for people whose communication patterns assume operator-mediated convenience. P2P architectures are particularly well-suited to use cases where the absence of any operator is itself a primary requirement — typically, threat models in which the user must assume that any operator will be coerced or compromised.

1.6 Open source, closed source, and verifiability

Source-code availability is a precondition for several forms of independent verification but is not, by itself, sufficient for "verifiable privacy". The relevant distinctions:

Source available. The operator publishes source code for the client, the server, or both, under a recognised licence. Permissive licences (MIT, BSD, Apache 2.0) allow third parties to inspect, fork, modify, and redistribute the code with few constraints. Copyleft licences (the GNU General Public License family, the GNU Affero General Public License) require that derived works be distributed under the same licence, with corresponding obligations regarding network-served modifications under the AGPL. Source availability allows independent researchers to read the code, run static analysis, build and test independently, and publish findings. Source availability also supports the possibility — but not the actuality — that the binaries the operator ships to users were built from the published source.

Reproducible builds. A build is reproducible when independent parties, starting from the published source, can produce a binary artefact that is bit-identical to the artefact the operator distributes. Reproducible builds turn the question "did this operator ship the code they published?" from a matter of trust into a matter of cryptographic verification. The Reproducible Builds project (reproducible-builds.org) maintains tooling and documentation. Several modern open-source messaging applications publish reproducible-build instructions and metadata. Without reproducible builds, source availability proves only that the operator could have built the binary from the published source, not that they did.

Independent audit. A security audit is an examination of a system by parties other than the system's developers, with results published. Audits vary widely in scope (some cover only a specific protocol component; others cover an entire client implementation), in depth (some are time-boxed at a few engineer-weeks; others extend to formal verification of cryptographic primitives in tools such as ProVerif, CryptoVerif, Tamarin, or hax), in adversary model (some assume a passive observer; others a fully active attacker with access to specific subsystems), and in publication discipline (some audits publish full reports including findings the developer chose not to fix; others publish only summaries). When reading a profile, the relevant questions about an audit are: who conducted it, what was in scope, what was the publication date, what is the published report's URL, and were the report's findings remediated. Many audits cover specific protocol components (key agreement, ratcheting construction, group-message handling) rather than the full deployed system; coverage of a cryptographic component does not by itself imply coverage of an application's user interface, its data-storage layer, or its operational practices.

Supply-chain trust. Source code, reproducible builds, and audits collectively address the question "is this code what it claims to be?". They do not address the question "has the code, the build environment, the dependency tree, the device firmware, the operating system, the application-store distribution channel, the cryptographic libraries, or any of dozens of other components been tampered with?". Modern supply-chain attacks (the SolarWinds compromise of 2020; the XZ Utils backdoor disclosed in 2024-03) have demonstrated repeatedly that compromise can occur at any layer between source code and running binary. Defences against supply-chain compromise include reproducible builds, cryptographic signing of releases, transparency logs (such as the Sigstore ecosystem), runtime attestation, and operator-side controls that lie outside the messaging application itself.

The practical implication for reading a privacy report: source availability, audit history, and reproducible-build status are necessary inputs to a "verifiable privacy" claim but are not sufficient. A platform whose source code is published, has been audited, builds reproducibly, and signs its releases has done substantially more to support independent verification than a platform that has done none of these things. It has not, by virtue of those facts alone, demonstrated that any specific user's specific communications are confidential against any specific adversary. Each profile in this report records what the platform publishes; the act of evaluating those records against a particular threat model remains the reader's.

References cited in this primer:

Bhargavan, K., Beurdouche, B., et al. Messaging Layer Security (MLS) Protocol. RFC 9420. Internet Engineering Task Force, July 2023. https://www.rfc-editor.org/rfc/rfc9420

Edman, M. and Yener, B. On Anonymity in an Electronic Society: A Survey of Anonymous Communication Systems. ACM Computing Surveys, Vol. 42, No. 1, December 2009. DOI: 10.1145/1592451.1592456

Klensin, J. Simple Mail Transfer Protocol. RFC 5321. Internet Engineering Task Force, October 2008. https://www.rfc-editor.org/rfc/rfc5321

Marlinspike, M. and Perrin, T. The Double Ratchet Algorithm. Signal documentation, 2016. https://signal.org/docs/specifications/doubleratchet/

Maymounkov, P. and Mazières, D. Kademlia: A Peer-to-peer Information System Based on the XOR Metric. International Workshop on Peer-to-Peer Systems, 2002.

National Institute of Standards and Technology. Module-Lattice-Based Key-Encapsulation Mechanism Standard. FIPS 203, August 2024. https://csrc.nist.gov/pubs/fips/203/final

Saint-Andre, P. Extensible Messaging and Presence Protocol (XMPP): Core. RFC 6120. Internet Engineering Task Force, March 2011. https://www.rfc-editor.org/rfc/rfc6120

Unger, N., Dechand, S., Bonneau, J., Fahl, S., Perl, H., Goldberg, I., and Smith, M. SoK: Secure Messaging. IEEE Symposium on Security and Privacy, 2015. DOI: 10.1109/SP.2015.22

Electronic Frontier Foundation. Surveillance Self-Defense. https://ssd.eff.org

Reproducible Builds Project. https://reproducible-builds.org

Platform Profiles

The twenty profiles that follow are presented in the grouping established in Appendix A. Within each group, profiles appear in the order published in the brief (§2.1). Each profile follows a uniform template; comparison across platforms is left to the reader.

Mainstream centralized

WhatsApp

Developer / Operator

Company: WhatsApp LLC (US users, Menlo Park, CA); WhatsApp Ireland Limited (European Region users, Dublin, Ireland); wholly owned subsidiary of Meta Platforms, Inc. (Nasdaq: META) HQ jurisdiction: Menlo Park, California, USA (Meta parent; Delaware incorporation); Dublin, Ireland (EU service provider) Ownership structure: Public (Meta Platforms, Inc., Nasdaq: META) per Meta 10-K FY2024 Year founded: 2009 (WhatsApp Inc.); acquired by Facebook/Meta February 2014

Architecture

Type: Centralized client–server Server locations (declared): Per EEA Privacy Policy (updated 2025-03-27), "data centers we rely on … includes the United States" plus additional Meta and third-party provider locations; more granular locations not publicly documented Self-hosting available: No (consumer WhatsApp Messenger)

Code & Transparency

Client source code: Proprietary — https://www.whatsapp.com/download Server source code: Proprietary — [Archive.org snapshot pending] Protocol specification: Public — "WhatsApp Encryption Overview" Technical Whitepaper (Signal Protocol), https://faq.whatsapp.com/820124435853543 and https://www.whatsapp.com/security/WhatsApp-Security-Whitepaper.pdf Transparency report: Published (semiannual) — https://transparency.meta.com/reports/government-data-requests/ ; WhatsApp-specific landing at https://www.whatsapp.com/legal/transparencyreports ; monthly India reports at https://www.whatsapp.com/legal/india-monthly-reports

Encryption

E2E by default: All personal 1:1 chats, group chats, and voice/video calls since 2016, per WhatsApp Security Whitepaper Protocol: Signal Protocol — per Whitepaper: "The Signal Protocol, designed by Open Whisper Systems, is the basis for WhatsApp's end-to-end encryption." Keys on device: Yes — per Whitepaper: "The WhatsApp server has no access to the client's private keys." Last independent audit: Not publicly documented (no named-firm third-party audit of WhatsApp's Signal Protocol implementation published in the 2024-04 → 2026-03 window located)

Identity & registration

Phone number required: Yes — per Terms of Service (accessed 2026-04-20): "you must … provide accurate and complete information … including your mobile phone number" Email required: No Anonymous registration: Not possible

Data retention (per their own Privacy Policy)

Content of messages: Per WhatsApp Security Whitepaper — "We build our Services so that … delivered messages aren't stored"; undelivered messages queued on servers and deleted after 30 days Metadata retained: [US policy, whatsapp.com/legal/privacy-policy, updated per live text accessed 2026-04-20] "We store information for as long as necessary for the purposes identified in this Privacy Policy … The storage periods are determined on a case-by-case basis"; [EU policy, whatsapp.com/legal/privacy-policy-eea, post-DMA 2024, accessed 2026-04-20] materially identical wording plus GDPR Article-6 legal-basis mapping, EU-US Data Privacy Framework declaration, and lead supervisory authority (Irish DPC); Account Information retained "for the lifetime of [the] account" in both Backup handling: Optional E2EE backups (opt-in) layered over iCloud/Google Drive using user-controlled 64-digit key or passphrase; per US Privacy Policy: "if you use a data backup service integrated with our Services (such as iCloud or Google Drive), they will receive information about what you share with them." Identical across regions.

Law enforcement (per their own disclosures)

Most recent transparency report period: H1 2025 (published Q3 2025); H2 2025 not yet published as of 2026-04-20 per transparency.meta.com/reports/integrity-reports-h1-2026/ Government requests received: Meta-wide (all products incl. WhatsApp) — H1 2024: 323,846 (+7.4% vs H2 2023); H2 2024: 322,062 (−0.5%); US H2 2024: 74,672. Per-WhatsApp-only aggregate: Not publicly documented Government requests complied with: Per-country compliance rates published in the interactive dataset; WhatsApp-only aggregate complied-with figure: Not publicly documented Data typically provided: Per WhatsApp "Information for Law Enforcement Authorities" (faq.whatsapp.com/444002211197967) — basic subscriber records (name if provided, service start date, last-seen date, IP addresses, phone number, email if provided); additional account information in emergencies; E2EE content not accessible to WhatsApp

Publicly disclosed incidents (2024-04 → 2026-03)

• 2024-03-07 — Policy change: WhatsApp publishes DMA Reference Offer and third-party interoperability engineering documentation (engineering.fb.com 2024-03-06) [pre-window by ~3 weeks; included as antecedent] • 2025-01-31 — Vulnerability / LE: WhatsApp notifies ~90 users of Paragon "Graphite" zero-click targeting; vector mitigated server-side (CVE-2025-30259) • 2025-05-06 — Law enforcement: US federal jury awards WhatsApp ~$167.25M punitive + $444,719 compensatory damages vs NSO Group (NDCA Pegasus case) • 2025-08-29 — Vulnerability: CVE-2025-55177 (incomplete authorization of linked-device synchronization) chained with Apple CVE-2025-43300; Meta notified <200 users; CISA KEV 2025-09-02 • 2025-11-14 — Policy change: WhatsApp launches DMA third-party chats (BirdyChat, Haiket) in European Region • 2026-Q1 — Policy change: European Commission designates WhatsApp (Channels feature) as VLOP under DSA (reported DSA figures: 46.8M H2 2024; 51.7M H1 2025 monthly recipients) • 2026-02-10 — Law enforcement: CJEU (Case C-97/23 P) rules WhatsApp Ireland's challenge to EDPB Article 65 binding decision admissible; referred back to General Court

Sources

---
---
### Facebook Messenger

#### Developer / Operator
Company: Meta Platforms, Inc. (EU provider: Meta Platforms Ireland Limited)
HQ jurisdiction: 1 Meta Way, Menlo Park, California 94025, USA; Delaware incorporation (Meta 10-K FY2024)
Ownership structure: Public (Nasdaq: META, Class A common stock)
Year founded: Messenger launched 2011, per about.fb.com 2023-12-06 ("the biggest set of improvements to Messenger since it was first launched in 2011")

#### Architecture
Type: Centralized client–server
Server locations (declared): Not publicly documented at Messenger-product granularity; Meta 10-K FY2024 discloses a global data-center footprint without per-app segmentation
Self-hosting available: No

#### Code & Transparency
Client source code: Proprietary (Meta apps); "Code Verify" browser extension for messenger.com integrity is open source — https://github.com/facebookincubator/meta-code-verify
Server source code: Proprietary
Protocol specification: Public — "Messenger End-to-End Encryption Overview" (v1, 2023-12-06) and "The Labyrinth Encrypted Message Storage Protocol" (v1, 2023-12-06), engineering.fb.com/wp-content/uploads/2023/12/
Transparency report: Published (semiannual, account-level) — https://transparency.meta.com/reports/government-data-requests/ ; DSA Article 15/24 transparency report published for Messenger as non-VLOP online platform (transparency.meta.com/reports/regulatory-transparency-reports/)

#### Encryption
E2E by default: Personal 1:1 chats and personal voice/video calls are default E2EE. Per messenger.com/privacy (accessed 2026-04-20): "Personal messages and calls on Messenger will be end-to-end encrypted by default. That means that messages and calls can only be seen or heard by you and the person you send them to, and no one else—not even Meta." Not default E2EE per Meta Help Center: business chats, Marketplace chats, community (Facebook group) chats, Meta AI chats. Group personal chats: "optionally available" in Dec 2023 whitepaper (v1); default status as of 2026-04-20 Not publicly documented in a dated Meta primary source.
Protocol: Signal Protocol (Curve25519 identity keys, X3DH-style initiation, Double Ratchet with AES-256-CBC + HMAC-SHA256) for 1:1 sessions; Noise Protocol Framework (Curve25519, AES-GCM, SHA-256) for client-server channel; Labyrinth for server-side encrypted message storage (AES-GCM-Extended 32-byte key/28-byte nonce; CPace PAKE for multi-device enrollment; PADMÉ padding). Per "Messenger End-to-End Encryption Overview" v1, 2023-12-06.
Keys on device: Yes (Identity Key Pair, Signed Pre Key, One-Time Pre Keys generated at registration; server retains only associated public keys)
Last independent audit: Not publicly documented. Meta's Dec 6 2023 whitepapers are self-published. No named-firm (Cure53, NCC Group, Trail of Bits, Citizen Lab, Project Zero) cryptographic audit of Messenger Labyrinth or the full Messenger E2EE stack located in scope. Key Transparency external auditor: Cloudflare (launched 2025-11-20).

#### Identity & registration
Phone number required: No — Facebook account creation accepts either phone or email
Email required: No — Facebook account creation accepts either phone or email
Anonymous registration: Not permitted under Meta Terms (facebook.com/terms) and Name policy

#### Data retention (per their own Privacy Policy)
Content of messages: E2EE chats — ciphertexts stored on Meta's servers via Labyrinth until user/account deletion; per about.fb.com 2023-12-06 "nobody, including Meta, can see what's sent or said, unless you choose to report a message to us". Non-E2EE chats (business/Marketplace/community/Meta AI) — per Privacy Policy: "Messages that you send and receive, including their content, subject to applicable law. On some Products, you can use end-to-end encrypted messages."
Metadata retained: Participants, timestamps, IP addresses, device info, account identifiers; per-field retention periods Not publicly documented
Backup handling: PIN-based Secure Storage — 6-digit PIN or 40-character recovery code, with optional third-party cloud key storage (iCloud/Google Drive). Per about.fb.com 2023-12-06: "you will be prompted to set up a recovery method, such as a PIN, so you can restore your messages if you lose, change or add a device." User-controlled key; Meta states it cannot decrypt. Opt-out available.

#### Law enforcement (per their own disclosures)
Most recent transparency report period: H1 2025 (published Q3 2025); H2 2025 not yet published per transparency.meta.com/reports/integrity-reports-h1-2026/
Government requests received: Account-level (Facebook/Instagram/WhatsApp/Messenger combined) — H2 2024: 322,062 global (−0.5% vs H1 2024); US H2 2024: 74,672 (−8.8% vs H1 2024); Messenger-only breakout Not publicly documented
Government requests complied with: 76.6% of US H2 2024 requests included non-disclosure orders; 14.1% emergency requests; 21 NSL non-disclosure orders lifted. Messenger-only compliance rate Not publicly documented
Data typically provided: Per Meta Law Enforcement Guidelines — subscriber/registration data, login IPs/timestamps, account metadata; for emergencies, additional account metadata. Content of E2EE 1:1 personal messages not accessible to Meta; metadata (who-to-whom, timestamps, IPs, device) may be produced.

#### Publicly disclosed incidents (2024-04 → 2026-03)
• 2024-03-28 — Policy change: Meta publishes default-E2EE rollout continuation update (about.fb.com, messengernews.fb.com) [pre-window by 4 days; retained as rollout context]
• 2024-11-21 — Transparency report: Meta DSA progress report + first independent DSA audit; Meta Facebook Systemic Risk Assessment 2024 states Messenger excluded from DSA VLOP scope
• 2024-12-17 — Law enforcement: Irish DPC final decision, €251M fine on Meta Platforms Ireland Limited for GDPR Art. 33(3), 33(5), 25(1), 25(2) infringements re: 2018 "View As" token breach affecting 29M accounts globally (~3M EU/EEA); Messenger access tokens tied to the same Facebook account system
• 2025-04-25 — Transparency report: Meta publishes H2 2024 Government Requests report (322,062 global)
• 2025-11-20 — Policy change / audit infrastructure: Meta launches Key Transparency for 1:1 E2EE Messenger chats using the open-source AKD library with Cloudflare as external auditor
• 2026-03-09 — Policy change: Messenger Advanced Browsing Protection technical post (URL-scanning without content exposure)

No NVD/MITRE CVEs specifically for Facebook Messenger in the 2024-04 → 2026-03 window located. A June 2024 Facebook Messenger for Windows path-traversal → RCE was reported via Meta BountyCon (~$111,750 bounty) but without a public NVD CVE ID or Meta primary disclosure; two-of-sources threshold not met — excluded.

#### Sources
- <https://www.sec.gov/Archives/edgar/data/0001326801/000132680125000017/meta-20241231.htm> — live, accessed 2026-04-20
- <https://about.fb.com/news/2023/12/default-end-to-end-encryption-on-messenger/> — live, accessed 2026-04-20
- <https://about.fb.com/news/2024/03/end-to-end-encryption-on-messenger-explained/> — live, accessed 2026-04-20
- <https://engineering.fb.com/wp-content/uploads/2023/12/MessengerEnd-to-EndEncryptionOverview_12-6-2023.pdf> — live, accessed 2026-04-20
- <https://engineering.fb.com/wp-content/uploads/2023/12/TheLabyrinthEncryptedMessageStorageProtocol_12-6-2023.pdf> — live, accessed 2026-04-20
- <https://engineering.fb.com/2023/12/06/security/building-end-to-end-security-for-messenger/> — live, accessed 2026-04-20
- <https://engineering.fb.com/2025/11/20/security/key-transparency-comes-to-messenger/> — live, accessed 2026-04-20
- <https://www.messenger.com/privacy> — live, accessed 2026-04-20
- <https://www.facebook.com/privacy/policy/> — live, accessed 2026-04-20
- <https://transparency.meta.com/reports/government-data-requests/> — live, accessed 2026-04-20
- <https://transparency.meta.com/integrity-reports-q1-2025> — live, accessed 2026-04-20
- <https://transparency.meta.com/reports/integrity-reports-h1-2026/> — live, accessed 2026-04-20
- <https://transparency.meta.com/reports/regulatory-transparency-reports/> — live, accessed 2026-04-20
- <https://about.fb.com/news/2024/11/metas-progress-implementing-the-digital-services-act/> — live, accessed 2026-04-20
- <https://www.dataprotection.ie/en/news-media/press-releases/irish-data-protection-commission-fines-meta-eu251-million> — live, accessed 2026-04-20
- <https://engineering.fb.com/2026/03/09/security/how-advanced-browsing-protection-works-in-messenger/> — live, accessed 2026-04-20
- <https://messengernews.fb.com/2024/03/28/end-to-end-encryption-what-you-need-to-know/> — Archive.org snapshot pending

---

iMessage

Developer / Operator

Company: Apple Inc. HQ jurisdiction: One Apple Park Way, Cupertino, California, USA (Apple 10-K FY2024, filed 2024-11-01) Ownership structure: Public (NASDAQ: AAPL); 15,115,823,000 shares outstanding as of 2024-10-18 (10-K cover) Year founded: iMessage launched 2011, per security.apple.com/blog/imessage-pq3/ ("When iMessage launched in 2011…"); Apple Inc. founded 1976

Architecture

Type: Centralized, proprietary client–server over Apple Push Notification service (APNs); per Apple Platform Security Guide (support.apple.com/guide/security/imessage-security-overview-secd9764312f/web): "Apple iMessage is a messaging service … Relying on the Apple Push Notification service (APNs)…" Server locations (declared): Not publicly documented at iMessage-specific infrastructure level; Apple Platform Security Guide references IDS (Identity Service) and APNs as components without per-jurisdiction data-center declarations Self-hosting available: No (Apple ID / Apple Account required)

Code & Transparency

Client source code: Proprietary (Messages app bundled with iOS/iPadOS/macOS/watchOS/visionOS) Server source code: Proprietary Protocol specification: Partial — descriptive specifications in Apple Platform Security Guide (iMessage chapter) and security.apple.com blog posts on PQ3 and Contact Key Verification; no formal RFC. Academic formal models published at IACR ePrint 2024/357 (Stebila) and 2024/1395 (Basin/Linker/Sasse) Transparency report: Published (biannual) at https://www.apple.com/legal/transparency/ ; most recent period primary-sourced at access date 2026-04-20: H1 2024 (apple.com/legal/transparency/pdf/requests-2024-H1-en.pdf, disclosed 2025-06-04 per secondary reporting). H2 2024 and H1 2025: Not publicly documented at this URL on access date.

Encryption

E2E by default: Yes, for iMessage message content in transit between devices. Per apple.com/legal/privacy/data/en/messages/: "We designed iMessage to use end-to-end encryption, so there's no way for Apple to decrypt the content of your conversations when they are in transit between devices." Protocol: PQ3 hybrid post-quantum protocol. Per security.apple.com/blog/imessage-pq3/ (2024-02-21): "PQ3 … support for PQ3 will start to roll out with the public releases of iOS 17.4, iPadOS 17.4, macOS 14.4, and watchOS 10.4." Combines ML-KEM (Kyber) post-quantum KEM with Elliptic Curve in hybrid initial key establishment and ongoing Signal-style double-ratchet with periodic post-quantum rekey. Prior legacy protocol (iOS 13+): Elliptic Curve Integrated Encryption Scheme (ECIES) + ECDSA, per Apple Platform Security Guide. Keys on device: Yes — per Apple Platform Security Guide: "When a user turns on iMessage on a device, the device generates encryption and signing pairs of keys … The public keys are sent to Apple Identity Service (IDS)." Private keys stored in Secure Enclave per PQ3 blog. Last independent audit: Formal academic verification — Basin/Linker/Sasse (ETH Zürich), "A Formal Analysis of Apple's iMessage PQ3 Protocol," IACR ePrint 2024/1395 (2024-09-05; USENIX Security 2025); companion reductionist proof by Stebila (U. Waterloo), IACR ePrint 2024/357 (Feb 2024). No named commercial penetration-test firm (NCC Group, Trail of Bits, Cure53) iMessage audit publicly documented in window.

Identity & registration

Phone number required: Conditional — per apple.com/legal/privacy/data/en/messages/: "You can sign in to iMessage using your Apple Account, or just your phone number." Email required: Conditional — either a phone number OR an email address (Apple Account) is required Anonymous registration: Not possible (Apple Account required)

Data retention (per Apple's own docs)

Content of messages: "Apple doesn't store message content or attachments" (Platform Security Guide — iMessage security overview). Undelivered messages queued on Apple servers "for up to 30 days" (support.apple.com/guide/security/how-imessage-sends-and-receives-messages-sec70e68c949/web). Encrypted attachments being composed "may be automatically uploaded to Apple while you are composing an iMessage. If your message isn't sent, the attachments are deleted from the server after 30 days" (apple.com/legal/privacy/data/en/messages/). Metadata retained: "Apple retains limited information about the use of iMessage, such as whether your device is eligible to use iMessage, for up to 30 days" (apple.com/legal/privacy/data/en/messages/). IDS registry entries mapping phone/email ↔ device keys ↔ APNs addresses: retention periods Not publicly documented. Backup handling: Two modes per support.apple.com/en-us/102651. Standard Data Protection (default): "When iCloud Backup is enabled, the keys to your backups are secured in Apple data centers. If you use both iCloud Backup and Messages in iCloud, your backup includes a copy of the Messages in iCloud encryption key to help you recover your data" — Apple holds key; producible under lawful process. Advanced Data Protection (opt-in, iOS 16.2+): "iCloud Backup and everything inside it is end-to-end encrypted, including the Messages in iCloud encryption key" — Apple cannot produce. ADP withdrawn for new UK users 2025-02-21 (support.apple.com/en-us/122234).

Law enforcement (per Apple's own disclosures)

Most recent transparency report period: H1 2024 (January 1 – June 30, 2024) — apple.com/legal/transparency/pdf/requests-2024-H1-en.pdf Government requests received: Categories per Apple Transparency Report H1 2024 — Device Requests, Financial Identifier Requests, Account Requests, Account Preservation Requests, Account Restriction/Deletion Requests, Push Token Requests, Emergency Requests, US National Security Requests, US Legal Process Types, US Private Party Requests, Digital Content Provider Requests. Global aggregate totals and per-country figures in the PDF tables. Government requests complied with: Compliance rates vary by category and country per the PDF dataset Data typically provided: Per apple.com/legal/transparency/about.html — for Account Requests, "may also seek customers' content data, such as photos, email, iOS device backups, contacts or calendars." iMessage message content in transit is E2EE and not decryptable by Apple. iCloud Backups under Standard Data Protection may include the Messages in iCloud key and are producible; with ADP enabled, Apple cannot produce Messages in iCloud content.

Publicly disclosed incidents (2024-04 → 2026-03)

• 2024-02-13 — Policy change: European Commission closes DMA Article 17(3) market investigation (Case DMA.100015), iMessage NOT designated as gatekeeper [pre-window; retained as regulatory context] • 2024-02-21 — Policy change: Apple announces PQ3 post-quantum protocol; rollout begins with iOS 17.4 (released 2024-03-05) [pre-window; retained as rollout context] • 2024-04-22 — Law enforcement: Apple files appeal before the EU General Court challenging the Commission's characterisation of iMessage as a NIICS under the DMA (per Digital Policy Alert / Cleary Antitrust Watch; case pending) • 2024-12-31 — Policy change: Apple's stated PQ3 full-rollout target end-of-2024 (per Feb 2024 blog); a separate completion notice was not publicly documented • 2025-01-27 — Vulnerability: iOS 18.3 patches "NICKNAME" imagent use-after-free; iVerify (disclosed 2025-06-05) reports suspected zero-click exploitation on ~6 devices; Apple "strongly disagree[s] with the claims of a targeted attack"; CVE assignment Not publicly documented in retrieved primary sources • 2025-02-21 — Policy change: Apple withdraws Advanced Data Protection for new UK users per support.apple.com/en-us/122234; in-transit iMessage E2EE unaffected • 2025-04-16 — Vulnerability: Apple patches CVE-2025-31200 (CoreAudio memory corruption) and CVE-2025-31201 (RPAC bypass) "exploited in an extremely sophisticated attack against specific targeted individuals"; delivery-vector attribution to iMessage per third-party researcher (seclists.org Full Disclosure 2025-06-09); not confirmed in Apple's advisory • 2025-06-04 — Transparency report: Apple publishes H1 2024 Transparency Report • 2025-08-20 — Vulnerability: Apple patches CVE-2025-43300 (ImageIO out-of-bounds write) "exploited in an extremely sophisticated attack"; ImageIO invoked by multiple apps; iMessage-specific vector Not publicly documented in Apple's advisory; chained with WhatsApp CVE-2025-55177

Sources

---
---
### Google Messages (RCS)

#### Developer / Operator
Company: Google LLC (subsidiary of Alphabet Inc.); EEA service provider: Google Ireland Limited
HQ jurisdiction: Mountain View, California, USA (Google LLC; Delaware incorp.); Dublin, Ireland (Google Ireland Limited, per Google Terms)
Ownership structure: Public (NASDAQ: GOOGL/GOOG via Alphabet Inc., Delaware) — Alphabet 10-K FY2024 Exhibit 21.01, filed 2025-01-31
Year founded: Messages application released 2014; RCS ("chat features") via Google Jibe from 2019; renamed "Google Messages" December 2023

#### Architecture
Type: Federated RCS client with Google-operated centralized backend (Jibe Cloud / Jibe Hub); cross-carrier/cross-provider RCS routed via Jibe Hub; SMS/MMS fallback routed via user's mobile carrier
Server locations (declared): Not publicly documented in Messages-specific docs; Google Privacy Policy states global data-center processing
Self-hosting available: No (Google Messages client is proprietary; Jibe is Google-hosted SaaS for carriers)

#### Code & Transparency
Client source code: Proprietary (Google Messages app via Google Play); AOSP ships a separate minimal reference SMS client
Server source code: Proprietary (Jibe Cloud / Jibe Hub)
Protocol specification: Public — GSMA RCS Universal Profile 3.0 (13 March 2025; MLS-based interoperable E2EE) and 3.1 (25 July 2025; E2EE Subspec 2.0 for file transfer per RCC.07 v16.0); Google Messages E2EE whitepaper (Emad Omara) at https://www.gstatic.com/messages/papers/messages_e2ee.pdf
Transparency report: Published (biannual) — https://transparencyreport.google.com/user-data/overview ; DSA reports at transparencyreport.google.com cover Search/Maps/Play/Shopping/YouTube (Google Messages NOT designated VLOP/VLOSE)

#### Encryption
E2E by default: 1:1 RCS chats between Google Messages users — Yes, since June 2021 stable rollout. Group RCS chats between Google Messages users — Yes, fully rolled out 2023-08-08. Cross-platform RCS (Google ↔ Apple iOS 18 / other RCS clients) — Not E2EE at iOS 18 launch (2024-09-16). Per Google support (support.google.com/messages/answer/9487020, accessed 2026-04-20): "RCS chats with iPhone users don't have end-to-end encryption." GSMA UP 3.0 (March 2025) standardised MLS-based interoperable E2EE; as of 2026-04-20, Google's own support pages still document cross-iPhone RCS as not E2EE, indicating the MLS rollout is in progress. SMS/MMS fallback — NOT E2EE, per support.google.com/messages/answer/10262381: "SMS/MMS messages are not end-to-end encrypted."
Protocol: Signal Protocol (X3DH + Double Ratchet; BoringSSL RAND_bytes for key generation; SHA-512 verification fingerprints) for Google-to-Google RCS per Google's whitepaper; Messaging Layer Security (MLS, RFC 9420) for GSMA UP 3.0/3.1 cross-platform interoperable E2EE (rollout in progress)
Keys on device: Yes — private keys never leave device; public keys uploaded to Google key server per whitepaper
Last independent audit: Not publicly documented for the Google Messages E2EE consumer client. Google's RCS Business Messaging (RBM) infrastructure is annually audited to ISO 27001, SOC 2, SOC 3 per developers.google.com/business-communications/rcs-business-messaging/support/data-security (accessed 2026-04-20).

#### Identity & registration
Phone number required: Yes — RCS is tied to the SIM's phone number
Email required: Not required for SMS/RCS; a Google Account (email- or phone-based) is required for companion features (Messages for web, backup, Key Verifier)
Anonymous registration: Not possible

#### Data retention (per Google's own Privacy Policy & Messages support docs)
Content of messages: RCS E2EE (Google↔Google) — content not accessible to Google; messages temporarily queued on Jibe infrastructure for delivery and deleted after delivery (support.google.com/messages/answer/9592174). RCS non-E2EE (cross-provider/pre-UP 3.0) — TLS in transit only. SMS/MMS — handled by carrier; not E2EE per Google's docs.
Metadata retained: Per support.google.com/messages/answer/9592174: phone number, device identifiers, SIM card number "may be stored for about a month to keep you connected to RCS and in cases where you temporarily go offline." Files (images, videos, GIFs, stickers) stored with "random, unguessable URLs" on Google's RCS infrastructure, temporarily, for delivery.
Backup handling: Messages DB stored on device; Android system backup (Android 9+) encrypted with key derived from user's lock-screen PIN/pattern/passcode so "Google servers can't access it" per Google E2EE whitepaper. Google Drive / Google One backup of SMS history follows Google account backup encryption rules.

— Law enforcement (per Google's disclosures — Google-wide, not Messages-specific)
Most recent transparency report period: H1 2025 (January–June 2025), published Autumn 2025 per transparencyreport.google.com
Government requests received: Google-wide totals available at transparencyreport.google.com/user-data/overview; Google Messages is not broken out. Exact H1 2025 aggregate: Not publicly documented in the specific numeric quote retrieved during this research pass.
Government requests complied with: Disclosure rate published per period in the Transparency Report
Data typically provided: Per policies.google.com/terms/information-requests — subscriber info, non-content records, and (with a warrant, in the US) content. E2EE RCS content cryptographically inaccessible to Google. SMS/MMS content not stored by Google (carrier-handled).

#### Publicly disclosed incidents (2024-04 → 2026-03)
• 2024-09-16 — Policy change: Apple ships iOS 18 with RCS support based on GSMA UP 2.4; cross-platform iPhone↔Android RCS not E2EE at launch
• 2024-09-18 — Policy change: GSMA publicly announces work on interoperable RCS E2EE
• 2024-10-02 — Policy change: Google announces "5 new protections on Google Messages" including Contact Key Verification to launch 2025 (security.googleblog.com)
• 2025-03-13 — Policy change: GSMA publishes RCS Universal Profile 3.0 adding MLS-based E2EE; Google and Apple publicly confirm commitment to implement
• 2025-07-25 — Policy change: GSMA publishes RCS Universal Profile 3.1 extending MLS E2EE to file transfer
• 2025-10-15 — Policy change: Google Messages launches Android System Key Verifier to general availability on Android 10+ (requires Messages app android_20250723.00_p0)
• 2025-12-01 — Vulnerability (platform-level): Android Security Bulletin patches CVE-2025-48633 (Framework info disclosure) and CVE-2025-48572 (Framework EoP); added to CISA KEV 2025-12-02. Not Google Messages app-scoped. No CVE uniquely scoped to com.google.android.apps.messaging located in the 2024-04 → 2026-03 window; Not publicly documented.
• GDPR / Irish DPC / CNIL messaging-relevant finalised decision against Google Messages in window: Not publicly documented (Irish DPC 2024-09-12 inquiry into Google Ireland concerns PaLM 2 AI training, not messaging)

#### Sources
- <https://policies.google.com/privacy> — live, accessed 2026-04-20
- <https://policies.google.com/terms> — live, accessed 2026-04-20
- <https://policies.google.com/terms/information-requests> — live, accessed 2026-04-20
- <https://support.google.com/messages/answer/10262381> — live, accessed 2026-04-20
- <https://support.google.com/messages/answer/9592174> — live, accessed 2026-04-20
- <https://support.google.com/messages/answer/10252671> — live, accessed 2026-04-20
- <https://support.google.com/messages/answer/9487020> — live, accessed 2026-04-20
- <https://www.gstatic.com/messages/papers/messages_e2ee.pdf> — live, accessed 2026-04-20
- <https://jibe.google.com/> — live, accessed 2026-04-20
- <https://docs.jibemobile.com/intro> — live, accessed 2026-04-20
- <https://transparencyreport.google.com/user-data/overview> — live, accessed 2026-04-20
- <https://storage.googleapis.com/transparencyreport/report-downloads/pdf-report-27_2025-1-1_2025-6-30_en_v1.pdf> — live, accessed 2026-04-20
- <https://www.sec.gov/Archives/edgar/data/0001652044/000165204425000014/goog-20241231.htm> — live, accessed 2026-04-20
- <https://www.sec.gov/Archives/edgar/data/0001652044/000165204425000014/googexhibit2101q42024.htm> — live, accessed 2026-04-20
- <https://www.gsma.com/solutions-and-impact/technologies/networks/gsma_resources/gsma-rcs-universal-profile-3-0-specifications/> — live, accessed 2026-04-20
- <https://www.gsma.com/newsroom/article/rcs-encryption-a-leap-towards-secure-and-interoperable-messaging/> — live, accessed 2026-04-20
- <https://security.googleblog.com/2024/10/5-new-protections-on-google-messages.html> — live, accessed 2026-04-20
- <https://www.dataprotection.ie/en/data-protection-commission-publishes-2024-annual-report> — live, accessed 2026-04-20
- <https://source.android.com/docs/security/bulletin/2025-12-01> — live, accessed 2026-04-20
- <https://developers.google.com/business-communications/rcs-business-messaging/support/data-security> — live, accessed 2026-04-20

---

Telegram

Developer / Operator

Company: Telegram Messenger Inc. (operator, per Privacy Policy §1); parent Telegram Group Inc. (British Virgin Islands); group members Telegraph Inc. (BVI) and Telegram FZ-LLC (Dubai, UAE) per Privacy Policy §8.2. EEA representative: European Data Protection Office (EDPO), Brussels HQ jurisdiction: Dubai, UAE (operating entity); British Virgin Islands (parent) Ownership structure: Private Year founded: 2013 (founders Pavel and Nikolai Durov)

Architecture

Type: Centralized, cloud-based; distributed data centers Server locations (declared): For EEA/UK users, data stored in data centers in the Netherlands (Privacy Policy §4.1); "encryption keys in each case are stored in several other data centers in different jurisdictions" (§3.3.1). FAQ: "Cloud chat data is stored in multiple data centers around the globe that are controlled by different legal entities spread across different jurisdictions. The relevant decryption keys are split into parts and are never kept in the same place as the data they protect." Self-hosting available: No

Code & Transparency

Client source code: Partial — clients open source under GPL: github.com/telegramdesktop/tdesktop (Desktop), github.com/DrKLO/Telegram (Android), github.com/TelegramMessenger/Telegram-iOS (iOS). Reproducible builds at https://core.telegram.org/reproducible-builds Server source code: Proprietary Protocol specification: Public — MTProto 2.0 at https://core.telegram.org/mtproto; Secret Chat protocol at https://core.telegram.org/api/end-to-end Transparency report: Partial / Not publicly documented as comprehensive — Telegram does not publish a comprehensive law-enforcement transparency report comparable to Meta/Apple/Google. In-app @transparency bot (https://t.me/transparency) returns per-region quarterly counts per Privacy Policy §8.3. DSA obligations: Telegram self-reports below-45M EU MAU and is not designated VLOP

Encryption

E2E by default: Direct only (Secret Chats — 1:1, device-bound, not cloud-synced). Cloud Chats (default), groups, supergroups, and channels use client-server MTProto 2.0 encryption with keys held across Telegram data centers. Privacy Policy §3.3.1 (Cloud Chats): "All data is stored heavily encrypted and the encryption keys in each case are stored in several other data centers in different jurisdictions." §3.3.2 (Secret Chats): "Secret chats use end-to-end encryption…There is no way for us or anybody else without direct access to your device to learn what content is being sent in those messages. We do not store your secret chats on our servers." Protocol: MTProto 2.0 Keys on device: Partial — device-bound for Secret Chats; split across Telegram data centers for Cloud Chats Last independent audit: Not publicly documented (no commissioned third-party comprehensive audit published; bug bounty operated). Peer-reviewed cryptanalysis: Albrecht/Mareková/Paterson/Stepanovs, "Four Attacks and a Proof for Telegram," IEEE S&P 2022 (https://mtpsym.github.io/paper.pdf; full version J. Cryptology 2025); Albrecht/Mareková/Paterson/Ronen/Stepanovs, "Analysis of the Telegram Key Exchange," EUROCRYPT 2025

Identity & registration

Phone number required: Yes — phone number is the unique identifier (Privacy Policy §3.4). Anonymous numbers available via Fragment platform (blockchain-based, no SIM) Email required: Optional — used for 2FA recovery and (since 2022) login codes Anonymous registration: Possible via Fragment anonymous numbers

Data retention (per their own Privacy Policy)

Content of messages: [Cloud Chats] > "We store messages, photos, videos and documents from your cloud chats on our servers so that you can access your data from any of your devices anytime without having to rely on third-party backups." — Privacy Policy §3.3.1. [Secret Chats] > "We do not store your secret chats on our servers. We also do not keep any logs for messages in secret chats, so after a short period of time we no longer know who or when you messaged via secret chats." — §3.3.2. Metadata retained: > "To improve the security of your account, as well as to prevent spam, abuse, and other violations of our Terms of Service, we may collect metadata such as your IP address, devices and Telegram apps you've used, history of username changes, etc. If collected, this metadata can be kept for 12 months maximum." — Privacy Policy §5.2. Backup handling: Cloud Chats are themselves the server-side backup; keys split across Telegram data centers. Secret Chats have no server-side backup. Default inactive-account self-destruction: 18 months (user-configurable; changed in 2024-09-29 changelog; current configurable range remains). Law-enforcement disclosure clause (§8.3): > "If Telegram receives a valid order from the relevant judicial authorities that confirms you're a suspect in a case involving criminal activities that violate the Telegram Terms of Service, we will perform a legal analysis of the request and may disclose your IP address and phone number to the relevant authorities. If any data is shared, we will include such occurrences in a quarterly transparency report published at: https://t.me/transparency." Global vs EU ToS: [Global ToS, telegram.org/tos] baseline terms; [EU ToS, telegram.org/tos/eu, 2024] EEA-specific variant with EDPO representative designation and jurisdiction-specific provisions. Substantive differences: Not separately verified in this research pass.

Law enforcement (per their own disclosures)

Most recent transparency report period: Per-region counts via @transparency bot; no public comprehensive report in the format used by other platforms — Not publicly documented as a published PDF report Government requests received: Not publicly documented as aggregate figure Government requests complied with (in part or full): Not publicly documented as aggregate figure Data typically provided: IP address and phone number, where disclosed, per §8.3

Publicly disclosed incidents (2024-04 → 2026-03)

• 2024-07-11 (disclosed 2024-07-22): CVE-2024-7014 "EvilVideo" — ESET-discovered logic flaw in Telegram for Android ≤10.14.4 permitting APKs disguised as video files; server-side fix 2024-07-09, client fix in v10.14.5 on 2024-07-11. • 2024-08-24: Pavel Durov detained at Paris-Le Bourget on an arrest warrant issued by a Paris investigating judge; JUNALCO/J3 cybercrime section and OFMIN-coordinated investigation (Communiqué Parquet de Paris 2024-08-26). • 2024-08-26: Paris prosecutor Laure Beccuau communiqué lists 12 preliminary offences including complicity in administering an online platform enabling illicit transactions in organised gang, refusal to communicate information to lawful interception, complicity in distribution of CSAM in organised gang, drug trafficking, organised fraud, criminal conspiracy, organised money laundering, and unlawful provision of cryptology. • 2024-08-28: Mise en examen on all 12 counts; placed under contrôle judiciaire with €5 million bail, twice-weekly police check-ins, and ban on leaving French territory (Communiqué Parquet de Paris 2024-08-28). • 2024-09-23: Telegram Privacy Policy §8.3 substantively updated — narrower "terror suspect only" disclosure clause replaced by disclosure for any "valid order…criminal activities that violate the Telegram Terms of Service" (Privacy Policy §11 changelog). • 2024-09-29: Privacy Policy §10.4 inactive-account default updated. • 2025-03-13 → 2025-03-15: Investigating judge modified contrôle judiciaire; Durov authorised to travel temporarily to Dubai; supervision suspended 2025-03-15 to 2025-04-07 (Paris prosecutor statements to AFP/BBC/France24). • 2025-06-19 (effective 2025-07-10): Paris Court of Appeal further relaxed judicial supervision permitting leave of up to 14 consecutive days to Dubai subject to one-week prior notice; bail retained (AFP via France24). • 2024–2026: European Commission VLOP list does not include Telegram (below-45M EU MAU self-declaration); JRC technical investigation opened August 2024 into user-number methodology; European Parliament Questions E-002762/2024 and E-001293/2025 raised. • 2022–2025: Academic cryptanalysis of MTProto 2.0 (IEEE S&P 2022; EUROCRYPT 2025; ASIACCS 2023) identified symmetric-layer issues patched after coordinated disclosure; key-exchange security proven under non-standard assumptions.

Sources

Discord

Developer / Operator

Company: Discord Inc. (Delaware, USA); Discord Netherlands BV (EEA data controller, Schiphol) HQ jurisdiction: San Francisco, California, USA Ownership structure: Private Year founded: 2015

Architecture

Type: Centralized (client-server) Server locations (declared): Primary United States; "may also store information on servers and equipment in other countries" per Privacy Policy "International data transfers" (Effective 2025-09-29) Self-hosting available: No (core service not self-hostable; not publicly documented as offered)

Code & Transparency

Client source code: Proprietary — not publicly documented as open-sourced Server source code: Proprietary — not publicly documented as open-sourced Protocol specification: Partial — developer API public at https://discord.com/developers/docs/intro; DAVE (voice/video E2EE) protocol public at https://github.com/discord/dave-protocol (v1.1) and https://daveprotocol.com Transparency report: Published — biannual, at https://discord.com/safety-transparency [live, accessed 2026-04-21] (latest periodic file available on hub: H1 2024; DSA 2024 and 2025 reports available)

Encryption

E2E by default: Direct only — voice and video calls only (DAVE), since 2024-09. Text messages, DMs, and server channels are not E2E. Per Privacy Policy: "All information sent within our services is encrypted both in transit and at rest…Voice and video communications on Discord are designed to be end-to-end encrypted." Protocol: DAVE (MLS-based group key exchange, WebRTC encoded transforms, per-sender symmetric media keys, ECDSA identity keys) Keys on device: Yes (per DAVE whitepaper, Discord does not access media keys); cross-device persistent key sync not publicly documented Last independent audit: 2024-09 by Trail of Bits — design review + code review, https://github.com/trailofbits/publications/blob/master/reviews/2024-09-discord-dave-protocol-codereview.pdf

Identity & registration

Phone number required: Optional at signup (email accepted); "you may be required to verify your account or provide…a verified phone number" per Privacy Policy Email required: Yes — contact method required; email or phone accepted Anonymous registration: Not possible (contact method + date of birth required; pseudonymous usernames permitted)

Data retention (per their own Privacy Policy)

Content of messages: > "We retain personal information until we determine it is no longer needed for the processing purposes for which we collected or retain it or for legal compliance." — Privacy Policy, section "Data retention", Effective 2025-09-29. Voice/video call content: > "We generally do not store the contents of video or voice calls or channels." — Privacy Policy, same version. Metadata retained: account info (username, password, email, phone number, birthday, display name); messages and drafts; attachments; custom emojis; server and role info; purchases; IP address; OS and browser info; device settings; log/event data (servers/channels visited); cookies; third-party ad/referral data — per Privacy Policy "The information we collect". Backup handling: Server-side; > "it can take up to 45 days to delete identifying information from backups." — Discord data retention policy, https://support.discord.com/hc/en-us/articles/5431812448791. Inactive accounts may be deleted after two years; public posts may be retained 180 days to two years.

Law enforcement (per their own disclosures)

Most recent transparency report period: H1 2024 (January–June 2024) — the latest periodic biannual file listed on the Transparency Hub as of 2026-04-21; H2 2024, H1 2025, H2 2025 periodic reports: Not publicly documented on hub as of access date Government requests received: 3,782 US legal requests; 545 international legal requests; 539 emergency disclosure requests; 3,235 preservation requests (H1 2024) Government requests complied with (in part or full): 3,223 US (85%); 126 international (23%); 314 emergency (58%); 2,081 preservation valid/actioned (64%) Data typically provided: basic subscriber information, IP connection logs, and message content when validly compelled — per https://discord.com/safety/360044157931-working-with-law-enforcement; each request reviewed for legal validity

Publicly disclosed incidents (2024-04 → 2026-03)

• 2024-04: Third-party "Spy.pet" scraping of ~4 billion messages from ~14,201 public servers; Discord banned affiliated accounts and stated it was "considering appropriate legal action" (404 Media, 2024-04-17; The Register, 2024-04-16). • 2024-09: DAVE protocol launched for voice/video E2EE; Trail of Bits audit published concurrently (https://discord.com/blog/meet-dave-e2ee-for-audio-video). • 2025-08/09: Privacy Policy updated (Last Updated 2025-08-29; Effective 2025-09-29) — sponsored content disclosures, jurisdictional rights, UK OSA age-verification pathway. • 2025-10-03 (updated 2025-10-09): Third-party customer-service vendor compromise; ~70,000 users may have had government-ID photos exposed; data categories included names, Discord usernames, emails, support messages, limited billing metadata, IPs — https://discord.com/press-releases/update-on-security-incident-involving-third-party-customer-service. • 2026-03-01: DAVE enforcement milestone — clients without DAVE support can no longer participate in Discord calls (https://discord.com/blog/bringing-dave-to-all-discord-platforms).

Sources

Snapchat

Developer / Operator

Company: Snap Inc. (Delaware corporation); Snap B.V. (EU representative, Amsterdam) HQ jurisdiction: Santa Monica, California, USA Ownership structure: Public — NYSE: SNAP; SEC CIK 0001564408; IPO March 2017 Year founded: 2011 (predecessor Future Freshman, LLC 2010; incorporated as Snapchat, Inc. 2012; renamed Snap Inc. 2016)

Architecture

Type: Centralized (proprietary cloud service) Server locations (declared): Not publicly documented at granular level in primary Snap documents Self-hosting available: No

Code & Transparency

Client source code: Proprietary Server source code: Proprietary Protocol specification: Proprietary Transparency report: Published — biannual global Transparency Report plus DSA reports; https://values.snap.com/privacy/transparency and https://values.snap.com/privacy/transparency/european-union

Encryption

E2E by default: None for regular Snaps, Chats, or Group chats. Snap does not claim E2E for standard messaging. Per Privacy By Product: "Snaps and Chats are private and delete by default…This means we don't know what you're Chatting or Snapping except in limited, safety-related circumstances." My Eyes Only Memories are "encrypted, and protected behind a password you choose." Protocol: Not publicly documented (no published messaging protocol specification) Keys on device: Not publicly documented (My Eyes Only password-derived; broader messaging not E2E) Last independent audit: E2E audit not applicable. DSA Article 37 Independent Audit Reports published August 2024 and August 2025 at https://values.snap.com/privacy/transparency/european-union

Identity & registration

Phone number required: Yes — account requires name, username, email, birthday, and phone number per Privacy Policy "Information You Provide" Email required: Yes Anonymous registration: Not possible (minimum age 13; verified contact details required)

Data retention (per their own Privacy Policy)

Content of messages: > "As a general rule, we keep information as long as you tell us to, and otherwise as long as we need it to provide our Services, or as required by law. For example, if you store something in Memories, we will keep it as long as you need it, but when you Chat with a friend, our systems are designed to delete Chats you send within 24 hours after your friend reads it (unless you've changed your default settings or decide to save it)." — Privacy Policy, section "How Long We Keep Your Information", Effective 2025-04-07.

"Snapchat servers are designed to automatically delete Snaps that you add to your My Story when the Snap expires (usually 24 hours after posting, but varies depending on your Settings). For public My Stories, we may retain some data about the Snap for up to 30 days…Chats that you send to a Topic Chat are public, and are retained for 5 years." — Snap Support, "When does Snapchat delete Snaps and Chats?", accessed 2026-04-21. My AI: > "All the content you share with My AI is retained until you delete it. These stored interactions help My AI learn and improve over time…It can take up to 30 days to delete the relevant My AI data from Snapchat servers." — Snap Support, https://help.snapchat.com/hc/en-us/articles/15682296562836. Metadata retained: usage information; content metadata (date/time, recipients, viewers); device information (hardware/software, OS, advertising IDs, installed apps, browser, sensors); approximate location via IP; cookies and identifiers; log information — per Privacy Policy "Information We Generate". Backup handling: Not publicly documented as a distinct retention category; Memories retained until user deletes

Law enforcement (per their own disclosures)

Most recent transparency report period: H1 2025 (January–June 2025), released 2025-12-01 Government requests received: 25,449 US requests covering 41,007 accounts (H1 2025); international figures on legal-requests hub page Government requests complied with (in part or full): 81.6% of US requests produced some data (subpoena/summons 82.0%; PRTT 80.0%; court order 86.3%; search warrant 83.8%; emergency disclosure 68.2%; wiretap 100%) Data typically provided: account records; preservation 90 days with one 90-day extension under 18 U.S.C. § 2703(f) — per https://values.snap.com/safety/safety-enforcement

Publicly disclosed incidents (2024-04 → 2026-03)

• 2024-05: UK ICO closed its My AI Article 35/36 DPIA investigation without enforcement action after Snap's fifth revised DPIA accepted (sole controller determination for Snap Inc.). • 2024-09-05: New Mexico AG filed civil complaint against Snap in First Judicial District (Santa Fe County) alleging design features facilitating CSAM and sextortion; Snap motion to dismiss filed 2024-11-21, denied April 2025. • 2024-08 and 2025-08: Snap published DSA Article 37 Independent Audit Reports. • 2025-04-07: Snap Privacy Policy update (current effective version) — includes provisions on AI Features (Inputs/Outputs), Memories, location, My AI. • 2025-04-22: Florida AG James Uthmeier filed suit in Santa Rosa County Circuit Court alleging Snap violated Florida HB 3 (Online Protections for Minors). • 2025-12-01: H1 2025 Global Transparency Report released; EU DSA H1 2025 report cited AMAR of 94.7 million EU users as of 2025-06-30; zero Article 9 orders to act against illegal content received. • Breaches/CVEs: None company-acknowledged and none assigned to Snap/Snapchat vendor in NVD within window — Not publicly documented.

Sources

Viber

Developer / Operator

Company: Viber Media S.à r.l. (Luxembourg), 2 rue du Fossé, L-1536 Luxembourg HQ jurisdiction: Luxembourg (operating/data controller); Tokyo, Japan (parent) Ownership structure: Private subsidiary of Rakuten Group, Inc. (Tokyo Stock Exchange, ticker 4755). Acquired by Rakuten February 2014 (reported $900M; Rakuten IR archival confirmation pending) Year founded: 2010

Architecture

Type: Centralized (phone-number-based, server-mediated relay) Server locations (declared): Not publicly documented at granular level; Privacy Policy references Luxembourg controller and international transfers under Rakuten Binding Corporate Rules Self-hosting available: No

Code & Transparency

Client source code: Proprietary Server source code: Proprietary Protocol specification: Proprietary — "Viber Encryption Overview" whitepaper published at https://www.viber.com/app/uploads/viber-encryption-overview.pdf (Curve-25519 keys; Double-Ratchet-style handshake; SHA-256; HMAC-SHA256; 48-character SAS) Transparency report: Partial — Viber publishes an EU DSA Transparency Report (Article 15) at https://www.viber.com/en/terms/eu-digital-services-act-dsa-transparency-report/. Global non-EEA law-enforcement transparency report: Not publicly documented

Encryption

E2E by default: All 1:1 and group messages and 1:1 audio/video calls. Communities and Channels (public) are not E2E. Per Privacy Policy: "Starting with Viber 6.0, Viber's core features are secured with end-to-end encryption: Viber one-on-one calls, one-on-one messages, group messages, private media sharing and linked devices. This means that the encryption keys are stored only on your devices and no one, not even Viber itself, has access to them." Per Help Center: "Some chats aren't end-to-end encrypted for functionality reasons. For example, Channels and Communities display the entire chat history to new members…These messages are protected by encryption-in-transit." Protocol: Proprietary Viber protocol (Double-Ratchet-inspired) per "Viber Encryption Overview" Keys on device: Yes (per Privacy Policy and Encryption Overview) Last independent audit: Not publicly documented (no commissioned third-party cryptographic audit identified)

Identity & registration

Phone number required: Yes (registration by phone number) Email required: Optional Anonymous registration: Not possible

Data retention (per their own Privacy Policy)

Content of messages: > "We wish to clarify that we do not read or listen to the content of your messages and/or calls made privately via Viber and we do not store those messages (including any media files transferred therein) once they have been delivered to their destination (which on average takes less than one second). If for some reason the message was not delivered to its destination within up to 2 weeks, it will be deleted from our servers." — Privacy Policy, Last Updated 2026-03-23. Metadata retained: > "Activity data, relating to your usage of Services, such as connection status, whether you have received and seen messages sent to you, if you are currently on another call and data related to the calls and messages that you send and receive, such as length of the call, who called who, who messaged who, and at what time." — Privacy Policy, section "Data we collect automatically from your device", Last Updated 2026-03-23. Also: phone number; Identifiers; phone address book where provided; device identifiers; IP; usage metadata. Backup handling: Optional — user-selected external backup. > "We note that we allow you the option to back up your chat history data on your own external data backup service (like iCloud or Google Drive)." — Privacy Policy, Last Updated 2026-03-23. Backup encryption depends on user's iCloud/Google Drive settings; Viber does not document its own E2E backup — Not publicly documented. Rakuten sharing: Privacy Policy describes optional linkage of Viber account to a Rakuten account, with shared usage data for group-service provision; delinking available in-app.

Law enforcement (per their own disclosures)

Most recent transparency report period: DSA EU report covering 2025-02-18 → 2025-12-31 Government requests received: 58 Article 9 illegal-content orders; 254 Article 10 user-information orders (Luxembourg 195, Bulgaria 15, Hungary 13, France 8, Greece 6, Germany 6, Poland 5, Slovenia 4, Italy 1, Lithuania 1) — EEA only Government requests complied with (in part or full): Not broken out by compliance rate in the public DSA report — Not publicly documented Data typically provided: per Viber Law Enforcement page — account records; 90-day preservation plus 90-day extension; disclosure "without compromising our end-to-end encryption" may include activity data, Identifiers, and phone address book

Publicly disclosed incidents (2024-04 → 2026-03)

• 2024-08 → 2025-12: UK ICO Children's Code engagement; Viber implemented requested changes (personalised advertising off by default for under-18s; just-in-time privacy notices; private profiles by default; restricted visibility of child users) per ICO progress updates March 2025 and December 2025. No fine. • 2024-12-13: Russia — Roskomnadzor restricted access to Viber across the Russian Federation, citing the law on information-dissemination organizers (TASS; Interfax; Recorded Future News; BleepingComputer). • 2025 (full-year, EEA): Viber DSA Transparency Report published covering 2025-02-18 → 2025-12-31; 58 Article 9 and 254 Article 10 orders; ~1.38M proactive moderation actions. • 2025-09-12: CVE-2025-55996 — Viber Desktop for Windows ≤25.6.0 HTML Injection via message compose/forward text parameter (CWE-79); NVD; GitHub Advisory GHSA-mr84-m23m-f429. • 2026-03-23: Privacy Policy substantive update — new processing disclosures on biometric data for Dating verification, AI in-chat features, eSIM processing, expanded inference modeling. • Final GDPR DPA decisions against Viber in window: Not publicly documented (CNPD 2024 Annual Report published 2025-09-22 contains no Viber-specific case).

Sources

Regional centralized

WeChat (international) / Weixin (mainland China) — Platform Profile

Batch 3 • Messenger Privacy Report 2026 Q2 • Profile generated 2026-04-21

This profile documents two separate products operated by two separate Tencent Holdings Ltd. (HKEX: 0700.HK) subsidiaries under two separate legal regimes. Per WeChat's own Privacy Policy: "This Privacy Policy does not apply to you if you are a Weixin user. You are a Weixin user if you have … registered by linking a mobile number that uses international dialing code +86 … or contracted with 深圳市腾讯计算机系统有限公司 (Shenzhen Tencent Computer Systems Company Limited) for Weixin." — WeChat Privacy Policy, section "Introduction", as of 2026-04-21 (https://www.wechat.com/en/privacy_policy.html). [Archive: Snapshot pending — no existing Wayback capture verified as of 2026-04-20]

Product identity

  • Platform name: WeChat (intl) / Weixin (微信, CN)
  • Legal entity — WeChat (intl): Tencent International Service Pte. Ltd. (Singapore). EU representative: Tencent International Service Europe B.V., Buitenveldertselaan 1-5, 1082 VA Amsterdam (per WeChat Cookies Policy, https://www.wechat.com/en/cookies_policy.html).
  • Legal entity — Weixin (CN): 深圳市腾讯计算机系统有限公司 / Shenzhen Tencent Computer Systems Company Limited.
  • Ultimate parent: Tencent Holdings Ltd., HKEX-listed 0700.HK. Corporate filings at hkexnews.hk.
  • HQ jurisdiction — WeChat (intl): Singapore; servers located in Singapore and Hong Kong SAR per Privacy Policy.
  • HQ jurisdiction — Weixin (CN): Shenzhen, PRC; subject to PRC Cybersecurity Law (2017), Data Security Law (2021), and Personal Information Protection Law (PIPL, 2021).

Architecture

  • Architecture type: Client–server, closed infrastructure (both products).
  • Data location — WeChat (intl): "Our servers are located in Singapore and the Hong Kong Special Administrative Region ('Hong Kong SAR'). We also have support, engineering and other teams that support the provision of WeChat to you, located around the world (including Singapore and the Netherlands)." — WeChat Privacy Policy, section "Where do we process your data?", as of 2026-04-21. [Archive: Snapshot pending]
  • Data location — Weixin (CN): mainland China, per Weixin Privacy Protection Guidelines (隐私保护指引) — content not retrieved in full in this batch. [Archive: Snapshot pending — weixin.qq.com privacy template]
  • Network encryption: WeChat uses a proprietary protocol MMTLS (MicroMessenger Transport Layer Security), a modified TLS 1.3. Per Citizen Lab's technical analysis of WeChat Android 8.0.21 / 8.0.23 (re-verified on 8.0.49, April 2024) published 2024-10-15, "MMTLS is a modified version of TLS 1.3, with many of the modifications that WeChat developers made to the cryptography introducing weaknesses … such as its use of deterministic IVs and lack of forward secrecy." An inner "Business-layer Encryption" wrapped by MMTLS was found to contain a metadata leak (user account ID and other information unencrypted at that layer). Researchers could not develop an end-to-end attack defeating the overall encryption. (https://citizenlab.ca/2024/10/should-we-chat-too-security-analysis-of-wechats-mmtls-encryption-protocol/) Consistent with earlier research by Citizen Lab (2020, "We Chat, They Watch") and Citizen Lab (2023, "Should We Chat? Privacy in the WeChat Ecosystem", https://citizenlab.ca/2023/06/privacy-in-the-wechat-ecosystem-full-report/).

Encryption and end-to-end status

  • E2E default — WeChat (intl) and Weixin (CN): No. Tencent's help-center disclosures describe client-to-server encryption, not end-to-end. Per WeChat Help Center: "WeChat securely encrypts your sent and received messages between our servers and your device … WeChat uses industry-standard encryption practices and technologies, including specifically the Advanced Encryption Standard (AES) 256" (section "How secure are my chat messages", as of 2026-04-21).
  • Encryption protocol: MMTLS (transport); AES-256 (claimed) for message payload between client and server. No public specification of E2EE for chats.
  • Backup encryption: Chat content not permanently retained on server per policy (see Retention below); local backups handled by device OS. Not publicly documented that local/cloud backups are end-to-end encrypted.

Source code and audits

  • Client source — both: Closed-source. Tencent's GitHub org (github.com/Tencent and github.com/tencent-wechat) hosts infrastructure components (e.g. Mars networking library, mmkv key-value store, libco) but not the WeChat/Weixin consumer client.
  • Server source: Closed-source.
  • Last independent security audit by named firm (2024–2026): Not publicly documented. Citizen Lab's 2024-10-15 MMTLS analysis and 2023-06-28 Mini Programs analysis are independent technical research (not a commissioned audit).

Identifiers and registration

  • Phone required — both: Yes. Per WeChat Privacy Policy section "What information do we collect?": "When you register for a WeChat account, we will need your mobile number and an alias." Account routing is dialling-code-segmented: +86 numbers bind to Weixin; non-+86 numbers bind to WeChat.
  • Email required: Optional.

Retention and metadata

  • Retention — WeChat (intl): "How long we retain information for depends on the type of information — for example, log-in data is retained for up to 90 days from the date the data is collected." — Privacy Policy summary, as of 2026-04-21. Per WeChat Help Center: "Once 72 hours has lapsed since you sent your chat message, or 120 hours for images, audio, videos, and files, WeChat permanently deletes the content of the message on our servers."
  • Retention — Weixin (CN): [Original: Chinese]: "我们会在为你提供微信服务之目的所必需的期间内保留你的个人信息" [Working translation]: "We will retain your personal information for the period necessary for the purpose of providing you with Weixin services." — Weixin 隐私保护指引, section on retention. Exact section text not retrieved in full this batch; cross-verification pending. [Archive: Snapshot pending]
  • Metadata retained: registration data, device attributes, IP/log data, profile data, WeChat ID, contacts/friend lists, location data where permissions granted (per noyb access-request complaint 2025-01 citing WeChat Privacy Policy Annex 3).

Disclosure to authorities and transparency reporting

  • Transparency report: Tencent does not publish a transparency report in the format used by Meta, Apple, or Google. Tencent Holdings' HKEX annual filings (hkexnews.hk, stock code 00700) contain aggregate compliance disclosures. State per brief: "Not publicly documented" in standard transparency-report format.
  • Disclosure clause — WeChat (intl): "We do not share your information with third parties, except where we need to in order to provide the service (e.g., SMS service providers) or if we are instructed to by a court, authority or compelled by law." — Privacy Policy, section "Who do we share your data with?", as of 2026-04-21.
  • Disclosure regime — Weixin (CN): Governed by PRC Cybersecurity Law, Data Security Law, and PIPL; Cyberspace Administration of China (CAC, cac.gov.cn) is primary regulator. 2024-03-22 CAC "Regulations on Promoting and Regulating Cross Border Data Flows" relevant to Weixin-side processing.

Regulatory posture and external findings (24-month window)

  • EU DSA VLOP status: WeChat is not designated a Very Large Online Platform under EU DSA as of 2026-04-01 per the European Commission designations list (https://digital-strategy.ec.europa.eu/en/policies/list-designated-vlops-and-vloses). Tencent publishes DSA contact points (dsa.enquiries@global.tencent.com).
  • USTR Notorious Markets: WeChat e-commerce ecosystem added 2022; removed January 2025 per USTR 2024 Review.
  • US DoD Section 1260H list: Tencent added 2025-01-07; Tencent publicly disputed the listing. Advisory designation only.
  • Self-hosting: Not available (both products).

Notes

Jurisdictional split is architectural and legal, not cosmetic: a Weixin account and a WeChat account cannot interoperate as one identity, and conversion between them requires account migration. Per WeChat Privacy Policy: "If you subsequently change your phone number (either from a Chinese mainland mobile number to a non-Chinese mainland mobile number, or vice versa) you will be required to convert your account." — section "Introduction", as of 2026-04-21.

=== END FILE ===

=== FILE: profiles/line.md ===

LINE — Platform Profile

Batch 3 • Messenger Privacy Report 2026 Q2 • Profile generated 2026-04-21

Product identity

  • Platform name: LINE
  • Legal entity: LY Corporation (LINEヤフー株式会社). Formed via Z Holdings + Yahoo Japan + LINE Corporation consolidation; Z Holdings created from the 2021 merger of LINE Corp and Yahoo Japan; further consolidated into LY Corporation effective 2023-10-01.
  • Ownership: A Holdings (SoftBank + Naver joint venture).
  • Korean subsidiary: LINE Plus Corporation (handles some international operations from South Korea).
  • HQ country: Japan.
  • CEO (at 2026-04-21): Takeshi Idezawa (出澤 剛).
  • Reported scale: ~98 million Japan MAU per LY Corp Media Guide (late March 2025).

Architecture

  • Architecture type: Client–server, closed infrastructure. Proprietary transport protocol "LEGY" (LINE Event-delivery GatewaY), migrating to TLS 1.2 / TLS 1.3 (DHE/ECDHE) as default.
  • Data location: Japan (primary). Third-party cloud backups (iCloud/Google Drive) store plaintext backups outside LINE's E2EE envelope per LINE's own disclosure.
  • Transparency URL: https://www.lycorp.co.jp/en/privacy-security/privacy/transparency/ . [Archive: Snapshot pending — no existing Wayback capture verified as of 2026-04-20]

Encryption and end-to-end status

  • E2E default: Yes for 1-to-1 and group (≤50 members) text/location messages; 1-to-1 audio/video calls. Since 2021, "Letter Sealing" cannot be manually disabled for supported features. Group calls, group video calls, and LINE Meeting use transport-level encryption only (not E2EE). Media E2EE (images, voice, video, files) rolled out beginning November 2023; per LY Corp announcements, transparent enablement for all users worldwide completed by November 2024, conditional on all chat participants running compatible LINE versions.
  • Protocol — "Letter Sealing": ECDH over Curve25519 for message key exchange (secp256r1 for VoIP); AES-GCM (16-byte tag) for message encryption; HKDF for derivation; SRTP (AES_CM_128_HMAC_SHA1_80) for voice/video. Documented in LINE Encryption Whitepaper v2.2 (December 2025), https://www.lycorp.co.jp/en/privacy-security/line-encryption-whitepaper-ver2.2.pdf . [Archive: Snapshot pending]
  • Protocol history: Letter Sealing v1 released August 2015 (optional), default 2016. v2 deployed October 2019 following Bug-Bounty disclosures by Takanori Isobe (University of Hyogo) and Kazuhiko Minematsu (NEC) identifying protocol-level forgery/impersonation risks. v2 co-developed with the researchers; the original attacks were not practically feasible due to server-side checks.
  • Metadata: sender/recipient IDs, key IDs, version, content type are authenticated (AEAD associated data) but not encrypted — server-visible and disclosable under warrant (per LINE's own documentation).
  • Backup encryption: "Backup PIN" uses client-side encryption plus Intel SGX server-side protection. "LY Premium Backup" — launched June 2025 — provides SGX-based E2EE chat backup authenticated via LINE password, available only to LY Premium subscribers (Japan/Taiwan/Thailand). Third-party iCloud/Google Drive backups are not E2EE — LINE explicitly discloses this.

Source code and audits

  • Client source: Closed. github.com/line hosts SDKs and infra (Armeria, line-bot-sdk- in multiple languages, Promgen, ABC User Feedback) but not the LINE client*.
  • Server source: Closed.
  • Certifications: ISO/IEC 27001 since 2007; SOC 2 and SOC 3 (SysTrust) for LINE App; LINE Pay PCI DSS Level 1. (https://linecorp.com/en/security/article/39, [Archive: Snapshot pending].)
  • Last independent audit by named firm (2024–2026) specific to E2EE: Not publicly documented — no Trail of Bits / NCC Group / Cure53 / Quarkslab audit of Letter Sealing located in public channels as of 2026-04-21.

Identifiers and registration

  • Phone required: Yes (mandatory for account).
  • Email required: Optional.
  • Self-hosting: No.

Retention and metadata

  • Retention: Tied to active accounts; retained post-termination "as reasonably necessary" for legal compliance, dispute resolution, fraud detection — per LY Corporation Privacy Policy at https://terms.line.me/line_rules (section on retention). [Archive: Snapshot pending]
  • Collected items: phone number (mandatory), optional email/profile, device info, IP, usage history, purchase history, opt-in location.
  • Server-side processing (metadata/content visible server-side): read-receipt signals, URL previews (LINE server fetches URL on user's behalf), sticker-suggestion (federated-learning + differential privacy since migration), pinned announcement messages and polls (sent to server to serve new group members).

Transparency report

LY Corporation publishes a semi-annual Transparency Report for the LINE service at https://www.lycorp.co.jp/en/privacy-security/privacy/transparency/reports/ . Latest and prior period (per LY Corporation disclosures accessed 2026-04-21):

Period Investigation inquiries Warrants Emergency (suicide risk) Emergency (other) Disclosure rate
2024 H1 3 2,578 (JP 1,745 / TW 815 / KR 18) 63 23 98.01%
2024 H2 41 3,545 52 19 98.7%
2025 H1 (published 2025-12-22) 481 3,174 65 21 95.7%

Delta 2025 H1 vs 2024 H2: warrants −371 (−10.5%); investigation inquiries +440; disclosure rate −3.0 pp. Taiwan warrants 953 (+88 vs prior), disclosure rate 99.69%.

Regulatory actions (24-month window)

  • 2024-03-05 — MIC Administrative Guidance #1 (Ministry of Internal Affairs and Communications, 総務省). Following Naver Cloud third-party access disclosure (November 2023; ~520,000 records including ~300,000 user records). MIC found breach of "secrecy of communications" under Article 4(1) of Telecommunications Business Act. (soumu.go.jp press release 01kiban18_01000224, [Archive: Snapshot pending].)
  • 2024-03-28 — PIPC (個人情報保護委員会) Recommendation under Article 148(1) APPI; required quarterly reports through March 2025. (ppc.go.jp/news/press/2024/240328/, [Archive: Snapshot pending].)
  • 2024-04-16 — MIC Administrative Guidance #2. MIC judged the April 1 report insufficient, particularly regarding the capital relationship with Naver. (soumu.go.jp press release 01kiban18_01000230.)
  • 2025-03-28 — MIC Administrative Guidance regarding "LINE Albums" thumbnail leak (2024-11-28) that affected ~70,000 domestic / ~135,000 total users; MIC ruled a breach of secrecy of communications.
  • Naver decoupling timeline (per LY Corporation 2025-03-31 report): outsourcing Type ① to end by end-December 2025; Type ② (technology/system use) to end by end-March 2026; residual data deletion by end-June 2026.
  • EU DSA VLOP status: LINE is not designated as VLOP under EU DSA as of 2026-04-01; primary user base in Japan/Taiwan/Thailand/Indonesia.

Notes

LY Corp publicly states it does not support wiretapping or censorship and discloses only where legally obligated or under strict emergency criteria. Notable 2025 incidents include a LINE Official Account CDN-related misdisplay (discovered September–December 2025) and a published notice (2025-12-22) regarding an issue with the data-disclosure process to Taiwanese law enforcement. The LINE Security Bug Bounty Program was temporarily suspended 2025-12-03 following a reporter's verification activity that breached program rules.

=== END FILE ===

=== FILE: profiles/kakaotalk.md ===

KakaoTalk — Platform Profile

Batch 3 • Messenger Privacy Report 2026 Q2 • Profile generated 2026-04-21

Product identity

  • Platform name: KakaoTalk (카카오톡)
  • Legal entity: Kakao Corp. (주식회사 카카오). KOSPI-listed, ticker 035720. Filings via DART, https://dart.fss.or.kr .
  • HQ country: Republic of Korea (Jeju-do; operational HQ Pangyo/Seongnam).
  • CEO (at 2026-04-21): Shina Chung (정신아), since 2024.
  • Regulatory framework: Korean Personal Information Protection Act (PIPA). Not GDPR-primary (GDPR applies only to EU-offered services).
  • Reported scale: installed on >95% of Korean smartphones; ~46–54M MAU (per Kakao IR and third-party estimates).

Architecture

  • Architecture type: Client–server, multi-DC (Ansan + Siheung + leased capacity). Current multi-DC architecture follows the 2022-10-15 SK C&C Pangyo data center outage that affected Kakao services (Kakao's post-mortem: https://tech.kakao.com/ — "우리가 부족했던 이유" / "우리의 재발 방지 계획", if(kakao) 2022 keynotes; [Archive: Snapshot pending — no existing Wayback capture verified as of 2026-04-20]). Kakao's Ansan hyperscale DC became operational Q1 2024 (KRW ~460 bn capex; up to 120,000 servers, 6 EB storage); Siheung DC groundbreaking 2024.
  • Transport protocol: LOCO (proprietary).
  • Data location: South Korea (primary).

Encryption and end-to-end status

  • E2E default: No for standard chats. Secret Chat provides E2EE but is opt-in only, originally introduced 2014-12 (Android), later iOS; initially 1-to-1, later extended to group. In Secret Chat rooms, decryption keys are stored only on user devices; free calls, polls, events, and chatroom album are unavailable in Secret Chat mode. Kakao Work Chat offers E2EE separately.
  • Protocol: Kakao does not publish a full E2EE whitepaper comparable to Signal or LINE. Third-party academic and independent analyses (Jong et al. "Secret Chat" reviews; diva-portal theses; stulle123.github.io) describe long-lived RSA keypairs stored client-side (TalkKeyStore / KakaoTalk.db on Android) and note that the LOCO protocol does not provide a standard HTTPS-equivalent server-authenticated channel for the messaging backend. This is third-party research, not a Kakao publication.
  • Backup encryption: Not publicly documented as E2EE. Historical reused-key issue in KakaoTalk Android backups (academic research, ScienceDirect 2022) addressed in KakaoTalk Android ≥ v9.0.

Source code and audits

  • Client source: Closed. github.com/kakao hosts ~71 repositories, largely SDKs and infra tools. No official open-source KakaoTalk client; community-reverse-engineered projects (KiwiTalk, node-kakao) are unofficial.
  • Server source: Closed.
  • Certifications: ISMS-P, ISO/IEC 27001, 27701, 27017 (per Kakao Reliability Report 2024). Kakao's Privacy Policy states: "Kakao is verified annually by an independent auditing organization to ensure that we meet national and international certification standards on information protection and privacy management." — Kakao Privacy Policy, section "Information Protection Certifications", Amendment Notice Date 2026-04-03 (https://www.kakao.com/policy/privacy?lang=en, [Archive: Snapshot pending]).
  • Last independent audit by named non-certification firm (Trail of Bits / NCC / Cure53 etc.) 2024–2026: Not publicly documented.

Identifiers and registration

  • Phone required: Yes.
  • Email required: Optional (used for Kakao Account).
  • Self-hosting: No.

Retention and metadata

Per Kakao Privacy Policy (as of 2026-04-03 amendment; effective 2026): - Withdrawal-related data destroyed within 1 year. - Rights-infringement reports retained 5 years. - KakaoTalk phone numbers used for re-registration blocks retained 60 days. - Connecting Information (CI) retained 1 year (5 years for minor-sexual-crime violations). - Kakao Certificate usage history retained 5 years after discontinuation. - Disclosure stance: "Kakao does not provide personal information to any third party without your consent or unless demanded by applicable laws." — Kakao Privacy Policy, section "Provision of Personal Information", as of 2026-04-21. - Wiretap stance: Since October 2016, Kakao does not cooperate with real-time wiretapping (통신제한조치) under the Communications Secrets Protection Act, citing Supreme Court 2016도8137. Communication User Information (name, RRN, address, phone, ID, subscription dates) requests declined following Constitutional Court 2010헌마439.

Transparency report

Kakao publishes a bi-annual Transparency Report at https://privacy.kakao.com/transparency and https://privacy.kakao.com/transparency/report?lang=en . Report covers: communication-restricting measures, communication confirmation data, warrants of seizure/search, and (since the Constitutional Court ruling) communication user information requests declined. Latest file identified: 2h_2025_kakao_transparency_report_kor.xlsx (covering 2H 2024 / early-2025 disclosures). [Archive: Snapshot pending]

Delta: Specific numeric period-over-period delta values require spreadsheet parsing not completed in this batch; flagged for batch-archival verification. Directional indicator from Kakao's own commentary: warrant volumes trending upward alongside PIPC breach-notification enforcement in 2024–2025.

Regulatory actions (24-month window)

  • 2024-05-23 — PIPC fine KRW 15.14 bn (~US$11M) for KakaoTalk Open Chat ID-exposure matter; at the time the largest PIPC fine against a Korean company. Root cause: shared membership serial numbers between regular and Open Chat; unencrypted pre-Aug-2020 temporary IDs; decryption endpoint on Open Chat bulletin-board. Confirmed ≥65,710 users affected. Kakao filed administrative suit November 2024.
  • 2025-01-23 — PIPC fines Kakao Pay KRW 5.968 bn and Apple KRW 2.45 bn over 2018–2024 cross-border transfer of data to Alipay (Singapore) for NSF-score modelling. Corrective order required Alipay to delete the NSF-score model — a globally unusual "model deletion" remedy.
  • 2026-01-15 — Seoul Administrative Court upheld PIPC's 2024-05-23 fine on the Open Chat matter, finding failure to notify authorities and users unlawful.
  • CVE-2023-51219 — disclosed via Kakao Bug Bounty December 2023; public June 2024. 1-click exploit in KakaoTalk Android v10.4.3 via CommerceBuyActivity WebView deep-link validation flaw combined with stored XSS on m.shoppinghow.kakao.com; enabled Authorization-token exfiltration. Patched May 2024; CVSS 6.5.
  • 2024–2025 — Konni/APT37-linked campaign abusing KakaoTalk PC sessions alongside Google Find Hub accounts (named security research: Genians).
  • EU DSA VLOP status: Not designated under EU DSA as of 2026-04-01. Kakao's EU user base is below threshold.

Notes

Ranking Digital Rights 2025 Big Tech Edition (reviewed 2025-03-20) rated Kakao highest among non-US platforms overall while flagging KakaoTalk as the least transparent major messenger on privacy indicators specifically, citing shared membership numbers across private/open chats and breach-notification practices — context, not evaluation. Kakao disputes the characterization of membership serial numbers and Kakao Pay transfers as "personal information leakage"; related litigation remains active.

=== END FILE ===

=== FILE: csv-rows-batch3.md ===

Privacy-focused centralized

Signal

— Developer / Operator

  • Company: Signal Messenger, LLC (wholly-owned by Signal Technology Foundation). Signal Technology Foundation is a Delaware 501(c)(3), EIN 82-4506840, tax-exempt since 2019-02.
  • HQ jurisdiction: Mountain View, California, United States
  • Ownership structure: Foundation (501(c)(3) nonprofit)
  • Year founded: Signal app released 2014 (Open Whisper Systems); Signal Technology Foundation established 2018

— Architecture

  • Type: Centralized
  • Server locations (declared): Not publicly documented in current Privacy Policy
  • Self-hosting available: No (not offered by the operator)

— Code & Transparency

  • Client source code: Public — https://github.com/signalapp
  • Server source code: Public — https://github.com/signalapp/Signal-Server
  • Protocol specification: Public — https://signal.org/docs/
  • Transparency report: Published — aperiodic release of subpoena transcripts at https://signal.org/bigbrother/ (as of 2026-04, multiple transcripts covering EDVA 2016, CDCA 2021, Santa Clara County warrant, D.C. grand-jury subpoena). No periodic numerical report.

— Encryption

  • E2E by default: All chats
  • Protocol: Signal Protocol with Double Ratchet; PQXDH initial key agreement (X25519 hybridized with ML-KEM-768, deployed 2023-09-19); SPQR (Sparse Post-Quantum Ratchet) combined with Double Ratchet as "Triple Ratchet" (deployed 2025-10-02)
  • Keys on device: Yes
  • Last independent audit: No commercial third-party application audit publicly disclosed. Most recent peer-reviewed cryptographic analysis: Bhargavan, Jacomme, Kiefer, Schmidt — machine-checked ProVerif/CryptoVerif proof of PQXDH, 2023-10-20 (https://eprint.iacr.org/2023/1738). SPQR peer-reviewed at Eurocrypt 2025 and USENIX Security 2025.

— Identity & registration

  • Phone number required: Yes (account anchor; usernames since 2024 allow chat initiation without exposing the number but phone number remains bound to account)
  • Email required: No
  • Anonymous registration: Not possible

— Data retention (per their own Privacy Policy)

  • Content of messages: Per Signal's Privacy Policy (as of 2026-04-21): "Signal messages and calls cannot be accessed by us or other third parties because they are always end-to-end encrypted, private, and secure."
  • Metadata retained: Per signal.org/bigbrother (as of 2026-04-21): "the only information we can produce in response to a request like this is the date and time a user registered with Signal and the last date of a user's connectivity to the Signal service."
  • Backup handling: Opt-in "Signal Secure Backups" (Android beta launched 2025-09-08; iOS launched 2025-11). End-to-end encrypted with a 64-character recovery key generated on device and never shared with Signal servers. No other cloud backup offered by Signal. Android on-device local backup available.

— Law enforcement (per their own disclosures)

  • Most recent transparency report period: No periodic numerical report published. Latest published subpoena transcript (as of 2026-04-21): District of Columbia grand-jury subpoena, partially unsealed late 2025 via ACLU counsel — covered 37 phone numbers, of which 7 did not exist and 24 had no responsive information on Signal's servers.
  • Government requests received: Not publicly reported as aggregate number
  • Government requests complied with (in part or full): Not publicly reported as aggregate number
  • Data typically provided: Account creation date and last-connectivity date only, per signal.org/bigbrother

— Publicly disclosed incidents (2024-04 → 2026-03)

  • 2024-02-20 — Usernames feature launched in Android beta; full rollout (iOS + Android GA) 2024-03-05. Source: https://signal.org/blog/phone-number-privacy-usernames
  • 2025-09-08 — Signal Secure Backups Android beta launched (opt-in, E2E, 64-char recovery key; free tier 100 MiB + last 45 days of media; paid US$1.99/month for up to 100 GB). Source: https://signal.org/blog/introducing-secure-backups
  • 2025-10-02 — SPQR (Sparse Post-Quantum Ratchet) publicly released and combined with Double Ratchet as "Triple Ratchet". Source: https://signal.org/blog/spqr
  • Late 2025 (specific date not public) — District of Columbia grand-jury non-disclosure order partially unsealed via ACLU counsel. Source: https://signal.org/bigbrother

— Sources

  • Privacy Policy — https://signal.org/legal/ (accessed 2026-04-21)
  • Terms of Service — https://signal.org/legal/ (accessed 2026-04-21)
  • Government Communication ("Big Brother") — https://signal.org/bigbrother/ (accessed 2026-04-21)
  • Protocol documentation — https://signal.org/docs/ (accessed 2026-04-21)
  • Source repositories — https://github.com/signalapp (accessed 2026-04-21)
  • IRS Form 990, Signal Technology Foundation, FY2024, filed 2025-09-19 — https://projects.propublica.org/nonprofits/organizations/824506840 (accessed 2026-04-21)
  • PQXDH announcement — https://signal.org/blog/pqxdh (2023-09-19)
  • SPQR announcement — https://signal.org/blog/spqr (2025-10-02)
  • Usernames announcement — https://signal.org/blog/phone-number-privacy-usernames (2024-02-20)
  • Secure Backups announcement — https://signal.org/blog/introducing-secure-backups (2025-09-08)
  • Bhargavan et al., PQXDH formal analysis — https://eprint.iacr.org/2023/1738 (2023-10-20)

Wire

— Developer / Operator

  • Company: Wire Swiss GmbH (Zefix UID CHE-432.881.146)
  • HQ jurisdiction: Untermüli 9, 6300 Zug, Canton Zug, Switzerland
  • Ownership structure: Private limited company (GmbH)
  • Year founded: 2012-10-24 (Zefix registration date); Wire app launched 2014-12-03

— Architecture

  • Type: Centralized (optional federation on roadmap per wire-server README)
  • Server locations (declared): Germany and Ireland per Wire's own documentation (corporate domicile Switzerland)
  • Self-hosting available: Yes — wire-server is released as Kubernetes Helm charts at https://github.com/wireapp/wire-server and https://github.com/wireapp/wire-server-deploy

— Code & Transparency

  • Client source code: Public — https://github.com/wireapp
  • Server source code: Public — https://github.com/wireapp/wire-server (AGPLv3)
  • Protocol specification: Public — IETF RFC 9420 (MLS, published 2023-07-19); Proteus (legacy, based on Signal Protocol) at https://github.com/wireapp/proteus
  • Transparency report: Published as a legal-framework statement at https://wire.com/en/transparency-report — no numerical data on request volumes or compliance rates disclosed as of 2026-04-21

— Encryption

  • E2E by default: All chats (messages and calls)
  • Protocol: Messaging Layer Security (MLS, RFC 9420) — general availability 2024; Wire's prior Proteus protocol remains in use during migration. Voice/video encrypted with DTLS-SRTP.
  • Keys on device: Yes for messages and calls. Wire Drive file assets are encrypted at rest with server-side keys, not client-side E2EE; Wire's DPA states: "Wire may technically access Drive Content where reasonably necessary to provide, maintain, secure, and support the Wire Drive functionality."
  • Last independent audit: Kudelski Security + X41 D-Sec audit of Proteus (2017-02-08); application-level audit 2018. No publicly released third-party audit of Wire's MLS implementation as of 2026-04-21. Academic MLS analysis: Alwen, Coretti, Dodis, "Security Analysis and Improvements for the IETF MLS Standard for Group Messaging", CRYPTO 2020 — applies to MLS as a standard, not Wire's specific implementation.

— Identity & registration

  • Phone number required: Optional — registration accepts phone number OR email address (email-only registration possible via https://app.wire.com)
  • Email required: Optional — alternative to phone
  • Anonymous registration: Not possible (one of phone/email required; Wire Pro/Enterprise uses work email)

— Data retention (per their own Privacy Policy)

  • Content of messages: Per Wire's Privacy Policy (as of 2026-04-21): "Encrypted messages are temporarily stored on Wire's servers for delivery when users come back online. However, this data is immediately deleted from Wire's servers as soon as the relevant message has been delivered to the recipient of the message."
  • Metadata retained: Not publicly documented as an itemized list in current Privacy Policy
  • Backup handling: Not publicly documented for consumer clients. Wire Drive (enterprise file storage) stored with server-side encryption per DPA.

— Law enforcement (per their own disclosures)

  • Most recent transparency report period: Not publicly documented (Wire's transparency statement describes legal framework only, no period-bounded numbers)
  • Government requests received: Not publicly documented (not disclosed numerically)
  • Government requests complied with (in part or full): Not publicly documented
  • Data typically provided: Per Wire's transparency statement, Swiss legal basis is Articles 22(3) and 27 BÜPF; requests must be submitted via Post- und Fernmeldeverkehr Überwachung (PTSS). Specific data categories produced not publicly enumerated.

— Publicly disclosed incidents (2024-04 → 2026-03)

  • 2024 (specific date not in Wire's own timeline) — MLS (RFC 9420) general availability in production Wire clients. Source: https://wire.com/en/blog/wire-mls-is-now-generally-available
  • 2024–2025 — Gradual Proteus-to-MLS migration across Wire user base per Wire's release notes
  • 2025 (specific date not publicly disclosed in press releases reviewed) — Wire announced €24M funding round. Source: Wire communications / press coverage; primary-source URL not in scope of this reformat.
  • 2025-02-13 — Most recent SHAB notice for Wire Swiss GmbH (23rd notice since incorporation)

— Sources

  • Privacy Policy — https://wire.com/en/privacy-policy/ (accessed 2026-04-21)
  • Terms of Service — https://wire.com/en/legal/ (accessed 2026-04-21)
  • Transparency statement — https://wire.com/en/transparency-report (accessed 2026-04-21)
  • Data Processing Addendum — https://wire.com/en/legal/ (accessed 2026-04-21)
  • Security whitepapers — https://wire.com/en/security/ (accessed 2026-04-21)
  • Source code — https://github.com/wireapp (accessed 2026-04-21)
  • Self-hosting docs — https://github.com/wireapp/wire-server-deploy (accessed 2026-04-21)
  • Zefix entry (Wire Swiss GmbH, UID CHE-432.881.146) — https://www.zefix.ch (accessed 2026-04-21)
  • SHAB register — https://www.shab.ch (accessed 2026-04-21)
  • MLS standard — https://datatracker.ietf.org/doc/rfc9420/ (2023-07-19)
  • MLS GA announcement — https://wire.com/en/blog/wire-mls-is-now-generally-available
  • Kudelski Security / X41 D-Sec Proteus audit — https://wire.com/downloads/Kudelski_X41_Wire_Security_Review.pdf (2017-02-08)
  • Alwen, Coretti, Dodis — CRYPTO 2020, DOI 10.1007/978-3-030-56784-2_9

Threema

— Developer / Operator

  • Company: Threema GmbH (Zefix UID CHE-221.440.104); parent entity Threema Holding AG (UID CHE-487.082.806). CEO Robin Simon; Geschäftsführer Danilo Bargen.
  • HQ jurisdiction: Churerstrasse 82, 8808 Pfäffikon SZ, Canton Schwyz, Switzerland
  • Ownership structure: Private limited company (GmbH). Threema Holding AG was acquired in 2026-01 by Comitis Capital GmbH (Frankfurt am Main) from Afinum Management GmbH (Munich, held since 2020 autumn).
  • Year founded: Threema app launched 2012; Threema GmbH registered 2014-03-12

— Architecture

  • Type: Centralized
  • Server locations (declared): Switzerland only, per Threema's own documentation
  • Self-hosting available: Yes for commercial customers via Threema OnPrem (paid license; Linux + Docker deployment). Threema Web is open source and self-hostable (https://github.com/threema-ch/threema-web). Threema server daemons for the consumer service are proprietary.

— Code & Transparency

  • Client source code: Public — https://github.com/threema-ch (Android, iOS, Desktop, Web) under GNU AGPLv3; reproducible builds available for Android
  • Server source code: Proprietary (server daemons for Threema's hosted consumer service are not published; Threema OnPrem licenses include installation packages under commercial terms)
  • Protocol specification: Public — Ibex end-to-end protocol described at https://threema.com/en/blog and in formal-verification paper by University of Erlangen-Nuremberg, Chair of Applied Cryptography (published 2023-07); Threema Gateway SDK open source
  • Transparency report: Published annually — https://threema.com/en/transparency-report (most recent update 2025-12-31 covering calendar year 2025)

— Encryption

  • E2E by default: All chats
  • Protocol: Ibex (announced 2022-11-29 with Threema 5.0). Previously NaCl-based ECC. Perfect forward secrecy on end-to-end layer per formal proof by Univ. of Erlangen-Nuremberg (2023-07). Post-quantum upgrade via ML-KEM announced 2026-03-10 in collaboration with IBM Research.
  • Keys on device: Yes (key pair generated on device during initial setup; public key sent to server, private key remains on device)
  • Last independent audit: Cure53 audit of Threema Desktop, published 2024-01 (https://cure53.de/pentest-report_threema-desktop.pdf). Prior Cure53 audits: 2020 (apps + server), 2022-02 (Rust crypto libraries). cnlab audit 2015-08.

— Identity & registration

  • Phone number required: No (optional for contact discovery; stored only as salted hash if linked)
  • Email required: No (optional for contact discovery; stored only as salted hash if linked)
  • Anonymous registration: Possible — account identity is an 8-character randomly generated Threema ID; one-time purchase payable via app store or anonymously with cash/Bitcoin per Threema Shop

— Data retention (per their own Privacy Policy)

  • Content of messages: Per Threema Privacy page (as of 2026-04-21): "messages are deleted from our servers immediately after delivery, connection information is not logged, and group memberships remain solely on your devices." Hard 14-day delivery cutoff after which undelivered messages are removed.
  • Metadata retained: Per Threema's Privacy Policy: Threema ID creation date (without time); Threema ID last-login date (without time); salted hashes of linked phone/email if the user opted to link them. Connection information not logged. Contact-list synchronization uses hashes that are not stored.
  • Backup handling: Local encrypted backups (device-side). Threema Safe — optional encrypted cloud backup of Threema ID + contacts (no messages) with user-chosen password; user can self-host the Threema Safe server.

— Law enforcement (per their own disclosures)

  • Most recent transparency report period: Calendar year 2025 (report updated 2025-12-31)
  • Government requests received: 423 in 2025 (up from 306 in 2024 and 177 in 2023)
  • Government requests complied with (in part or full): 422 in 2025; data actually produced in 402 cases covering 1,505 Threema IDs
  • Data typically provided: Per Threema transparency report: "Date (without time) of the Threema ID's creation; Date (without time) of Threema ID's most recent login," plus hashed phone/email if the user opted to link them. Legal basis Article 22(3) BÜPF. Direct foreign requests refused; requests must come through Swiss channels.

— Publicly disclosed incidents (2024-04 → 2026-03)

  • 2024-09 — Founding CEO Martin Blatter and remaining original developers departed (publicly acknowledged by Threema). Source: Threema official communications
  • 2024-12-20 — Threema Desktop 2.0 open-source beta released. Source: https://threema.com/en/blog
  • 2025-10-20 — Threema 6.2 released; support for Android 5 and Android 6 dropped. Source: https://threema.com/en/changelog
  • 2025-12-31 — 2025 transparency report update: 423 requests, 422 compliances, 402 data productions covering 1,505 Threema IDs. Source: https://threema.com/en/transparency-report
  • 2026-01 — Ownership of parent Threema Holding AG transferred from Afinum Management GmbH to Comitis Capital GmbH (Frankfurt am Main). Source: https://comitiscapital.com and Zefix filings
  • 2026-03-10 — IBM Research partnership announced for post-quantum upgrade using ML-KEM. Source: https://threema.com/en/blog/quantum-secure-future

— Sources

  • Privacy Policy / Privacy page — https://threema.com/en/privacy (accessed 2026-04-21)
  • Terms of Service — https://threema.com/en/tos (accessed 2026-04-21)
  • Transparency report — https://threema.com/en/transparency-report (accessed 2026-04-21)
  • Security overview — https://threema.com/en/security (accessed 2026-04-21)
  • Open source page — https://threema.com/en/why-threema/open-source (accessed 2026-04-21)
  • Source repositories — https://github.com/threema-ch (accessed 2026-04-21)
  • Threema OnPrem — https://threema.com/en/onprem (accessed 2026-04-21)
  • Zefix entry (Threema GmbH, UID CHE-221.440.104) — https://www.zefix.ch (accessed 2026-04-21)
  • Zefix entry (Threema Holding AG, UID CHE-487.082.806) — https://www.zefix.ch (accessed 2026-04-21)
  • Cure53 Threema Desktop audit 2024 — https://cure53.de/pentest-report_threema-desktop.pdf (2024-01)
  • Ibex formal analysis (Univ. of Erlangen-Nuremberg, 2023-07) — https://threema.com/en/blog
  • Comitis Capital acquisition announcement — https://comitiscapital.com (2026-01)
  • IBM Research quantum announcement — https://threema.com/en/blog/quantum-secure-future (2026-03-10)

Wickr

Scope per brief §7.2: Wickr Me (consumer) was discontinued 2023-12-31. This profile covers the current AWS Wickr products (AWS Wickr commercial, AWS WickrGov, Wickr Enterprise, Wickr RAM) only.

— Developer / Operator

  • Company: Amazon Web Services, Inc. (Wickr LLC is the legal developer entity; Wickr was acquired by AWS in 2021)
  • HQ jurisdiction: Seattle, Washington, United States (AWS). Parent Amazon.com, Inc. is Delaware-incorporated; publicly traded on NASDAQ (AMZN).
  • Ownership structure: Wholly-owned subsidiary of Amazon.com, Inc. (publicly traded)
  • Year founded: Wickr Inc. founded 2012; acquired by AWS 2021

— Architecture

  • Type: Centralized
  • Server locations (declared): AWS Wickr (commercial) available in AWS regions Asia Pacific (Malaysia, Singapore, Sydney, Tokyo), Canada (Central), Europe (Frankfurt, London, Stockholm, Zurich), US East (N. Virginia). AWS WickrGov is deployed exclusively in AWS GovCloud (US-West, Oregon).
  • Self-hosting available: Yes via Wickr Enterprise and Wickr RAM (both are on-premises, self-hosted deployments listed on the AWS Wickr download page)

— Code & Transparency

  • Client source code: Proprietary
  • Server source code: Proprietary
  • Protocol specification: Partially public (historical Wickr whitepapers); current AWS Wickr cryptographic architecture not released as a formal specification
  • Transparency report: No product-specific transparency report. AWS government/law-enforcement request statistics are bundled in the AWS Information Request Report (https://aws.amazon.com/compliance/information-request-report/)

— Encryption

  • E2E by default: All chats, calls, file transfers, screen sharing
  • Protocol: Wickr proprietary protocol (historically based on Double Ratchet principles with ephemeral per-message keys). 256-bit AES for content per AWS Wickr product page.
  • Keys on device: Yes
  • Last independent audit: Not publicly documented post-AWS acquisition. AWS Wickr is DoD CC SRG Impact Level 5 (IL5) and FedRAMP High authorized in AWS GovCloud (US-West); SOC 1/2/3, ISO 27001, HIPAA-eligible.

— Identity & registration

  • Phone number required: No (account provisioning is email-based within an AWS Wickr network)
  • Email required: Yes (enterprise provisioning uses email addresses)
  • Anonymous registration: Not possible — accounts are provisioned by a network administrator within an AWS Wickr network

— Data retention (per their own Privacy Policy)

  • Content of messages: End-to-end encrypted in transit and at rest. Retention is administrator-configurable within the AWS Wickr network; administrators can enable automatic records retention for compliance use cases.
  • Metadata retained: Not publicly documented as an itemized list. AWS WickrGov public documentation states email addresses of provisioned users and network names are visible to AWS Wickr service personnel "as part of normal service function" and may leave the GovCloud region.
  • Backup handling: Administrator-configurable data retention module; configuration determines whether messages are retained in a data retention store. No separate end-user cloud-backup product.

— Law enforcement (per their own disclosures)

  • Most recent transparency report period: AWS Information Request Report — most recent period published is bundled across all AWS services, not Wickr-specific (accessed 2026-04-21)
  • Government requests received: Not publicly documented at product level (aggregated across AWS)
  • Government requests complied with (in part or full): Not publicly documented at product level
  • Data typically provided: Per AWS Privacy Notice and Information Request Report, AWS responds to valid legal process; specific data categories for Wickr not itemized separately from the AWS aggregate.

— Publicly disclosed incidents (2024-04 → 2026-03)

  • 2025-03-13 — New AWS Wickr administration console released (replaces classic admin console). Source: https://docs.aws.amazon.com/wickr/latest/adminguide/
  • 2025-06-11 — AWS WickrGov Enterprise QuickStart for up to 50,000 users announced; updated no-cost trial of up to 50 users through 2025-12-31. Source: https://aws.amazon.com/blogs/publicsector/new-aws-wickrgov-offerings-to-enable-secure-compliant-communication-on-multiple-devices/
  • 2025-12-08 — AWS Wickr bots version 6.60 released with Ubuntu 24 and FIPS compliance updates. Source: https://docs.aws.amazon.com/wickr/latest/wickrio/release-notes.html
  • 2026-01-20 — AWS Wickr bots version 6.60.05.78 released; CVE-level fix for "limited authorization validation" in admin command handling that could allow unauthorized privilege escalation. Source: https://docs.aws.amazon.com/wickr/latest/wickrio/release-notes.html
  • Pre-window context (per brief §7.2): 2023-12-31 Wickr Me consumer product discontinued.

— Sources

  • AWS Wickr product page — https://aws.amazon.com/wickr/ (accessed 2026-04-21)
  • AWS Wickr FAQs — https://aws.amazon.com/wickr/faqs/ (accessed 2026-04-21)
  • AWS Wickr Privacy Notice — https://wickr.com/privacy-policy/ (accessed 2026-04-21)
  • AWS Privacy Notice — https://aws.amazon.com/privacy/ (accessed 2026-04-21)
  • AWS WickrGov GovCloud docs — https://docs.aws.amazon.com/govcloud-us/latest/UserGuide/govcloud-wickr.html (accessed 2026-04-21)
  • AWS Wickr administration console release notes — https://docs.aws.amazon.com/wickr/latest/adminguide/ (accessed 2026-04-21)
  • AWS Wickr IO release notes — https://docs.aws.amazon.com/wickr/latest/wickrio/release-notes.html (accessed 2026-04-21)
  • AWS Information Request Report — https://aws.amazon.com/compliance/information-request-report/ (accessed 2026-04-21)
  • AWS compliance programs — https://aws.amazon.com/compliance/ (accessed 2026-04-21)
  • Wickr Enterprise download (self-hosted) — https://aws.amazon.com/wickr/ (accessed 2026-04-21)
  • AWS Public Sector blog on AWS WickrGov — https://aws.amazon.com/blogs/publicsector/new-aws-wickrgov-offerings-to-enable-secure-compliant-communication-on-multiple-devices/ (2025-06-11)
  • SEC filings (Amazon.com, Inc.) — https://www.sec.gov/cgi-bin/browse-edgar?action=getcompany&CIK=0001018724

Session

— Developer / Operator

  • Company: Session Technology Foundation / Session Technology Stiftung (Switzerland; established 2024). Previously stewarded by Oxen Privacy Tech Foundation (Australia; 2018–2024).
  • HQ jurisdiction: Switzerland (specific canton not publicly documented as of 2026-04-21)
  • Ownership structure: Swiss-law foundation (Stiftung); non-profit steward with governance codified in constitutional documents
  • Year founded: Session project began 2018 under Oxen Privacy Tech Foundation; Session Technology Foundation established 2024

— Architecture

  • Type: Decentralized — client messages are onion-routed via the Session Network, a permissionless network of service nodes (formerly called Oxen service nodes) operated by the community. No central message-routing server operated by the Foundation.
  • Server locations (declared): Global distribution of community-operated service nodes; no central server locations declared
  • Self-hosting available: Yes — anyone can operate a Session Network service node under the staking requirements published by Session. The client source is available for independent builds.

— Code & Transparency

  • Client source code: Public — https://github.com/session-foundation and https://github.com/oxen-io (historical repos)
  • Server source code: Public — Session Network / service-node software under GPL-equivalent licenses at https://github.com/session-foundation
  • Protocol specification: Public — Session Protocol and Session Network design described in the Session whitepaper at https://arxiv.org/abs/2002.04609 and in documentation at https://getsession.org/faq
  • Transparency report: Not published as a periodic numerical report (by architecture design, the Foundation does not operate the message-routing infrastructure and does not receive message-routing data)

— Encryption

  • E2E by default: All messages (one-to-one and groups)
  • Protocol: Session Protocol (internally developed after migration away from Signal Protocol); onion-routed transport via the Session Network. Groups v2 upgrade publicly announced 2026-Q1.
  • Keys on device: Yes (Session ID derived from an Ed25519 keypair generated on device)
  • Last independent audit: Trail of Bits audit (2022) and Trail of Bits audit (2024). Published audit reports available via https://getsession.org/blog and Trail of Bits publications.

— Identity & registration

  • Phone number required: No
  • Email required: No
  • Anonymous registration: Possible — account identity is a 66-character alphanumeric Session ID derived from an on-device keypair; no personally identifying information is required

— Data retention (per their own Privacy Policy)

  • Content of messages: End-to-end encrypted; ephemeral storage on service nodes for offline delivery (per Session FAQ: encrypted messages are held for a short period by the receiving swarm until delivery or expiry)
  • Metadata retained: Per Session Privacy Policy (as of 2026-04-21): the Foundation does not operate message-routing infrastructure and does not collect message metadata centrally. Service nodes route messages via onion paths; no single node sees both sender and recipient.
  • Backup handling: Local on-device backups; no cloud-backup product operated by the Foundation. Recovery via the user-held recovery phrase that reconstructs the Session ID.

— Law enforcement (per their own disclosures)

  • Most recent transparency report period: Not applicable — no periodic numerical report
  • Government requests received: Not publicly documented (the Foundation does not operate message-routing servers that would hold message data)
  • Government requests complied with (in part or full): Not publicly documented
  • Data typically provided: Per Session FAQ, the Foundation does not hold user identity information, phone numbers, email addresses, IP addresses, or message content centrally. The Foundation stewards app publishing, repository management, and signing keys.

— Publicly disclosed incidents (2024-04 → 2026-03)

  • 2024-10 — Session Technology Foundation established in Switzerland; stewardship of Session transferred from Oxen Privacy Tech Foundation (Australia) to Session Technology Foundation (Switzerland). Publicly cited reasons, per Session's own communications: the Australian Assistance and Access Act 2018, the Australian eSafety Commissioner's encrypted-messaging code, and interactions with Victoria Police and the Australian Federal Police. Source: https://getsession.org/blog and 404 Media reporting
  • 2024 — Trail of Bits security audit published for Session clients. Source: Trail of Bits publications
  • 2025-02 to 2025-03 — Session Token (SESH) Token Generation Event and migration of the Session Network from the Oxen blockchain to an Arbitrum-based (EVM-compatible) staking model. Source: https://oxen.io/session-token-tge-update-whats-changing-and-what-it-means-for-oxen-node
  • 2026-Q1 — Groups v2 upgrade publicly announced for improved stability in larger group chats. Source: https://getsession.org/blog
  • Note: On 2026-04-09 — outside the 2024-04 → 2026-03 window specified by brief §2.3 — the Session Technology Foundation announced it will close operations after 2026-07-08 if it does not receive at least US$1M in additional funding (per Wikipedia entry and Foundation communications). Included here as context; not counted as an in-window incident.

— Sources

  • Privacy Policy — https://getsession.org/privacy-policy (accessed 2026-04-21)
  • Terms of Service — https://getsession.org/terms-of-service (accessed 2026-04-21)
  • FAQ — https://getsession.org/faq (accessed 2026-04-21)
  • Session whitepaper — https://arxiv.org/abs/2002.04609
  • Blog (Session Technology Foundation) — https://getsession.org/blog (accessed 2026-04-21)
  • Source code — https://github.com/session-foundation (accessed 2026-04-21)
  • Oxen / legacy repositories — https://github.com/oxen-io (accessed 2026-04-21)
  • STF Switzerland migration announcement — https://getsession.org/blog (2024-10)
  • Session Token TGE — https://oxen.io/session-token-tge-update-whats-changing-and-what-it-means-for-oxen-node (2024-11)
  • Trail of Bits Session audits (2022, 2024) — https://github.com/trailofbits/publications
  • 404 Media reporting on Australian police visit — https://www.404media.co (2024)

Federated and decentralized

Matrix / Element

Developer / Operator

Company: The Matrix.org Foundation C.I.C. (UK Companies House No. 11648710, incorporated 2018-10-29, registered office 14 Turnham Green Terrace Mews, London W4 1QU) stewards the protocol. Element is operated by New Vector Limited / Element Creations Limited (UK Companies House No. 10873661, incorporated 2017-07-19, registered office 10 Queen Street Place, London EC4R 1AG). Per Companies House filings reviewed 2026-04-22, entity 10873661 now records the name "ELEMENT CREATIONS LIMITED"; element.io legal text still cites "New Vector Limited". HQ jurisdiction: United Kingdom (England) Ownership structure: Foundation (Matrix.org Foundation — private company limited by guarantee, registered as Community Interest Company with asset lock); Private (Element — venture-funded private limited company). Co-founders Matthew Hodgson and Amandine Le Pape. Year founded: 2018 (Foundation); 2017 (Element)

Architecture

Type: Federated Server locations (declared): Per matrix.org Privacy Notice, matrix.org homeserver data hosted on AWS (EU region). Other homeservers hosted by independent operators in jurisdictions of their choice. Self-hosting available: Yes. Reference server implementations: Synapse (github.com/element-hq/synapse), Dendrite (github.com/element-hq/dendrite; matrix-org/dendrite archived 2024-11-25), Conduit, Continuwuity.

Code & Transparency

Client source code: Public (AGPLv3) — https://github.com/element-hq Server source code: Public (AGPLv3 or commercial Element license, dual-licensed since 2023) — https://github.com/element-hq/synapse Protocol specification: Public — https://spec.matrix.org/ Transparency report: Not publicly documented — As of 2026-04-22, neither matrix.org nor element.io publishes a periodic law-enforcement transparency report; a Law Enforcement Guidelines document is published at https://matrix.org/legal/law-enforcement-guidelines/.

Encryption

E2E by default: All chats (private rooms and DMs create encrypted rooms by default in current Element clients; public rooms unencrypted by design) Protocol: Olm / Megolm (Double Ratchet variant). MLS (RFC 9420) integration in progress under MSC4244 / MSC4256; status tracked at https://arewemlsyet.com/ Keys on device: Yes (cross-signing; optional server-side Secure Secret Storage / Key Backup encrypted with user-held recovery key) Last independent audit: 2016-09 by NCC Group (Olm/Megolm review); 2022-08 academic paper "Practically-exploitable Cryptographic Vulnerabilities in Matrix" (Albrecht, Celi, Dowling, Jones), IEEE S&P 2022 — https://nebuchadnezzar-megolm.github.io/

Identity & registration

Phone number required: No (on matrix.org homeserver; varies by homeserver operator) Email required: Optional (required for password reset on matrix.org) Anonymous registration: Possible (on homeservers that permit it; matrix.org requires account creation via Matrix Authentication Service as of 2025)

Data retention (per their own Privacy Policy)

Content of messages: Per matrix.org Privacy Notice, message content of E2EE rooms is not accessible to the server operator. Per element.io Privacy Policy, for EMS-hosted services redacted messages/media are retained 7 days before permanent deletion. Metadata retained: Per matrix.org Privacy Notice: IP logs retained up to 180 days; account identifiers; room membership and presence; device identifiers. Analytics via Plausible and PostHog EU (aggregate by MXID). Backup handling: Server-side (client-encrypted) — Secure Secret Storage / Key Backup, encrypted with user-held recovery key before upload.

Law enforcement (per their own disclosures)

Most recent transparency report period: Not publicly documented Government requests received: Not publicly documented Government requests complied with (in part or full): Not publicly documented Data typically provided: Per matrix.org Law Enforcement Guidelines (accessed 2026-04-22), the Foundation requires valid UK legal process (Investigatory Powers Act 2016) or MLAT for foreign requests; will not voluntarily share user data; "will not support encryption backdoors"; policy to notify users unless prohibited. E2EE room content is stated to be cryptographically inaccessible to server admins.

Publicly disclosed incidents (2024-04 → 2026-03)

CVE-2024-31208 (Synapse state-resolution CPU/DB amplification; fixed 1.105.1). CVE-2024-37303 (unauthenticated remote media planting; fixed 1.106). CVE-2024-52805 and CVE-2024-53867 (multipart/form-data memory exhaustion and Sliding Sync partial-state leakage; fixed 1.120.1). CVE-2025-30355 / GHSA-v56r-hwv5-mxg6 (federation-breaking malformed-event DoS, exploited in the wild; fixed 1.127.1). CVE-2025-61672 (insufficient device-key validation; fixed 1.139.x). "Project Hydra" coordinated disclosure 2025-08-14: CVE-2025-49090 (state reset via state-resolution manipulation) and CVE-2025-54315 (lack of cryptographic uniqueness for room creation events), mitigated via Matrix room version 12 released in Matrix 1.16 across Synapse, Dendrite, Conduit, Continuwuity, Tuwunel, Synapse Pro, ejabberd, Rocket.Chat. CVE-2026-24044 / ELEMENTSEC-2025-1670 (ESS Community Helm chart PRNG seed reuse producing predictable Synapse signing keys; Synapse 1.147.x blocks federation from known-insecure signing keys).

Sources

SimpleX

Developer / Operator

Company: SimpleX Chat Ltd. (UK Companies House No. 13691484, incorporated 2021-10-20, registered office 20-22 Wenlock Road, London N1 7GU). Sole director and PSC: Evgeny Poberezkin. HQ jurisdiction: United Kingdom (England) Ownership structure: Private (private limited company). Pre-seed funding round of US $1.3M closed 2024-08, led by Jack Dorsey with Asymmetric Capital Partners; prior angel funding from Village Global. Per SimpleX's own 2024-08 announcement, the investment includes no board seats and no control provisions; the company has stated intention to transition to non-profit governance. Year founded: 2021

Architecture

Type: Federated (relay network; no user accounts on relays) Server locations (declared): Per simplex.chat documentation (accessed 2026-04-22), users may use preset SMP and XFTP relays (operated by SimpleX Chat Ltd. and by Flux) or configure any self-hosted relay. Default client configuration uses four distinct servers per contact to split sender/recipient correlation. Self-hosting available: Yes — SMP messaging relays and XFTP file-transfer relays are open-source and self-hostable.

Code & Transparency

Client source code: Public (AGPLv3) — https://github.com/simplex-chat/simplex-chat Server source code: Public (AGPLv3) — https://github.com/simplex-chat/simplexmq Protocol specification: Public — https://github.com/simplex-chat/simplexmq/blob/master/protocol/simplex-messaging.md Transparency report: Published — https://simplex.chat/transparency/ ; updated as facts change. Per page text accessed 2026-04-22: "This page will include any and all reports on requests for user data. To date, we received none."

Encryption

E2E by default: All chats Protocol: Signal Double Ratchet with post-quantum extension (initial PQ-resistant handshake added in v5.6, March 2024); additional per-hop encryption between client and relay; TLS 1.3 on transport. Keys on device: Yes (local client database encrypted with passphrase stored in iOS Keychain / Android Keystore) Last independent audit: 2024-07 by Trail of Bits (cryptographic design review of SMP and related protocols; 3 medium + 1 low findings, all high-difficulty) — https://github.com/trailofbits/publications ; prior 2022-11 implementation review of simplexmq by Trail of Bits (4 findings, including X3DH KDF bug)

Identity & registration

Phone number required: No Email required: No Anonymous registration: Possible — per simplex.chat/privacy/, "SimpleX has no user identifiers of any kind — not even random numbers".

Data retention (per their own Privacy Policy)

Content of messages: Per Privacy Policy updated 2024 (accessed 2026-04-22): relays store undelivered messages encrypted for the recipient and delete them after delivery or expiry; SimpleX Chat Ltd. does not host user accounts or profiles. Metadata retained: Per Privacy Policy 2024 update: "absolute minimum of metadata required for the network to function". Relays handle per-queue routing information; sender IP shielded from destination relay by the v5.8 Private Message Routing feature (2024-06). Backup handling: Local device only — no cloud backup by default; optional user-exported encrypted archive.

Law enforcement (per their own disclosures)

Most recent transparency report period: As of 2026-04-22, page states no legally enforceable requests have been received to date. Government requests received: 0 (per https://simplex.chat/transparency/) Government requests complied with (in part or full): 0 Data typically provided: Per transparency page: "In 2024 we received enquiries from several law enforcement agencies seeking information on our procedures for handling data requests. We responded by noting that we operate under the UK law and will consider such requests pursuant to UK law."

Publicly disclosed incidents (2024-04 → 2026-03)

None publicly disclosed as a security incident. Trail of Bits design review (2024-07) findings were remediated in SimpleX protocol v6.1 (2024-10), which relocated queue identifiers inside the TLS channel to mitigate traffic-correlation risk.

Sources

Briar

Developer / Operator

Company: The Briar Project — unincorporated developer collective. Lead developers Michael Rogers and Torsten Grote; additional core contributors listed at briarproject.org/about/ include Eleanor Saitta, Julian Dehm, Sebastian, Mikolai Gütschow, Nico Alt and Paul. HQ jurisdiction: Not publicly documented (no legal entity) Ownership structure: Other (unincorporated developer collective funded by public-interest grants) Year founded: 2014 (first public release)

Architecture

Type: P2P Server locations (declared): None. Per briarproject.org/how-it-works/ (accessed 2026-04-22), Briar operates without central servers; peers connect via Tor hidden services over the internet, or directly via Bluetooth or local Wi-Fi. Briar Mailbox (released 2023-06-15) is an optional user-hosted always-online inbox running on a spare Android device. Self-hosting available: Not applicable — no server exists to host. Users optionally host their own Briar Mailbox.

Code & Transparency

Client source code: Public (GPL-3.0-or-later) — https://code.briarproject.org/briar/briar Server source code: Not applicable (no server). Briar Mailbox source: https://code.briarproject.org/briar/briar-mailbox. Briar Desktop source (AGPL-3.0): https://code.briarproject.org/briar/briar-desktop Protocol specification: Public — Bramble suite (BQP handshake, BSP sync, BTP transport), specified at https://code.briarproject.org/briar/briar-spec Transparency report: Not publicly documented — no central operator exists to receive or log requests.

Encryption

E2E by default: All chats Protocol: Bramble Transport Protocol (BTP) and Bramble Sync Protocol (BSP), custom authenticated encryption built on Curve25519 / Ed25519 / XSalsa20-Poly1305 primitives; per-link keys derived via Bramble Handshake Protocol (BHP/BQP). Keys on device: Yes (device-local only; database encrypted with user passphrase) Last independent audit: 2017-03 by Cure53 (12 issues; all fixed) — https://cure53.de/pentest-report_briar.pdf ; 2023-03 ETH Zürich semester project "Cryptography in the Wild: Briar" by Yuanming Song, supervised by Prof. Kenny Paterson (3 issues; all fixed in Briar 1.4.22 and 1.5.3)

Identity & registration

Phone number required: No Email required: No Anonymous registration: Possible — user provides a nickname and passphrase; account is device-local.

Data retention (per their own Privacy Policy)

Content of messages: Per briarproject.org/privacy-policy/ (accessed 2026-04-22; no explicit effective date published on page): messages are stored only on the user's device in an encrypted database; no copies are stored by Briar developers. Metadata retained: Per Privacy Policy and briarproject.org/how-it-works/: contact discovery and message routing occur between peers; no developer-operated service receives traffic metadata. Backup handling: Device-local only. Account-portability mechanism exists via encrypted local backup / account transfer procedure documented in the Briar user manual.

Law enforcement (per their own disclosures)

Most recent transparency report period: Not publicly documented Government requests received: Not publicly documented Government requests complied with (in part or full): Not publicly documented Data typically provided: Per briarproject.org/privacy-policy/, the project holds no user data that could be disclosed to third parties.

Publicly disclosed incidents (2024-04 → 2026-03)

None publicly disclosed. In-window releases: Briar 1.5.14 (2025-03), Briar 1.5.17 (2026-03-12), Briar Desktop 0.6.5-beta (2026-02-20).

Sources

XMPP ecosystem

Developer / Operator

Company: XMPP Standards Foundation (XSF) — US 501(c)(3) nonprofit, EIN 84-1611178, P.O. Box 787, Parker, CO 80134, USA. Approximately 55 elected members; five-seat Council and Board. XSF publishes XEP specifications and writes no end-user code. Reference clients: Conversations (Daniel Gultsch), Gajim (volunteer community), Dino (volunteer community), Monocles. Reference servers: ejabberd (ProcessOne, France); Prosody (Matt Wild et al.). HQ jurisdiction: United States (Colorado) — XSF. Reference-implementation maintainers operate in multiple jurisdictions; homeserver operators are independent. Ownership structure: Foundation (XSF) + separate Private / community operators for clients and servers Year founded: 2001 (XSF)

Architecture

Type: Federated Server locations (declared): Varies by homeserver operator. Each operator is independent; no central registry of hosting locations. Self-hosting available: Yes — ejabberd, Prosody, Openfire, Tigase and others are open-source server implementations.

Code & Transparency

Client source code: Public — Conversations (GPLv3) at https://github.com/iNPUTmice/Conversations ; Gajim (GPLv3) at https://dev.gajim.org/gajim/gajim ; Dino (GPLv3) at https://github.com/dino/dino ; Monocles at https://codeberg.org/Arne/monocles_chat Server source code: Public — ejabberd (GPLv2-or-later) at https://github.com/processone/ejabberd ; Prosody (MIT) at https://hg.prosody.im/trunk/ (mirror: https://github.com/bjc/prosody) Protocol specification: Public — RFC 6120 (XMPP Core), RFC 6121 (XMPP IM), RFC 7622 (address format), and XEP series at https://xmpp.org/extensions/ Transparency report: Not publicly documented — The XSF does not publish a transparency report. Transparency reports, where published, are produced by individual homeserver operators.

Encryption

E2E by default: Opt-in (enabled by default for one-to-one chats in Conversations and Monocles when both devices support OMEMO; varies by client) Protocol: OMEMO (XEP-0384) — Signal Double Ratchet with X3DH over XMPP PEP. Namespace versions deployed as of 2026-04-22: eu.siacs.conversations.axolotl (legacy, dominant), urn:xmpp:omemo:1, urn:xmpp:omemo:2 ("Twomemo"). Per xmpp.org/extensions/xep-0384.html, XEP-0384 current version 0.9.0 (published 2025-04-07), status Experimental. Keys on device: Yes (per-device identity keys published to PEP; session state device-local) Last independent audit: Not publicly documented as a single audit of the ecosystem. Individual implementations have received academic and commercial review separately; no unified XSF audit programme exists.

Identity & registration

Phone number required: No (JID format is user@domain per RFC 7622) Email required: Optional (varies by homeserver operator) Anonymous registration: Possible (varies by homeserver operator; many operators allow registration with username and password only)

Data retention (per their own Privacy Policy)

Content of messages: Per operator. XSF has no access to message content. Server operators may retain server-side message archives under XEP-0313 (Message Archive Management) at retention periods set by that operator; OMEMO-encrypted payloads are not readable by the server. Metadata retained: Per operator. Typical server-retained metadata includes JID roster state, presence subscriptions, device/resource identifiers, and connection logs; specific retention periods vary by homeserver. Backup handling: Per operator and per client. Device-local client databases are the default; some servers offer XEP-0313 archives that clients can resynchronise.

Law enforcement (per their own disclosures)

Most recent transparency report period: Not publicly documented (XSF does not receive user data requests as it operates no production service) Government requests received: Not publicly documented Government requests complied with (in part or full): Not publicly documented Data typically provided: Per operator's policy. XSF holds no user messaging data.

Publicly disclosed incidents (2024-04 → 2026-03)

None publicly disclosed against XSF specifications in this window. ejabberd release 25.10 (2025-10-28) included the Matrix "Project Hydra" coordinated fix for CVE-2025-49090 / CVE-2025-54315 in mod_matrix_gw. Prosody issued routine minor releases in-window (13.0.0 on 2025-03-17, 13.0.1 on 2025-04-03, 13.0.2 on 2025-05-29, 13.0.3 on 2026-01-05, 13.0.4 on 2026-01-25); no platform-wide CVEs against Prosody were publicly disclosed in the window per https://prosody.im/doc/security.

Sources

Appendix A — Methodology

A.1. Scope and inclusion criteria

This report profiles twenty messaging platforms with publicly documented usage above one million monthly active users and material public claims regarding privacy. The selection follows the brief's §2.1 grouping:

  • Mainstream centralized (8): WhatsApp, Facebook Messenger, iMessage, Google Messages (RCS), Telegram, Discord, Snapchat, Viber.
  • Regional centralized (3): WeChat / Weixin, LINE, KakaoTalk.
  • Privacy-focused centralized (5): Signal, Wire, Threema, Wickr (AWS), Session.
  • Federated or decentralized (4): Matrix / Element, SimpleX, Briar, XMPP ecosystem.

The first edition explicitly excludes (a) enterprise-only platforms whose primary distribution channel is corporate procurement (Slack, Microsoft Teams, Mattermost, Rocket.Chat), (b) gaming-voice platforms (TeamSpeak, Mumble), and (c) discontinued projects (Keybase as a standalone messenger, Tox, Ricochet). WeChat and Weixin are profiled as a single platform with regional variants documented in the profile, consistent with Tencent's product framing.

The temporal window for the industry timeline is 2024-04-01 through 2026-03-31 (twenty-four months). Older incidents are referenced in platform profiles only where they remain materially relevant to the platform's current architecture or governance; they are not included in the cross-platform timeline.

A.2. Source hierarchy

The following are accepted as primary sources for factual claims in this report:

  • A platform operator's currently published Privacy Policy, Terms of Service, security whitepaper, transparency report, or law-enforcement guideline document.
  • A platform operator's official source-code repository (where present), including license metadata.
  • Filings by publicly traded operators with the United States Securities and Exchange Commission, the Hong Kong Exchanges and Clearing, the Korea Exchange, the Japan Exchange Group, or equivalent regulators.
  • Court documents accessed through PACER, CourtListener, EUR-Lex, official tribunal websites, or equivalent national court-records services.
  • Apple, Google, and Meta Transparency Reports for aggregate figures regarding requests served on those platforms.
  • Official communications from data-protection authorities, communications regulators, or competition regulators (EDPB, EDPS, national DPAs, the European Commission, the United Kingdom Information Commissioner's Office, the Korea Communications Commission, the Personal Information Protection Commission of Korea, the Personal Information Protection Commission of Japan, the Cyberspace Administration of China, etc.).
  • Peer-reviewed academic publications, accepted as primary for protocol-level cryptographic claims when published in venues such as IEEE Symposium on Security and Privacy, USENIX Security, ACM CCS, Eurocrypt, CRYPTO, IACR ePrint Archive, or comparable.
  • Published reports by recognised independent security research organisations including Citizen Lab, the Electronic Frontier Foundation, Trail of Bits, Cure53, Kudelski Security, X41 D-Sec, Quarkslab, NCC Group, Project Zero, and the Freedom of the Press Foundation.

The following are not accepted as primary sources for this report:

  • Personal social-media posts by founders, executives, or other interested parties (including but not limited to Telegram founder Pavel Durov's published statements regarding competitor platforms).
  • News articles that paraphrase or characterise documents without linking to those documents.
  • Forum discussions, including Reddit, Hacker News, and similar.
  • Leaks of unverified provenance.
  • Analyst opinions and commentary.
  • This report's own commentary.

Where a fact cannot be supported by a source meeting the above criteria, it does not appear in the report.

A.3. Verification threshold

An entry is admitted to the industry timeline only when at least two of the following independent confirmations are available:

  • The platform itself acknowledges the event (in a blog post, security advisory, transparency report, regulatory filing, or post-mortem).
  • A court record documents the event (PACER, CourtListener, EUR-Lex, an official tribunal publication).
  • At least two tier-one publications report the event with quoted sources or direct document links (Reuters, the Associated Press, the BBC, The Guardian, The New York Times, The Wall Street Journal, the Financial Times, TechCrunch, The Verge, Ars Technica, 404 Media, Wired).
  • A peer-reviewed academic publication describes the event.
  • A named security researcher with a published track record publishes the analysis in an attributable venue.

For non-Western regulatory matters, an entry from the relevant national regulator (e.g., the Cyberspace Administration of China, the Korea Communications Commission, the Personal Information Protection Commission of Korea, the Ministry of Internal Affairs and Communications of Japan) combined with regional tier-one press coverage satisfies the verification threshold; the entry's verification_basis field records the combination used.

Single-source news items, social-media-only references, and rumours are not admitted to the timeline.

A.4. Language and neutrality standards

Each factual claim is presented as an attribution to the document or party that published it. Adjectives that characterise the privacy posture of a platform (such as "secure", "insecure", "good", "bad", "spying", "surveillance" used pejoratively, "backdoor" used outside direct quotation with attribution, "fake encryption", "security theatre") do not appear in the body of this report. Where a third party — for example, a regulator or a researcher — uses such language, this report quotes the third party with full attribution and a citation to the original document.

Where a platform operator publishes a claim about its own product, this report presents the claim with that attribution: "Per [Operator]'s [Document], updated [Date]: …" with a brief paraphrase or, where exact wording is material, a short direct quote.

This report does not rank platforms, assign ratings, designate winners or losers, or recommend that readers use or avoid any platform. Readers are expected to draw their own conclusions from the documented facts.

A.5. Dating and archival

Every dated claim in this report carries a YYYY-MM-DD date wherever the source provides one; otherwise, YYYY-MM or YYYY as appropriate. Each Privacy Policy, Terms of Service, transparency report, security whitepaper, or other operator-published document cited in the report has a corresponding Wayback Machine snapshot of the live URL captured on the date of access (2026-04-21 unless otherwise noted). Archive URLs follow the canonical pattern https://web.archive.org/web/{YYYY}/{live_url} keyed to the relevant year. Where a specific snapshot timestamp could not be confirmed against the Wayback CDX API during this research session, the citation is marked Snapshot pending YYYY-MM-DD and is resolved to a specific snapshot timestamp before publication of the final PDF, per the brief's §1.4.

A.6. Corrections and updates

The complete dataset accompanying this report — messengers.csv (master comparison table), messengers_sources.csv (per-cell source attribution), timeline.json, and the per-platform profile files — is held by Catyonic OÜ and is available on request from contact@catyonic.com under the Creative Commons Attribution 4.0 International licence for journalists, researchers, and academic use. Corrections are accepted via the same channel; each correction must cite a primary source under the criteria in §A.2 above. Substantive corrections are reflected in the next minor version (e.g., 1.0 → 1.1) with a correction log included alongside the dataset. The next full edition is targeted for Q4 2026 with a twelve-month retrospective and a delta from this Q2 2026 edition.

A.7. Conflict of interest disclosure

Catyonic OÜ, the publisher of this report, develops Caty, a self-hosted private messenger. Caty is not profiled in the present edition. Caty is in pre-launch development and lacks the documentation set this report's methodology requires of profiled platforms — a privacy policy in force, transparency reports covering completed reporting periods, third-party security audits with published results, and a documented incident history. Future editions of this report will profile Caty when those documents exist, applying exactly the same methodology to Caty as to every other platform.

No platform profiled in this report has sponsored this work, reviewed any portion of it prior to publication beyond the optional fact-check window described in the brief's §10.3, or otherwise influenced its content. No advertising appears in the report. The report's production was funded by Catyonic OÜ from internal resources.

Appendix B — Sources and Bibliography

This bibliography lists primary sources cited in the platform profiles, the industry timeline, and the architecture primer. Sources accessed 2026-04-21 unless otherwise stated; archive snapshots are recorded in the accompanying messengers_sources.csv dataset on a per-cell basis. The complete URL list (483 unique URLs across 205 domains) is preserved in machine-readable form alongside this report; the prose bibliography below organises the key references for each platform plus the cross-platform regulatory, judicial, and academic sources cited throughout.

Citation format: [Organisation]. [Document title]. [Date or version, where stated]. [URL].

B.1 Per-platform sources

Mainstream centralized

WhatsApp

  • WhatsApp LLC. Privacy Policy. https://www.whatsapp.com/legal/privacy-policy
  • WhatsApp Ireland Limited. Privacy Policy (EEA). https://www.whatsapp.com/legal/privacy-policy-eea
  • WhatsApp LLC. Terms of Service. https://www.whatsapp.com/legal/terms-of-service
  • WhatsApp. WhatsApp Encryption Overview — Technical White Paper. Most recent revision available at https://www.whatsapp.com/security
  • Meta Platforms, Inc. Government Data Requests. https://transparency.meta.com/reports/government-data-requests/
  • Meta Platforms, Inc. Annual Report on Form 10-K. https://www.sec.gov/cgi-bin/browse-edgar?action=getcompany&CIK=0001326801
  • WhatsApp Help Center. About end-to-end encrypted backups. https://faq.whatsapp.com/490592613091019
  • European Commission. Designation of Meta services under the Digital Services Act and Digital Markets Act. https://digital-strategy.ec.europa.eu/

Facebook Messenger

  • Meta Platforms, Inc. Facebook Privacy Policy. https://www.facebook.com/privacy/policy/
  • Meta Platforms, Inc. Terms of Service. https://www.facebook.com/legal/terms
  • Meta Platforms, Inc. Government Data Requests. https://transparency.meta.com/reports/government-data-requests/
  • Meta Engineering. Labyrinth: Encrypted Storage for Messenger. https://engineering.fb.com/
  • Meta Engineering. Key Transparency for Messenger end-to-end encrypted chats (2025-11-20). https://engineering.fb.com/
  • Cloudflare Research. Auditor for Meta Key Transparency. https://research.cloudflare.com/

iMessage

  • Apple Inc. Apple Platform Security Guide (most recent edition). https://support.apple.com/guide/security/welcome/web
  • Apple Inc. Privacy Policy. https://www.apple.com/legal/privacy/
  • Apple Inc. Transparency Report. https://www.apple.com/legal/transparency/
  • Apple Inc. Advanced Data Protection for iCloud. https://support.apple.com/guide/security/icloud-data-security-overview-sec3cac31735/web
  • Basin, D., Linker, F., Sasse, R. (ETH Zurich). Formal verification of iMessage PQ3. IACR ePrint 2024/1395. https://eprint.iacr.org/2024/1395
  • Stebila, D. (University of Waterloo). Security analysis of iMessage PQ3 (companion reductionist proof), 2024.

Google Messages (RCS)

  • Google LLC. Google Privacy Policy. https://policies.google.com/privacy
  • Google LLC. End-to-end encryption in Messages. https://support.google.com/messages/answer/10262381
  • Google LLC. Transparency Report. https://transparencyreport.google.com/
  • GSMA. Universal Profile (UP) 3.0 — RCS Cross-Platform End-to-End Encryption Specification, March 2025. https://www.gsma.com/

Discord

  • Discord Inc. Privacy Policy. https://discord.com/privacy
  • Discord Inc. Terms of Service. https://discord.com/terms
  • Discord Inc. Transparency Report. https://discord.com/safety-transparency
  • Discord Inc. Meet DAVE: End-to-end encryption for audio and video in Discord. https://discord.com/blog/meet-dave-e2ee-for-audio-video
  • Discord Inc. DAVE Protocol. https://daveprotocol.com and https://github.com/discord/dave-protocol
  • Trail of Bits. Discord DAVE Protocol Code Review (2024-09). https://github.com/trailofbits/publications

Snapchat

  • Snap Inc. Privacy Policy. https://values.snap.com/privacy/privacy-policy
  • Snap Inc. Privacy by Product. https://values.snap.com/privacy/privacy-by-product
  • Snap Inc. Transparency Report. https://values.snap.com/privacy/transparency
  • Snap Inc. Annual Report on Form 10-K. https://www.sec.gov/cgi-bin/browse-edgar?action=getcompany&CIK=0001564408
  • European Commission. List of designated VLOPs and VLOSEs under the DSA. https://digital-strategy.ec.europa.eu/en/policies/list-designated-vlops-and-vloses

Viber

  • Viber Media S.à r.l. Viber Privacy Policy. https://www.viber.com/en/terms/viber-privacy-policy/
  • Viber Media S.à r.l. Viber Terms of Use. https://www.viber.com/en/terms/viber-terms-use/
  • Viber Media S.à r.l. Information for Law Enforcement and Governmental Authorities. https://www.viber.com/en/terms/information-for-law-enforcement-and-governmental-authorities/
  • Viber Media S.à r.l. Viber Encryption Overview (PDF). https://www.viber.com/app/uploads/viber-encryption-overview.pdf
  • Viber Media S.à r.l. EU Digital Services Act Transparency Report. https://www.viber.com/en/terms/eu-digital-services-act-dsa-transparency-report/
  • Rakuten Group, Inc. Annual Securities Report. https://global.rakuten.com/corp/investors/

Telegram

  • Telegram FZ-LLC. Privacy Policy. https://telegram.org/privacy
  • Telegram FZ-LLC. Terms of Service. https://telegram.org/tos
  • Telegram FZ-LLC. FAQ. https://telegram.org/faq
  • Telegram FZ-LLC. MTProto 2.0 Specification. https://core.telegram.org/mtproto
  • Telegram FZ-LLC. End-to-End Encryption (Secret Chats). https://core.telegram.org/api/end-to-end
  • Telegram FZ-LLC. Transparency channel. https://t.me/transparency
  • Tribunal Judiciaire de Paris. Communiqué de presse — Mise en examen de Pavel Durov (2024-08-28). https://www.tribunal-de-paris.justice.fr/sites/default/files/2024-08/2024-08-28%20-%20CP%20TELEGRAM%20mise%20en%20examen.pdf

Regional centralized

WeChat / Weixin

  • Tencent International Service Pte. Ltd. WeChat Privacy Policy (international). https://www.wechat.com/en/privacy_policy.html
  • 深圳市腾讯计算机系统有限公司. 微信隐私保护指引 (Weixin Privacy Policy, mainland). https://weixin.qq.com/
  • WeChat / Weixin. Help Center — message retention. https://help.wechat.com/
  • Tencent Holdings Ltd. Annual Report. HKEX filings via https://www1.hkexnews.hk/listedco/listconews/sehk/
  • Cyberspace Administration of China (国家互联网信息办公室). https://www.cac.gov.cn/
  • Citizen Lab. Research on WeChat surveillance. https://citizenlab.ca/

LINE

  • LY Corporation. LINE Rules and Privacy. https://terms.line.me/line_rules
  • LY Corporation. Privacy and Security Center. https://www.lycorp.co.jp/en/privacy-security/
  • LY Corporation. LINE Encryption Whitepaper, version 2.2 (December 2025, PDF). https://www.lycorp.co.jp/en/privacy-security/line-encryption-whitepaper-ver2.2.pdf
  • LY Corporation. Transparency Reports. https://www.lycorp.co.jp/en/privacy-security/privacy/transparency/reports/
  • Ministry of Internal Affairs and Communications, Japan (総務省). Administrative guidance to LY Corporation. https://www.soumu.go.jp/
  • Personal Information Protection Commission, Japan (個人情報保護委員会). https://www.ppc.go.jp/

KakaoTalk

  • Kakao Corp. Privacy Policy. https://www.kakao.com/policy/privacy
  • Kakao Corp. Privacy Transparency. https://privacy.kakao.com/transparency
  • Kakao Corp. Annual Disclosure (DART). https://dart.fss.or.kr/
  • Personal Information Protection Commission of Korea (개인정보보호위원회). https://www.pipc.go.kr/
  • Korea Communications Commission (방송통신위원회). https://kcc.go.kr/
  • Supreme Court of Korea. https://www.scourt.go.kr/

Privacy-focused centralized

Signal

  • Signal Messenger, LLC. Privacy Policy and Terms. https://signal.org/legal/
  • Signal Messenger, LLC. Government Communication ("Big Brother"). https://signal.org/bigbrother/
  • Signal Messenger, LLC. Protocol documentation. https://signal.org/docs/
  • Signal Messenger, LLC. PQXDH announcement, 2023-09-19. https://signal.org/blog/pqxdh
  • Signal Messenger, LLC. SPQR (Sparse Post-Quantum Ratchet) announcement, 2025-10-02. https://signal.org/blog/spqr
  • Signal Messenger, LLC. Phone-number privacy and usernames, 2024-02-20. https://signal.org/blog/phone-number-privacy-usernames
  • Signal Messenger, LLC. Introducing Secure Backups, 2025-09-08. https://signal.org/blog/introducing-secure-backups
  • Signal source repositories. https://github.com/signalapp
  • Signal Technology Foundation. IRS Form 990 (FY2024), filed 2025-09-19. https://projects.propublica.org/nonprofits/organizations/824506840
  • Bhargavan, K., Jacomme, C., Kiefer, F., Schmidt, B. A Formal Analysis of Signal's PQXDH. IACR ePrint 2023/1738, 2023-10-20. https://eprint.iacr.org/2023/1738

Wire

  • Wire Swiss GmbH. Privacy Policy. https://wire.com/en/privacy-policy/
  • Wire Swiss GmbH. Legal. https://wire.com/en/legal/
  • Wire Swiss GmbH. Transparency. https://wire.com/en/transparency-report
  • Wire Swiss GmbH. Security. https://wire.com/en/security/
  • Wire Swiss GmbH. MLS general availability announcement. https://wire.com/en/blog/wire-mls-is-now-generally-available
  • Wire source repositories. https://github.com/wireapp
  • Kudelski Security and X41 D-Sec. Wire Security Review (Proteus), 2017-02-08. https://wire.com/downloads/Kudelski_X41_Wire_Security_Review.pdf
  • Eidgenössisches Amt für das Handelsregister. Zefix entry CHE-432.881.146. https://www.zefix.ch
  • Schweizerisches Handelsamtsblatt. https://www.shab.ch

Threema

  • Threema GmbH. Privacy Policy. https://threema.com/en/privacy
  • Threema GmbH. Terms of Service. https://threema.com/en/tos
  • Threema GmbH. Transparency Report. https://threema.com/en/transparency-report
  • Threema GmbH. Open source. https://threema.com/en/why-threema/open-source
  • Threema GmbH. Threema OnPrem. https://threema.com/en/onprem
  • Threema GmbH. Quantum-secure future (IBM Research partnership), 2026-03-10. https://threema.com/en/blog/quantum-secure-future
  • Threema source repositories. https://github.com/threema-ch
  • Cure53. Pentest Report — Threema Desktop (2024-01). https://cure53.de/pentest-report_threema-desktop.pdf
  • Eidgenössisches Amt für das Handelsregister. Zefix entries CHE-221.440.104 and CHE-487.082.806. https://www.zefix.ch
  • Comitis Capital GmbH. Acquisition announcement. https://comitiscapital.com

Wickr (AWS)

  • Amazon Web Services, Inc. AWS Wickr product page. https://aws.amazon.com/wickr/
  • Amazon Web Services, Inc. AWS Wickr FAQs. https://aws.amazon.com/wickr/faqs/
  • Amazon Web Services, Inc. Wickr Privacy Policy. https://wickr.com/privacy-policy/
  • Amazon Web Services, Inc. AWS Privacy Notice. https://aws.amazon.com/privacy/
  • Amazon Web Services, Inc. AWS WickrGov GovCloud documentation. https://docs.aws.amazon.com/govcloud-us/latest/UserGuide/govcloud-wickr.html
  • Amazon Web Services, Inc. AWS Wickr Administration Guide. https://docs.aws.amazon.com/wickr/latest/adminguide/
  • Amazon Web Services, Inc. AWS Wickr IO release notes. https://docs.aws.amazon.com/wickr/latest/wickrio/release-notes.html
  • Amazon Web Services, Inc. Information Request Report. https://aws.amazon.com/compliance/information-request-report/
  • Amazon Web Services, Inc. AWS WickrGov offerings (Public Sector Blog), 2025-06-11. https://aws.amazon.com/blogs/publicsector/new-aws-wickrgov-offerings-to-enable-secure-compliant-communication-on-multiple-devices/
  • Amazon.com, Inc. SEC filings. https://www.sec.gov/cgi-bin/browse-edgar?action=getcompany&CIK=0001018724

Session

  • Session Technology Foundation. Privacy Policy. https://getsession.org/privacy-policy
  • Session Technology Foundation. Terms of Service. https://getsession.org/terms-of-service
  • Session Technology Foundation. FAQ. https://getsession.org/faq
  • Session Technology Foundation. Documentation. https://docs.getsession.org/
  • Session Technology Foundation. Blog. https://getsession.org/blog
  • Session source repositories (Session Foundation and historical Oxen). https://github.com/session-foundation and https://github.com/oxen-io
  • Kee, A., Vacca, A., Furl, A. Session: A Model for End-To-End Encrypted Conversations With Minimal Metadata Leakage. arXiv:2002.04609. https://arxiv.org/abs/2002.04609
  • Trail of Bits. Session security audits (2022, 2024). https://github.com/trailofbits/publications
  • Oxen.io. Session Token TGE update, 2024-11. https://oxen.io/session-token-tge-update-whats-changing-and-what-it-means-for-oxen-node
  • 404 Media. Reporting on Australian police visits to Oxen Privacy Tech Foundation, 2024. https://www.404media.co

Federated and decentralized

Matrix / Element

  • Matrix.org Foundation C.I.C. Matrix Specification. https://spec.matrix.org/
  • Matrix.org Foundation C.I.C. Law Enforcement Guidelines. https://matrix.org/legal/law-enforcement-guidelines/
  • Matrix.org Foundation C.I.C. Blog. https://matrix.org/blog/
  • Element Creations Ltd / New Vector Ltd. Privacy. https://element.io/privacy
  • Element Creations Ltd / New Vector Ltd. Element website. https://element.io
  • Matrix source repositories. https://github.com/matrix-org and https://github.com/element-hq
  • Albrecht, M., Celi, S., Dowling, B., Jones, D. Practically-exploitable Cryptographic Vulnerabilities in Matrix. IEEE Symposium on Security and Privacy 2022. https://nebuchadnezzar-megolm.github.io/
  • Companies House (United Kingdom). Company numbers 11648710 and 10873661. https://find-and-update.company-information.service.gov.uk

SimpleX

  • SimpleX Chat Ltd. Privacy Policy. https://simplex.chat/privacy/
  • SimpleX Chat Ltd. Transparency. https://simplex.chat/transparency/
  • SimpleX Chat Ltd. Blog. https://simplex.chat/blog/
  • SimpleX source repositories. https://github.com/simplex-chat
  • Trail of Bits. SimpleX Chat security audit, 2024-07. https://github.com/trailofbits/publications
  • Companies House (United Kingdom). Company number 13691484. https://find-and-update.company-information.service.gov.uk

Briar

  • The Briar Project. Privacy Policy. https://briarproject.org/privacy-policy/
  • The Briar Project. Security audit page. https://briarproject.org/security-audit/
  • The Briar Project. Documentation. https://briarproject.org/manual/
  • Briar source repositories. https://code.briarproject.org/briar
  • Cure53. Pentest Report — Briar Messenger, 2017-03. https://cure53.de/pentest-report_briar.pdf
  • ETH Zürich, Applied Cryptography Group. Briar semester project (Yuanming Song; Prof. Kenny Paterson), 2023-03. https://appliedcrypto.ethz.ch/education/student-projects/semester-projects.html
  • F-Droid. Briar package metadata. https://f-droid.org/

XMPP ecosystem

  • XMPP Standards Foundation. Standards page (XEPs). https://xmpp.org/extensions/
  • XMPP Standards Foundation. Foundation. https://xmpp.org/about/xsf/
  • Saint-Andre, P. Extensible Messaging and Presence Protocol (XMPP): Core. RFC 6120. https://www.rfc-editor.org/rfc/rfc6120
  • Conversations (Daniel Gultsch). https://conversations.im/ ; source: https://codeberg.org/iNPUTmice/Conversations
  • Gajim. https://gajim.org/ ; source: https://dev.gajim.org/gajim/gajim
  • Dino. https://dino.im/
  • Prosody IM. https://prosody.im/
  • ejabberd. https://www.ejabberd.im/

B.2 Cross-platform sources

Aggregator transparency reports

  • Apple Inc. Transparency Report. https://www.apple.com/legal/transparency/
  • Google LLC. Transparency Report. https://transparencyreport.google.com/
  • Meta Platforms, Inc. Transparency Center. https://transparency.meta.com/

European Union institutions

  • European Commission. Digital Services Act — list of designated VLOPs/VLOSEs. https://digital-strategy.ec.europa.eu/en/policies/list-designated-vlops-and-vloses
  • European Commission. Proposal for a Regulation laying down rules to prevent and combat child sexual abuse (CSAR) — proposed 2022-05-11; subsequent revisions 2024–2026. https://eur-lex.europa.eu/
  • Council of the European Union. Negotiating documents on CSAR. https://www.consilium.europa.eu/
  • European Parliament. Plenary and committee documents on CSAR and ProtectEU. https://www.europarl.europa.eu/
  • European Data Protection Supervisor (EDPS). https://edps.europa.eu/
  • European Data Protection Board (EDPB). Guidelines and binding decisions. https://edpb.europa.eu/

National regulators

  • Cyberspace Administration of China (国家互联网信息办公室). https://www.cac.gov.cn/
  • Personal Information Protection Commission, Japan (個人情報保護委員会). https://www.ppc.go.jp/
  • Ministry of Internal Affairs and Communications, Japan (総務省). https://www.soumu.go.jp/
  • Personal Information Protection Commission of Korea (개인정보보호위원회). https://www.pipc.go.kr/
  • Korea Communications Commission (방송통신위원회). https://kcc.go.kr/
  • Information Commissioner's Office, United Kingdom. https://ico.org.uk/
  • Office of Communications (Ofcom), United Kingdom. https://www.ofcom.org.uk/
  • Data Protection Commission, Ireland. https://www.dataprotection.ie/
  • Commission nationale pour la protection des données, Luxembourg. https://cnpd.public.lu/
  • Tribunal Judiciaire de Paris — Telegram / Pavel Durov proceedings. https://www.tribunal-de-paris.justice.fr/
  • Investigatory Powers Tribunal, United Kingdom. https://www.investigatorypowerstribunal.org.uk/
  • United States Securities and Exchange Commission EDGAR. https://www.sec.gov/cgi-bin/browse-edgar
  • New Mexico Office of the Attorney General. https://www.nmdoj.gov/
  • Office of the Attorney General of Florida. https://myfloridalegal.com/
  • CourtListener (Free Law Project). https://www.courtlistener.com/
  • EUR-Lex (European Union law). https://eur-lex.europa.eu/

Corporate registries and company-information services

  • Eidgenössisches Amt für das Handelsregister — Zefix (Switzerland). https://www.zefix.ch
  • Schweizerisches Handelsamtsblatt (SHAB). https://www.shab.ch
  • Companies House (United Kingdom). https://find-and-update.company-information.service.gov.uk
  • DART (Data Analysis, Retrieval and Transfer System), Republic of Korea. https://dart.fss.or.kr/
  • Hong Kong Exchanges and Clearing — HKEXnews. https://www1.hkexnews.hk/

Independent security research and civil-society organisations

  • Citizen Lab, Munk School, University of Toronto. https://citizenlab.ca
  • Electronic Frontier Foundation. https://www.eff.org and Surveillance Self-Defense. https://ssd.eff.org
  • Freedom of the Press Foundation. https://freedom.press
  • European Digital Rights (EDRi). https://edri.org
  • Privacy International. https://privacyinternational.org
  • Center for Democracy and Technology. https://cdt.org
  • Global Encryption Coalition. https://www.globalencryption.org
  • Trail of Bits. Publications. https://github.com/trailofbits/publications
  • Cure53. https://cure53.de
  • Kudelski Security. https://www.kudelskisecurity.com/

Vulnerability databases

  • MITRE Corporation / United States National Institute of Standards and Technology. National Vulnerability Database (NVD). https://nvd.nist.gov/
  • United States Cybersecurity and Infrastructure Security Agency (CISA). https://www.cisa.gov/

Academic publications referenced in the report

  • Albrecht, M., Celi, S., Dowling, B., Jones, D. Practically-exploitable Cryptographic Vulnerabilities in Matrix. IEEE S&P 2022.
  • Basin, D., Linker, F., Sasse, R. Formal verification of iMessage PQ3. IACR ePrint 2024/1395.
  • Bhargavan, K., Jacomme, C., Kiefer, F., Schmidt, B. A Formal Analysis of Signal's PQXDH. IACR ePrint 2023/1738.
  • Edman, M. and Yener, B. On Anonymity in an Electronic Society. ACM Computing Surveys, 2009. DOI 10.1145/1592451.1592456
  • Marlinspike, M. and Perrin, T. The Double Ratchet Algorithm. Signal documentation, 2016.
  • Maymounkov, P. and Mazières, D. Kademlia: A Peer-to-peer Information System Based on the XOR Metric, 2002.
  • Saint-Andre, P. Extensible Messaging and Presence Protocol (XMPP): Core. RFC 6120, 2011.
  • Bhargavan, K., Beurdouche, B., et al. Messaging Layer Security (MLS) Protocol. RFC 9420, 2023.
  • Unger, N. et al. SoK: Secure Messaging. IEEE S&P 2015. DOI 10.1109/SP.2015.22

Standards documents

  • Internet Engineering Task Force, RFC Editor. https://www.rfc-editor.org/
  • IETF Datatracker. https://datatracker.ietf.org/
  • National Institute of Standards and Technology. FIPS 203 — Module-Lattice-Based Key-Encapsulation Mechanism Standard. https://csrc.nist.gov/pubs/fips/203/final
  • GSM Association. RCS Universal Profile specifications. https://www.gsma.com/

News organisations cited for verification

Per §A.3, news coverage is admitted to the timeline only in combination with at least one other verification source. Tier-one publications cited across the timeline include Reuters, the Associated Press, the BBC, The Guardian, The New York Times, The Wall Street Journal, the Financial Times, TechCrunch, The Verge, Ars Technica, 404 Media, Wired, Bloomberg, CNBC, NPR, France 24, Le Monde, Heise, Computerweekly, Bleeping Computer, The Register, The Record (Recorded Future), Reuters Institute, MLex, Politico, Brussels Signal, EUobserver, EurActiv, Korea Times, The Chosun Daily, Yonhap News Agency, Nikkei, Asahi Shimbun, South China Morning Post, Rest of World, Radio Free Asia, Radio Free Europe / Radio Liberty, TASS, Interfax, The Moscow Times, Novaya Gazeta Europa.

Tools used for verification

  • Internet Archive Wayback Machine. https://web.archive.org/
  • Internet Archive Wayback CDX API for snapshot timestamp resolution.
  • IETF Datatracker for RFC and standards lookup.
  • IACR ePrint Archive for cryptographic preprints. https://eprint.iacr.org/

B.3 Note on completeness

The complete cell-level source list — every URL backing every field of messengers.csv, every dated entry in timeline.json, and every claim in the platform profiles — is maintained in machine-readable form in messengers_sources.csv alongside this report. The prose bibliography above is intended as a navigational aid for the reader; the CSV is the authoritative record. Both files are available on request from contact@catyonic.com for permanent reference and correction tracking.

About Catyonic

Catyonic OÜ is an Estonian software company focused on privacy-first communication tools.

Our products

Caty — a self-hosted private messenger for individuals and small teams. caty.ee

Contact

contact@catyonic.com Registry code: 17463508 Madara tn 9a, 10612 Tallinn, Estonia

This report

Published under CC BY 4.0. Raw data available on request: contact@catyonic.com Corrections welcome via pull request.