> Protonmail with SRP and 2FA where a attack has to pretty tricky stuff but you still get a e2e system is far better then what we have now. Its a far more involved attack to just look at your old emails, and its easier to detect.
Can you explain how this is better than Google End-to-End? (Which isn't completed, I know.)
Or even how it's worth implementing over regular webmail in the first place?
Extensions are obviously not optimal, for the very same reason crypto in JavaScript is not good: timing attacks, cache attacks, optimizations, secure storage (in-memory and on-disk), random-number generation, verifiability, ....
Protonmail suffers from that too. Except it's also subject to key exfiltration. Without an exploit. The server simply promises not to send malicious JavaScript.
It isn't significantly more involved for an attacker who has breached their servers to send malevolent code. It's also not easy to detect.
> We will never have a useable experience for all user if we do not accept compromises.
There are usable end-user interfaces capable of featuring secure cryptography.
Desktop applications. Mobile apps. Browser extensions. Hardware tokens (U2F).
Those can be audited. Inspected. Users can freeze updates.
Trying to implement secure cryptography in JavaScript that is fetched repeatedly from an assailable server is just asking for trouble.
> GPG is already not perfect and we should move away from it anyway
Yes, but that doesn't mean ignoring the advancements that have been made in modern security.
The most appropriate response to securing email is still this: Don't, use a secure messenger; or use out-of-band encryption. It's likely to remain that way forever.
The main benefit seems to be that to read your messages code has to be send to your browser. That is much easier to detect compared to compromise of the server now.
Plus it would have network effects that would benefit normal users.
In theory you could have clients with good guis and all that, these however barly exist and people simply want to use the web for this sort of stuff.
If your answer to solving a issue that billions of people deal with, then "Don't" is just not the solution expet maybe if there is a feature complete replacement.
Sending code to a desktop is easy to detect. Sending code to a non-web-based mobile app is easy to detect. Sending code to a browser isn't even detectable. In practice, no one audits JavaScript. If browsers offered the means to detect changes to cached content, security experts[1][2][3] would be less grim about webpage security.
Encryption done in untrusted JavaScript is security theater. If these websites offered privacy policies claiming to never read your data, like Riseup does, the end-result would be the same. Safer, actually, because deploying unnecessary crypto increases the vulnerability risks.
Recommending these websites is actively dangerous. Journalists and whistleblowers who take these claims of fraudulent security seriously, are going to be killed. Getting them to understand that email cannot be secured in-browser, is the entire point. That if you have important information to protect, you should be moving onto different approaches.
WhatsApp is literally safer than this, and it's more accessible.
Can you explain how this is better than Google End-to-End? (Which isn't completed, I know.)
Or even how it's worth implementing over regular webmail in the first place?
Extensions are obviously not optimal, for the very same reason crypto in JavaScript is not good: timing attacks, cache attacks, optimizations, secure storage (in-memory and on-disk), random-number generation, verifiability, ....
Protonmail suffers from that too. Except it's also subject to key exfiltration. Without an exploit. The server simply promises not to send malicious JavaScript.
It isn't significantly more involved for an attacker who has breached their servers to send malevolent code. It's also not easy to detect.
> We will never have a useable experience for all user if we do not accept compromises.
There are usable end-user interfaces capable of featuring secure cryptography.
Desktop applications. Mobile apps. Browser extensions. Hardware tokens (U2F).
Those can be audited. Inspected. Users can freeze updates.
Trying to implement secure cryptography in JavaScript that is fetched repeatedly from an assailable server is just asking for trouble.
> GPG is already not perfect and we should move away from it anyway
Yes, but that doesn't mean ignoring the advancements that have been made in modern security.
The most appropriate response to securing email is still this: Don't, use a secure messenger; or use out-of-band encryption. It's likely to remain that way forever.