In partnership with
Dear Sentinels
Hi and welcome! Chomping at the bit to start reading, well I shan't stand in your way ☺. First we will look at digital communication privacy and security. Tips and tricks and all that jazz, then well turn to the academic article.
In this weeks academic article we are returning to WhatsApp, again. A University of Vienna team did two studies: “Careless Whisper: Exploiting Silent Delivery Receipts to Monitor Users on Mobile Instant Messengers” and “Prekey Pogo: Investigating Security and Privacy Issues in WhatsApp's Handshake Mechanism”. In both these studies they found serous cracks, but we will focus of the first article in this newsletter.
But first, though, let's return to news from the web.
News from around the web
This newsletter you couldn’t wait to open? It runs on beehiiv — the absolute best platform for email newsletters.
Our editor makes your content look like Picasso in the inbox. Your website? Beautiful and ready to capture subscribers on day one.
And when it’s time to monetize, you don’t need to duct-tape a dozen tools together. Paid subscriptions, referrals, and a (super easy-to-use) global ad network — it’s all built in.
beehiiv isn’t just the best choice. It’s the only choice that makes sense.
Digital Communication Security and Privacy
Executive Summary
This document shows key principles and practical strategies for achieving secure digital communication, based on an analysis of security practices. The central finding is that while end-to-end encryption (E2EE) is the foundational technology for private communication, it is only one component of a comprehensive security posture. True security requires a multi-layered approach encompassing device hardening, operational awareness, critical evaluation of communication tools, and collective action.
Signal is consistently identified as the "gold standard" for secure messaging due to its non-profit ownership, open-source protocol, default E2EE, and minimal retention of user metadata. While other platforms like WhatsApp offer E2EE, they come with trade-offs, such as the potential for unencrypted cloud backups and corporate ownership by Meta. A critical limitation of all E2EE is its inability to protect metadata, which can be as revealing as the content itself.
For individuals in high-risk environments, practical measures are paramount. These include enabling full-disk encryption on devices, using strong passcodes instead of biometrics, and considering the use of disposable "burner" phones to protect one's identity. Ultimately, the analysis reveals that digital privacy is a "team sport." An individual's security is enhanced when their community adopts secure practices.
1. The Principle of End-to-End Encryption (E2EE)
End-to-end encryption is the core technology for ensuring that digital communications remain confidential. It is designed to prevent interception by any third party, including internet service providers, application developers, and government agencies.
1.1. Mechanism and Function
E2EE ensures that information is encrypted by the original sender (the first "end") and can only be decrypted by its intended recipient (the second "end"). This is achieved through the use of cryptographic keys.
Key Generation: When two individuals wish to communicate, their devices generate unique cryptographic keys.
Encryption Process: The sender uses the recipient's public key to encrypt the message, turning readable data into an unreadable format.
Decryption Process: Upon receipt, the recipient uses their private key to decrypt the message back into a readable format.
A core characteristic of robust E2EE is that even the people who design and deploy it cannot themselves break it. This prevents the service provider from accessing user conversations, even under legal compulsion.
1.2. E2EE vs. Transport-Layer Encryption
It is crucial to distinguish E2EE from the more common transport-layer encryption.
Feature | End-to-End Encryption (E2EE) | Transport-Layer Encryption |
Protection Scope | Protects content from the sender's device all the way to the recipient's device. | Protects content only while in transit between a user's device and the service's servers. |
Provider Access | The service provider cannot access the unencrypted content of the communication. | The service provider can access the unencrypted content on its servers. |
Analogy | A sealed letter that only the recipient can open. | A postcard handed to a mail carrier, who puts it in a sealed truck for delivery but can read it beforehand. |
1.3. The Limitations of E2EE: The Metadata Problem
E2EE protects the content of communication but not the metadata (the data about the communication). This metadata, which can be highly revealing, includes:
Who are you communicating with?
The time and duration of the communication.
Your physical location when using a mobile device.
Even without the content, metadata can provide highly sensitive insights. For example, a telecommunications provider could know that a user:
Called a suicide prevention hotline from the Golden Gate Bridge.
Spoke with an HIV testing service, a doctor, and a health insurance company within the same hour.
Called a gynaecologist and then a Planned Parenthood clinic on the same day.
2. A Comparative Analysis of Communication Tools
The choice of a communication tool has significant security implications. Platforms vary widely in their implementation of encryption, data retention policies, and overall security architecture.
2.1. The Gold Standard: Signal
Security experts widely recommend Signal as the most secure messaging application for the following reasons:
Ownership: It is developed by a non-profit foundation, not a for-profit corporation.
Encryption: It offers robust, open-source, and default end-to-end encryption for all text, voice, and video communications.
Minimal Metadata: As demonstrated in a real-world subpoena case, the only data Signal could provide to authorities was "the date and time a user registered with Signal and the last date of a user's connectivity to the Signal service."
Features: It includes security-conscious features like disappearing messages, which are permanently deleted from devices and servers after a set time.
2.2. Widely-Used and Conditional Platforms
Platform | Encryption Status | Key Considerations |
End-to-end encrypted by default (uses Signal's protocol). | Owned by Meta. A major vulnerability is that if any user in a chat has cloud backups enabled, copies of the conversation are stored unencrypted in the cloud. | |
iMessage | End-to-end encrypted, but only if all participants in the conversation are using Apple devices (iPhones, etc.). | Messages to non-Apple users are sent as unencrypted SMS texts. |
Telegram | Offers E2EE, but only if the user deliberately enables the "Secret Chats" feature. Standard chats are not E2EE. | Stores standard chat data on its servers; group chats cannot be E2EE; encryption model is proprietary rather than independently verified. |
Facebook Messenger | Offers E2EE via its "Secret Conversations" feature, which must be manually activated. | Standard chats are not E2EE. |
Signal | End-to-end encrypted by default for all messages, calls, and group chats. | Considered the gold standard for privacy: open-source, non-profit, minimal metadata, and does not store message content on cloud backups. |
2.3. Anonymous Browsing: Tor Browser
For anonymous internet activity, Tor Browser is recommended over Virtual Private Networks (VPNs).
VPNs: A VPN can mask a user's location, but the VPN company itself can see all of the user's traffic and can be compelled by subpoena to hand over that data (although certain VPNs don’t hand over these flies because they don’t collect them in the first pace).
Tor Browser: Tor protects privacy by distributing internet traffic across a global, volunteer-run network of computers (nodes). This makes it nearly impossible to trace the traffic back to a single user. It also prevents websites from seeing the user's IP address. News organisations often operate SecureDrop folders, which allow for anonymous document submission when using Tor.
3. Practical Security Protocols for Individuals
Effective security extends beyond communication channels to the devices and operational habits of the user.
3.1. Device Hardening
Securing the physical device is a critical first step.
Full-Disk Encryption: This encrypts all data stored on a device ("data at rest"), protecting it if the device is lost, stolen, or confiscated. Modern iOS and Android devices have this built in and various favours of Linux has this too.
Strong Passwords: Devices should be protected with a strong password of 8-12 random characters. This is crucial to prevent brute-force attacks from breaking the encryption.
3.2. Secure Data Handling
Back Up Data: Regularly back up device data to a secure location to mitigate the impact of a lost or confiscated device.
Beware of Document Tracking: Be cautious when sharing exact copies or photos of documents, as they may contain invisible watermarks. Printed documents can contain "printer dots" that encode the time, date, and location of printing.
4. The Anatomy of a Truly Secure Messenger
While encryption is the "easy part," the development of a genuinely secure messenger involves complex trade-offs and attention to detail far beyond the core cryptography.
4.1. Key Factors Beyond Encryption
Code Quality: Flaws in the implementation of otherwise perfect cryptographic maths can introduce critical vulnerabilities.
User Experience (UX): The interface must guide users toward secure actions. A poor UX can lead to users accidentally sending unencrypted messages.
Service Reliability: If a messenger fails to deliver messages reliably, "users may be forced to fall back to less secure channels."
Secure Auto-Updates: An out-of-date app with known flaws can be more dangerous than an unencrypted one. Secure, timely updates are essential.
Encrypted Backups: Cloud backups should be E2EE with a key inaccessible to the service provider, or be disabled by default with clear warnings about the risks of enabling them.
Alias Identifiers: Forcing users to register with a phone number can compromise the privacy of vulnerable individuals. Secure messengers should allow for aliases.
4.2. The Paradox of "Secure" Branding
The popularity of a messenger is itself a security feature. If an application is known as a "secure" app used primarily by activists or dissidents, simply having it installed can make a user a target. The ideal secure messenger has a user base that is large and diverse enough that its use is not inherently suspicious.
5. The Collective Dimension of Digital Privacy
The most effective digital defence strategies recognise that privacy is a collective endeavour.
Network Effects: An individual's privacy is strengthened when their friends, family, and colleagues also adopt secure tools. This normalises the use of encryption and expands the network of secure communicators.
Plausible Deniability: When a secure app like Signal has a large and diverse user base, its use is less likely to be interpreted as an indicator of sensitive or subversive activity. This provides a "shield of plausible deniability" for those who truly need it.
Shared Responsibility: Security is often only as strong as the weakest link.
The foundation of robust digital communication security relies on adopting end-to-end encryption (E2EE), which ensures that only the communicating parties can decode message content. However, while E2EE protects message content, practical security also demands careful management of features like device encryption and backups, along with the awareness that revealing metadata (who, when, and location) remains unprotected, necessitating a collective approach.
Summary
This paper highlights a significant privacy risk arising from delivery receipts in mobile messaging, showing how specially crafted messages trigger silent receipts without user notification or consent. Attackers can use this high-frequency, stealthy probing technique to extract sensitive private information, inferring user schedules, tracking devices, and launching resource exhaustion attacks.
"This paper highlights that delivery receipts can pose significant privacy risks to users."
Background
Mobile instant messaging services, used by over 3 billion users globally, rely on two types of acknowledgement: delivery receipts (server ack and device ack) and read receipts. While read receipts can often be disabled, delivery receipts cannot be deactivated due to their necessity in the underlying End-to-End Encrypted (E2EE) protocol for upholding forward secrecy. The protocol requires clients to acknowledge successful decryption of messages, meaning delivery receipts indicate success at the destination device level. Prior work showed that delivery receipt Round Trip Times (RTTs) from regular messages could reveal coarse user location, but that method alerted the victim, preventing high-frequency monitoring.
Use-case
The vulnerability enables several adversarial goals, including device fingerprinting, user monitoring, and offensive resource exhaustion. By continuously monitoring independent delivery receipts issued by each device, an attacker can precisely track a user's online status across companion devices, potentially revealing their location or daily routines, such as sleep schedules. Observing relative differences in RTTs allows an adversary to infer device activity, such as distinguishing between screen-on/off states or determining if the messaging application is currently in the foreground. Attackers can also launch resource exhaustion attacks, covertly inflating a victim's data allowance (up to 13.3 GB per hour on WhatsApp) or significantly draining the smartphone's battery.
Future Work
The authors discuss several countermeasures that messaging service operators must implement to address these vulnerabilities, including restricting delivery receipts and improving client-side validation. To prevent RTT-based tracking (activity monitoring), the immediate transmission of delivery receipts should be optional, or the timing should be made coarser by adding noise, such as a random delay. Since E2EE prevents server validation, clients need improved validation mechanisms to properly discard invalid messages (like reactions referencing non-existent messages) that are currently exploited to trigger receipts stealthily. Additionally, inconsistencies in receipt handling across different operating system implementations should be harmonised, or a single codebase should be used to eliminate device fingerprinting opportunities.
You can download the article here.
