What metadata leaks occur when using ProtonMail webmail compared to an IMAP client via Bridge?
Executive summary
ProtonMail’s webmail exposes unencrypted message headers such as subject lines and standard delivery metadata; ProtonMail’s zero‑access encryption protects message bodies and attachments but not all metadata [1][2]. Using ProtonMail Bridge + an IMAP client shifts decryption to your device and stores decrypted mail locally, reducing server‑side access to message bodies but available sources do not provide a definitive list comparing every metadata field leaked by webmail vs Bridge [3][4].
1. What ProtonMail encrypts and what it does not
ProtonMail implements end‑to‑end encryption for message content and attachments so Proton (the company) cannot read those bodies, but subject lines and some header fields remain unencrypted by design and can be produced if Proton receives a lawful request [1][2]. Proton’s use of OpenPGP/OpenPGP‑style handling means address‑related routing metadata must remain visible for mail delivery, which is why subjects and headers leak in current implementations [1].
2. How webmail produces server‑side metadata
When you use ProtonMail’s web interface, your messages, headers and delivery information necessarily traverse Proton’s servers and their architecture maintains access to unencrypted headers and delivery metadata; privacy‑focused reporting and reviews note webmail retains continuous server access patterns that make metadata available server‑side [5][2]. Reviews and privacy explainers also stress that webmail architectures generally enable providers to index and process metadata for features such as search and spam filtering [5].
3. What the Bridge changes — local decryption and client storage
The ProtonMail Bridge is a desktop application that downloads encrypted mail, decrypts it locally, and exposes a local IMAP/SMTP interface so your client talks to a local server instead of Proton’s servers directly; that moves decryption and plaintext storage to your machine and your client’s storage, reducing Proton’s ability to see decrypted message bodies [3]. Multiple guides and reviews describe the Bridge as the tool that allows traditional email clients to work with Proton’s zero‑access model by performing cryptographic operations locally [3][4].
4. Metadata that can still leak with Bridge
Available sources do not list every metadata field still visible to Proton when using Bridge, but they indicate that headers required for routing (addresses, some header fields) and subject lines are not end‑to‑end encrypted under current standards and so remain potential disclosures if required; Proton can turn over subject lines under Swiss court orders [1][2]. Because the Bridge simply performs local decryption, server‑side logs that record delivery events could still contain routing metadata even if content was never visible in plaintext on Proton’s servers — available sources do not provide a full audit of Proton’s server logging behavior for Bridge traffic [3][4].
5. Practical privacy tradeoffs
Using the webmail interface means Proton’s infrastructure handles more live plaintext operations — convenient, searchable, and feature‑rich but with the predictable server‑side exposure of header metadata and the potential for subject disclosure under legal process [2][1]. Using Bridge shifts plaintext into your endpoint, giving stronger operational control and local storage benefits, but it places trust in your device security and local client practices; reviews emphasize Bridge’s role in reducing server‑side access to message bodies while noting it’s not a magic bullet for every form of metadata leakage [3][5].
6. Competing perspectives and limits of reporting
Security reviewers and privacy explainers praise Proton’s zero‑access model for message content while pointing out the persistent metadata problem — subject lines and routing headers — which is a limitation of current email standards [1][5]. User community discussion calls for encrypting more metadata (subjects, sender names) but Proton’s responses cite technical and usability constraints; Proton has said metadata encryption is an area of research and may be implemented when the technology matures [6]. Available sources do not provide a complete, field‑by‑field comparison of what exact metadata Proton logs for webmail vs Bridge sessions.
7. What to do if metadata minimization is essential
Experts and guides suggest using Bridge plus a locked, secure endpoint and client configuration to minimize server‑side exposure while accepting that routing headers and subject lines remain weak points under current standards [3][1]. For users needing further address‑level obfuscation, community suggestions include aliasing services (e.g., SimpleLogin) to avoid address leakage — noted in Proton‑related summaries — but detailed efficacy and implementation tradeoffs are not exhaustively covered in the sources provided [4].
Limitations: This analysis relies on reviews, Proton community notices and setup guides in the provided set; none of the sources offer an exhaustive audit of Proton’s server logging policies for Bridge vs webmail, so some specific metadata‑by‑field confirmations are “not found in current reporting” [3][6].