What user-side forensic or metadata remains accessible after using ProtonMail Bridge?
Executive summary
Proton Mail Bridge reduces server-side exposure by providing end-to-end encryption between Proton’s servers and a local desktop client, and Proton states it “never permanently store[s] your PGP keys or decrypted message data on disc” [1]. However, the Bridge application maintains a local database that preserves account- and message-mapping metadata (IDs, address mappings and other sync state) and relies on OS credential stores, so usable forensic traces and metadata persist on the user’s machine even when message bodies remain encrypted on Proton’s servers [2] [3].
1. What Proton promises about ephemeral secrets and decrypted data
Proton’s public materials and marketing for Bridge explicitly emphasize that passwords “never leave your machine” and that the Bridge “never permanently store[s] your PGP keys or decrypted message data on disc,” a claim framed as a core privacy protection for desktop integrations with Outlook, Thunderbird and Apple Mail [1]. This is Proton’s affirmative position: message plaintext and long‑term key material are treated as transient on local storage according to their support and product pages [4] [1].
2. What the Bridge actually keeps: a local database of metadata
The Bridge changelog and source descriptions reveal a central technical fact: Bridge uses one database per Proton account and preserves buckets and ID mappings across address-mode changes, explicitly “keeping metadata for account” rather than destroying it when aliases change [2]. Release notes also reference changes to the default location of database and storage files to avoid conflicts with cache cleaners, which further confirms persistent on-disk artifacts exist for synchronization state and metadata [5].
3. Credential and launcher artifacts under the OS
The official Bridge distribution installs a launcher into a protected system area and integrates with native credential managers—Windows/Mac keychains or Linux secret-service backends—meaning credential material and the means to access Bridge are bound into platform-specific secure stores and installer locations that forensic examiners can inspect [3]. Proton’s wording that passwords “never leave your machine” coexists with this reality: credentials are local, not sent elsewhere, but they are persisted in OS-managed stores [1] [3].
4. The unresolved metadata problem and user demands
Proton community feature requests repeatedly press for encrypting all metadata (senders, subjects, attachments metadata) and point out that Proton does not currently provide “encrypt all metadata” as a zero‑knowledge service, with proponents arguing such encryption would prevent third‑party visibility [6] [7]. Proton has publicly acknowledged this is an area of ongoing research and cited practical tradeoffs—search functionality in the web client being a chief reason full metadata encryption is not straightforward [6].
5. Forensics implication: what an examiner can reasonably recover
Taken together, the sources support a cautious conclusion: while Bridge aims not to permanently store plaintext messages or PGP keys, local forensic artifacts remain—persistent database files that map account IDs, alias mappings and sync state, installer/launcher files in privileged locations, and entries in OS credential/keychain systems [2] [3] [5]. Proton’s public claims mitigate server-side exposure but do not contradict the existence of recoverable local metadata used to keep IMAP/SMTP-compatible clients synchronized [1] [2].
6. Competing narratives and practical tradeoffs
Proton’s narrative emphasizes transient secrets and end‑to‑end encryption for message content [1], while community requests and changelog details highlight that metadata remains a compromise between privacy and functionality—searchability and integration with desktop clients require retaining searchable metadata or state locally [6] [2]. The explicit admission that metadata encryption is “continued research” signals an engineering and product tradeoff rather than a covert policy decision [6].
7. Limits of available reporting and what remains unknown
None of the provided sources give a forensic-level inventory (file names, exact database schema, or specific temporary file lifetimes), so claims about exact artifacts, residual copies in swap/temporary folders, or specific timeline of retention cannot be made from these sources alone; forensic practitioners must inspect installed Bridge instances and platform keychains to produce a definitive artifact list [2] [3] [5].