Hacker News Reader

Comment by jasonsync | Hacker News Reader

End-to-end encryption protects against the service provider (employees) from easily reading your data. This is the biggest benefit.

Of course the service provider can be compelled by law enforcement to hand over encrypted data. Law enforcement may then either attempt to brute force the encryption key password, or compel the user to provide the encryption key password (typically the account password with end-to-end encrypted services): https://en.wikipedia.org/wiki/Key_disclosure_law

Does ordering you to hand over your password entail a form of self-incrimination or a violation of the right to silence? Would granting police the power to compel passwords cross a line centuries old against forcing a person to speak to build the case against them? https://globalnews.ca/news/5310901/canada-privacy-passwords-...

View on HN

End-to-end using server provided javascript code means that the code can be changed on the fly per user to enable lawful intercept. Plausible deniability only works if the client is encrypting the payload entirely independent of the provider. That would require the end user to be compelled directly and javascript would not be required.

So you're running a local encryption library or app (not relying on server side JS code).

Do you disable auto-update, and risk running a broken version of the encryption library or software, or do you enable auto-update and risk a remote backdoor injection via the auto update?

I disable auto-update and get my software from a computer not associated with me. I compare checksums to copies that friends have and checksums on virustotal.

For linux software, I validate GPG checks of individual packages and of the rpm repo. Both packages and metadata are signed. I get the public key from a non mirror site and compare to keys listed by others.

This does not preclude back-doors, but it means that everyone has the same backdoor as me. I then mitigate dial-home of said programs with firewall rules and selinux. If there is a hard-coded key, it will also affect all the companies and governments using the same software.

Are there cases where company employees are reading your email for some reason other than marketing? Serious question --- I'm not too aware of how and where this is documented.

Your point about being compelled to hand over your key password (email password) is valid and interesting, but I'm inclined to restate my original point: email is not the tool for you if you believe you're apt to be arrested and your communications subpoenaed.

Are there cases where company employees are reading your email for some reason other than marketing?

Technical support / customer service.

Email is not the tool for you if you believe you're apt to be arrested and your communications subpoenaed.

If you do not trust the provider you can still use email securely by utilizing something like PGP

Reply on news.ycombinator.com