This title is the definition of sensationalism and only by reading the article do you find the truth: "Their tests uncovered no major issues or security vulnerabilities". This is a bad look for them and I'm wary of their company now...
Using openssh as an example, would you say it's secure when you're using public keys for the authentication? Their track record seems pretty good for the last years, but there might still be uncovered vulnerabilities, could it still claim to be secure?
Nothing at all; it's a broken model. The server can at any time start serving malicious payloads [0]. The server hosts your mail but they also serve the webapp. The clientside decrypts the mail, but the server hosts the client code...
It's a fundamentally flawed idea, trying to retrofit encryption into email in this way, when the server essentially has to hold all of your mail. In this case, the only thing that would make me feel secure in using it, is a third-party OSS client that downloads the mail without using the webapp, using only client-side code. And even then, of course, the mail can simply just be not encrypted when being ingested by Proton. So even then I wouldn't really trust it without external encryption like PGP. In which case, why bother?
To be clear I do use private email services (protonmail, tutanota) but I am simply not going to fall for the illusion of guaranteed privacy; I just trust that they are what they say they are. They are still a better option IMO than something like Gmail, but I don't think they're a silver bullet.
[0]: If you think this is unlikely, see this: https://news.ycombinator.com/item?id=25337507
[0] https://mullvad.net/en/blog/2019/6/3/system-transparency-fut...
If you do trust the server then it can be acceptably secure.
What is actually snake oil, and distressingly rarely realised as such, is first-party end-to-end encryption. That’s what sodality2 is actually talking about. And when you stop and consider it in this light, you realise that the significant majority of stuff that’s advertised as having E2EE is first-party and thus, to put it mildly, not robust.
In the context of email, here’s Fastmail’s take on it: https://fastmail.blog/advanced/why-we-dont-offer-pgp/.
True, and I call this threat model "Beware Each and Every Fetch" (BEEF) in contrast to the more common TOFU model (although if you trust a desktop app to auto-update itself then these two models might not be all that different).
In any case, I think you're being a little quick to dismiss the idea of server-hosted applications. It's true that browsers don't natively have a nice way of pinning specific versions of a web app, but there is the clever hack of SecureBookmarks[0] (if you're prepared to sacrifice the UX), or, more realistically, you can pin the web app version using some sort of browser extension.
Examples of the latter include the Signed Pages extension[1], and Code Verify[2], which is the result of a collaboration between Meta and Cloudflare (for securing the WhatsApp Web code, currently, but should eventually support other sites like Proton's too). Of course, it would be much better if this capability was natively included in browsers themselves, but hopefully adoption of this technology will pressure browsers and standards bodies to take ownership of this.
[0] https://coins.github.io/secure-bookmark/
https://en.wikipedia.org/wiki/Evaluation_Assurance_Level
Proton is claiming something similar to EAL4, which is not secure, there is an assurance that not all trained reviewers can find a vulnerability. Openssh is a little less secure than that formally, but has more trained reviewers informally, which probably cover some parts extremely well and other parts sparsely.
here’s a maybe wild take, uh, never?
The security auditors themselves would never actually word it like that in their reports, because the statement implies a degree of certainty that cannot really exist.
Here's an example of what the auditor's actually said:
"Auditors identified two low-severity vulnerabilities. Additionally, five general recommendations were reported. At the same time, we confirm that no important security issues were identified during the pentest."
There's a reason that audit reports will never say outright that something is "secure". They may say something like "strong and effective security measures are in place", but that's a very different kind of statement.
I think the article itself is great but the headline just falls on the wrong side of being a bit hyperbolic and seems to be optimised for marketing impact over accuracy.
You can write all of the tests, you can get all of the audits, but there’s nothing that’s going to stop a 13-year old polish kid from mucking about in the guts of your tech. Security isn’t a promise you can make in absolutes, at some point you have to ship and you hope that you did everything well enough that there’s no low-hanging fruit.
There’s no such thing as a secure system, only systems which are more expensive to compromise.
Typically: don't do that.
Nevertheless, if you insist: you can claim a certain abstraction of a system guarantees certain mathematically expressed requirements cannot be violated by a certain attacker model once you've formally proved that.
Of course, all implementations have implementation details which violate the abstraction, your mathematically expressed requirements may not fully capture your intentions, and in practice, an attacker may have additional options that your model doesn't consider. But hey, now you can truthfully claim that "the system" is "secure" - for some values of "system" and "secure".
It does build confidence in the security to perform security audits.
Have they proved the non-existence of bugs? Nope. But the title is also not the complete opposite of reality, which is what their competition seems to doing.