Hacker News new | past | comments | ask | show | jobs | submit login

Private key required in the browser is bad. However if we had a system where those people that want or care can key their keys offline (or on a Smartcard) while those that don't want.

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.

We will never have a useable experience for all user if we do not accept compromises. I would prefer if everybody of my family was on some system like that, compared to gmx or yahoo.

There is a lot more you can do to protect the client from the server as well. Keybase is doing some interesting stuff in that direction.

We just have the change our assumption of what it means if a email arrives encrypted with GPG.

GPG is already not perfect and we should move away from it anyway, again, Keybase is offering some interesting steps in the right direction.

Steps on a long road.




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


I have not look at google end to end.

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.

[1] https://www.schneier.com/blog/archives/2012/08/cryptocat.htm...

[2] https://www.nccgroup.trust/us/about-us/newsroom-and-events/b...

[3] https://rdist.root.org/2010/11/29/final-post-on-javascript-c...




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: