Given Proton Mail’s fashiness coming out of the woodwork, lots of folks are looking at switching away — but they have a reasonable concern: Aren’t Proton Mail’s privacy features special, different from a normal mail provider?
-
scrottie (he/him/they)replied to scrottie (he/him/they) last edited by
@inthehands That doesn't give you privacy on who you are talking to (and also doesn't guard against disclosure after recipients have decrypted email from you) and the whole identity thing is bad as much as some people like key singing parties. But it isn't a black box, and doesn't attempt to do dodgy key escrow like stuff that ProtonMail does. So maybe I'll go put my public key in my profile or something again. "Move discussion elsewhere" is a good idea but it's also often observed that...
-
@inthehands @august As Alex Lindsay pointed out in the latest episode of TWiT (https://overcast.fm/+AAZarRN184U) — in the context of Sonos — trust arrives on foot, but leaves by horse.
-
@tantramar @august
That’s a great quote. -
scrottie (he/him/they)replied to scrottie (he/him/they) last edited by
@inthehands with things like Signal, the platform you're running it on may be the weakest link. Broadcom etc broadband processors are considered back doored even if you install a 3rd party Android fork and trust the 3rd party app store's apk.
-
scrottie (he/him/they)replied to scrottie (he/him/they) last edited by
@inthehands Someone suggested in response to my thread that this might be badjacketing of ProtonMail to shepherd people to less secure things; that makes me wonder if ProtoMail itself wasn't an attack to steer people away from GPG.
-
@inthehands @august don't forget that in the case of using a web interface, you have no guarantees that the JavaScript sent to you is the same JavaScript that was sent to someone else, or even the same that was sent to you yesterday. So if you want to target an individual, you can just ship a special version of the code that includes a line saying "and now send the private key unencrypted to the NSA", and you're unlikely to ever notice.
With downloaded apps such as signal (even signal desktop), this attack is far more difficult to pull off (but not mitigated fully if you want updates regularly)
-
Paul Cantrellreplied to scrottie (he/him/they) last edited by
@scrottie
Bottom line is (1) you •have• to trust someone somewhere if you want secure communication, and (2) there’s basically no upper limit to the amount of paranoia about technology that can find technical justification if you’re willing to speculate.I don’t •necessarily• assume, for example, that Broadcomm is backdoored. Passive void “considered” doing a lot of work there; considered by whom? But if I were, say, doing human rights work targeted by a hostile state actor…then yeah, I would have to start working under the assumption that Broadcomm could be compromised. No upper limit.
-
O [email protected] shared this topic
-
@Tutanota @heymarkreeves @inthehands I have one: what protections do you offer to your users against "Five Eyes"?
-
@inthehands the basic problem with that kind of “encrypted” “email” is that it’s only one of those at a time; it’s either encrypted end-to-end and delivered some other way, or it’s encrypted per-hop and delivered as email. None of those services do both at once. It should be possible to do both at once using GPG or S/MIME, but for that to actually work every provider would have to handle it well, and AKAIK none do.
It still baffles me that banks haven’t been pushing this
-
@inthehands I just wish they could put E2E textareas in the browser. It would be hard to do right and even harder to clearly present UI for, but it could fundamentally Work js crypto can't
-
@mcc @inthehands the issue here is that if the provider can push new javascript code then they can be compelled to push javascript code that leaks secrets (that's what happened to hushmail). you'd need some way to pin the html and javascript code and not allow it to update without user consent
-
@inthehands Email has e2ee since essentially forever. The claim it not being designed for this is a little misleading.
Is it supported well? No! Why? Because the vendors either want your data or promote a different platform for secure communication. -
@bob @inthehands The proposal in the previous post is that browsers allow for textarea elements whose contents are managed by the browser and inaccessible to JavaScript except to extract an encrypted version on teardown.
-
@helge
Agreeing in general spirit, is there an e2ee layer for email that’s part of the protocols, and not a bolt-on like GPG? -
-
@inthehands That made me ask myself: If some smart people were to design a secure, E2E supporting, distributed mail system, how would that look? Maybe some people already have and nobody noticed?
-
Paul Cantrellreplied to Fluchtkapsel last edited by [email protected]
@fluchtkapsel As other replies point out, there’s already S/MIME and GPG.
The thing is:
- Any E2EE is a pain, wrecks UX, and most people don’t care enough to put up with it
- Overcoming the UX challenges is a massive tech + design + org lift
- Large players have little incentive to work on this, and strong incentives againstSo, as usual, it’s not just smart people and the right tech; it’s social systems too.
-
@nazokiyoubinbou @heymarkreeves @inthehands Tuta is not part of the 5 Eyes; we only hand out data if we receive a warrant from a German judge. Plus, all data is end-to-end encrypted and we can't decrypt it. This might also be of interest to you: https://tuta.com/blog/fourteen-eyes-countries
-
@inthehands I know of those, and the security provided by them is only bolted on a system never meant to be secure. There are so many issues: conflating encryption with authentication, insecure by default, key management, no group recipient encryption support with changing members (e.g. mailing lists), additional devices are hard to authorize.
Looking at instant messengers, modern messengers like Signal or WhatsApp solved a lot of the issues of their predecessors. I'd like to know how mail would look if it were to be designed today with all we know.
-
@fluchtkapsel @inthehands This is like saying Signal is bolted on IPv4 which was never meant to be secure. Sorry, but this is non-sense. Both PGP and S/MIME are perfectly viable and proven standards to provide proper E2EE.
But as usual standards have to be *implemented* and made usable. E.g. Apple has done the former, but didn't invest in the latter.
It works for Signal and WhatsApp because they are silos. That's not necessary w/ email.
