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.
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.
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.