[bad_user]

I think this post from FastMail says it better than I do: https://fastmail.blog/2016/12/10/why-we-dont-offer-pgp/

Here are some arguments:

1. if it's encryption in the browser via a web interface, then it's not secure; the moment a web form asks for a password that can be used to decrypt your data, that's the moment your alarms should go off, because in spite of the claimed E2E encryption, their security might actually be worse than Google's

2. with email you're communicating with the world and the email world is not encrypted; what this effectively means is that ProtonMail keeps your email encrypted only while it is at rest; maybe it's better than what Google does, but they can still see whatever comes in or goes out in plain text and you're still relying on their promise to do no harm

3. ProtonMail needs to use a "bridge" in order to be compatible with email clients; this means that access to ProtonMail is non-standard (e.g. SMTP, IMAP) and therefore you still have the lock-in of Gmail, only it's now worse

4. It creates a false sense of security. If you want real information security, better tools are needed; various chat apps are much better, plus actual GPG ... because the PGP model requires a "chain of trust" that you have to maintain yourself for actual security

[floatboth]

> if it's encryption in the browser via a web interface, then it's not secure

Ehh…

The big difference from native apps is that native apps are often signed by the developer. While with web apps, there's normally only a more "temporary" form of signing, that is, the TLS session.

Assuming the app developers are better at securing their offline signing keys than TLS server keys, native apps with signatures are indeed more trustworthy. (But are they actually better at this??)

However, you can achieve the same kind of signing on the web with a browser extension: https://github.com/tasn/webext-signed-pages (+ SRI and CSP for subresources)

Also, you might be more likely to get malware browser extensions than OS-level malware. Maybe??

On the upside, the web is more auditable by default (of course you can obfuscate JS and WASM just like you can obfuscate anything, but "view source" is still much easier on the web).

> ProtonMail keeps your email encrypted only while it is at rest

IIRC it's also end-to-end between ProtonMail addresses or something?

[bad_user]

The web isn't more audit-able.

The problem is that the web page loads on every request. This means that you, @floatboth, can be targeted with a broken client that leaks your keys next Wednesday between 13:00 and 14:00 and you'll never know it.

A native app is not something that loads every time you open it. And the binary you get is the same binary that everyone else gets and if you suspect something fishy, you still have that binary later for inspection. Compromising an app binary is not impossible mind you, as we could see with fake Apple XCode fooling Chinese developers into submitting infected apps to Apple's store, but it's much, much harder with security conscious users.

Also there's not much difference between highly compiled and obfuscated JS code and binary code. In both cases people start inspecting such apps by sniffing the outputs. Or otherwise it's not such a big jump from JS to assembly for people that do this for a living (e.g. I'm guessing anti-virus companies).

> IIRC it's also end-to-end between ProtonMail addresses or something?

It might be, but encryption that only works between ProtonMail accounts is no longer _email_. It's either a standard, or it's not email and I'm not interested in communicating only with ProtonMail users.

[bartbutler]

1. ProtonMail implements the OpenPGP standard and is fully interoperable with other OpenPGP email systems. 2. The web app is a single page application so it does not reload on every request.

That said, you are correct that the web app is not appropriate when the threat model includes ProtonMail itself (though you can run the web app locally and thus sidestep the problem). The native clients are better suited in that case.