Security

Signing in runs Secure Remote Password through Proton’s own go-srp, so your password is never sent to Proton, not even hashed. Your keys are unlocked on your machine with gopenpgp, and everything is decrypted and encrypted here.

What leaves your machine

• API requests to https://mail.proton.me/api over HTTPS, authenticated with your session tokens.
• Encrypted payloads you asked to create: an encrypted message, an encrypted file block, an encrypted event, a key you generate or import for an address, locked so only your account opens it, the locked key a forwarding you accepted adds to your address, and the locked key a forwarding you set up derives for the other address, whose passphrase only that address can open.
• The decrypted body of a message you report with mail messages mark phishing, so Proton’s anti-abuse team can read what was sent to you. Nothing withdraws a report.
• The key to something you report with drive items abuse or drive invitations abuse, so Proton’s abuse team can open it. That key opens everything in what was shared with you, not only the item you named. Nothing withdraws a report.
• The SRP proof during login, which does not reveal your password.
• The verifier for a Pass extra password you set, which Proton checks a password against and cannot read one out of.
• When you change a password or set a recovery phrase: the same kind of verifier for the new secret, and your keys locked again with it. The secret itself does not leave, and the keys are the ones you already had.
• Opening a public link with --link or --shared carries your session, so Proton knows which account opened it, and the owner sees one more visit.
• The key that opens a calendar you publish with calendar settings links create --access full. It travels in the link, and Proton reads those events to serve the feed. A limited link carries no such key.
• The times a booking page offers, and which calendars block them, readable by Proton so it can serve the page. Its title, description and location are encrypted with a key only the link carries.
• Once a day, on an install no package manager owns, a request to GitHub asking which release is newest. It carries nothing about you or your account, and PROTON_NO_UPDATE_CHECK ends it (Updating).

What never leaves: your password, your second password if you have one, your Pass extra password, your key password, and an unlocked private key.

There is no telemetry, and there is nothing to turn off. proton-cli never reports a command you ran, a feature you used, or the fact that you ran it at all. The diagnostic log is written to your disk and read by nobody unless you run proton report and paste it somewhere yourself (Reporting a bug). What is known about how the tool is used comes from counters the distribution channels publish, and is on the site in full.

What you export is plaintext. mail messages export and contacts export decrypt on the way out, so the files they write are readable by anything. Put them where you would be comfortable putting the mail itself. A private key from account keys export --private is the exception: it is written locked with the passphrase you give.

What is stored on disk

The paths are listed under Files on disk. Three of them hold something sensitive.

The session file, one per profile, mode 0600, holds the session tokens and your key password. The key password is stored encrypted with a key that Proton holds and hands out only to a live session, so it is never on disk in cleartext, and revoking the session - proton account logout --revoke, or from any Proton app - makes a leaked copy undecryptable. The file still holds the session’s refresh token, so it is not safe to share; revoking neutralises a leak, it does not excuse one.

The diagnostic log, mode 0600, holds what each run did, written so it can be handed to a stranger: addresses, IDs, paths, tokens, subjects, filenames, search terms and flag values never enter it. --no-log or PROTON_NO_LOG stops it being written (Settings).

The local index, mode 0600, exists only after proton index create and holds a copy of what it indexed: for mail, every message with its subject, its addresses and its body as text; for Drive, the tree and the text of your text files up to 1 MB each. It is encrypted with AES-256-GCM under a key of its own, and that key is encrypted and signed to your account’s keys, so revoking the session makes a leaked copy unreadable the same way it does the session file. proton index delete removes it (Local index).

A file downloaded from a public link

Every file downloaded anywhere else is checked against a hash list its author signed. A public link is served without that signature, because whoever opens a link is outside the share and cannot hold the key that signed it. Each block is still checked against the hash list the link came with, so a file that arrives damaged is refused - but the list itself is Proton’s word rather than the author’s.

Two-factor and security keys

A code is asked for only when the account has one enabled. Security keys work at sign-in on Linux, macOS and Windows; see Security keys for what each platform reaches.

Reducing your risk

proton-cli is unaudited. To limit what that costs you:

• Run it as your normal user, never as root.
• Verify release checksums against the releases page before installing a downloaded binary.
• Keep it up to date with proton update, or your package manager.
• Revoke the session on any machine you lose control of, with proton account sessions revoke or Proton’s own session settings.
• Read proton account security-log list for sign-ins you do not recognise, once proton account security-log enable is on.
• Keep automated use plausible. Proton reacts to volume and rate, and an account flagged for that is an account problem rather than a bug here.

Found a vulnerability? SECURITY.md has the private reporting channels. Please do not open a public issue.