Meta’s Data: Meta’s WhatsApp Fix for View Once and its Impact on Metadata
TL;DR: Following our discovery and disclosure of Meta’s WhatsApp View Once media privacy issue, WhatsApp has silently updated its Servers (!) to solve this issue. In this blogpost we will dive into the fix’ technical details and discuss its privacy trade-offs, including its impact on metadata exposure not protected with End-to-End Encryption (E2EE).
The “View once” feature is marketed by WhatsApp as a privacy feature, which allows the recipients to view the sent media and prevent media forward, share, copy or even screenshot.
We discovered that View Once protection can be trivially bypassed and responsibly disclosed it to Meta.
Recently, WhatsApp has silently released a fix for this issue. This blogpost presents a thorough analysis of it.
The issue: A brief recap
On August 2024, we had discovered that WhatsApp View Once media feature can be trivially bypassed by using a browser extension that slightly modifies WhatsApp Web app.
The gist of the issue is that although View Once media should not be displayed on the WhatsApp Web client, the media is sent to the client with its only “protection” being a flag that announces it as “view once” media, which is respected by the official client. However, the client can be slightly modified, for example with a browser extension to not respect that flag and allow recipient to forward, share and copy it
We had responsibly disclosed our findings to WhatsApp through Meta’s Bug Bounty program, but when we learned on early September 2024 that the issue is actively exploited by publicly available browser extensions with 10K users, we decided to publicly publish our findings in TechCrunch to protect the privacy of WhatsApp’s users.
On mid-September 2024, Meta had silently released an incomplete client-side fix for the issue that handled some aspects of the issue and broke some existing exploiting extensions. However, since the core issue was not solved, some of these exploiting extensions were able to bounce back, bypass the fix and remove WhatsApp’s View Once protection.
On mid-November 2024, Meta had silently released a mostly server-side fix for the issue that solves the trivial exploitation of WhatsApp View Once in WhatsApp Web.
The Fix
The fix: Timing
On November 19th 2024, we gave a talk on the “View Once” issue in Intent summit.
As we prepared for the talk, we verified the status of the issue on November 12th 2024 and found it still exists.
On November 16th 2024, exploiting Chrome extension users started to complain about issues in the extension.
Therefore, we can conclude the fix was probably deployed mid-November.
The fix: Reproduction
To test the fix we had created a lab setup the consists of multiple devices for Sender and Recipient to reproduce that results. The fix was indeed verified: When we sent a View Once message, it was displayed once on mobile clients and not displayed on Web clients including on modified Web clients that used to display it in the past.
One clue to the nature of the fix is that on some WhatsApp Web clients an unexpected error message appeared.
According to WhatsApp FAQ this error is related to E2EE decryption errors.
In order to look under the hood and see what actually is sent and received on the wire, we used Chrome DevTools to dynamically analyze the official WhatsApp Web client and some open source and Baileys’ based clients that emulate the functionality of WhatsApp Web.
Using a Baileys’ client we saw that the View Once message received on that “Web” client does not contain the E2EE encrypted message, which explaind the error message shown above.
The message does include some unencrypted metadata
The unencrypted metadata consists of (among others):
- IDs: Sender phone number, device, WhatsApp nick and internal WhatsApp IDs
- Message type: “media” and “view once”
The fix: How it works?
So how does the “usual” View Once message reach mobile devices while Web devices get a “censored” message?
As we had shown in the past, WhatsApp is using Signal’s Sesame algorithm to support multiple device. Under the Sesame algorithm, the sending device maintains multiple distinct E2EE encrypted sessions with each of the Recipient devices and the other Sender devices.
This means that if Sender and Recipient have 5 devices each, the sending device will actually send 9 messages on 9 sessions: 5 to the Recipient devices and 4 to the other Sender devices.
Usually this message’s contents are identical, but nothing stops the Sender from sending different versions of the same message on each session, leading to a different view of the same conversation on different devices.
We had inspected WhatsApp web code, but it seemed that the same message is sent on all session to all devices.
Therefore, if the message contains media information when sent, but not when received, the change must happen on WhatsApp’s Server. The Server cannot see the contents of the message as it is E2EE encrypted, but it can observe its metadata that now includes the View Once indicator. When the Server sees that, it can check if the receiving device should handle such View Once messages and if not it removes the message’s E2EE encrypted contents.
The fix: Assessment
- This fix indeed solves the core issue: Recipient devices that should not display a View Once message do not get it. As a result, a trivial exploitation with a modified WhatsApp Web client cannot work.
- The fix still allows other Sender devices that should not display a View Once message to get it. This may pose an unnecessary risk as it increases the attack surface for no reason, since these message are not displayed on such devices. For example, a View Once message might be forensically extracted from these devices by attackers.
- The fix does not solve the issue for modified WhatsApp mobile clients, such as the one shown below. In order to solve that issue a more robust app and device integrity attestation is required and probably a full-fledged DRM solution.
Metadata and E2EE
The fix highlights the known, yet often overlooked, fact that E2EE protects messages’ content but not their metadata.
The brick and mortar analogy for metadata is a sealed envelope that protects the enclosed letter from prying eyes and hands, but gives away the sender’s and recipient’s addresses written on it and maybe some more features such as the letter’s dimensions and weight.
Metadata can seriously harm users’ privacy: For example, WhatsApp server that cannot see the contents of the sender’s View Once message, can still learn that Sender sent to a specific Recipient a view once media on 3 AM. Under some circumstances such information in itself might be enough to start a divorce process.
Obviously, a rogue, hacked or subpoenaed WhatsApp server is part of the user threat model. If that were not the case, and the WhatsApp server could be fully trusted, then E2EE encryption would not be required.
With this fix, WhatsApp traded-off user increased privacy against receiver unauthorized View Once content access, against reduced privacy for unauthorized View Once metadata access on WhatsApp server.
Summing up
As it often happens, there are no perfect solutions and indeed the fix that solves the original View Once privacy issue creates new privacy issues as it increases the amount of unencrypted metadata exposed to the WhatsApp Server.
In addition, the fix does not perfectly solves all issues, as discussed above.
While this fix is not perfect, we still consider it a significant improvement compared to the original starting point.
We are happy that our discoveries and publications pushed WhatsApp into fixing View Once in a thorough manner to protect users privacy.
We hope to continue contributing to the security and privacy of WhatsApp users and those of other apps.
