Earlier quoted context omitted.
Good points, but email is so entrenched it might be easier to slowly fix the issues rather than throw it all out.
A large problem is that the companies with the money to address the issue will only do so starting from a position of a walled-garden rather than a system like email that in principle is open to anyone's mua/mailserver? We have a proliferation of communication apps that don't talk to each other because each of the capitalistic driving forces wants to kill every other app so there's wins (even if there app is much wor…
Convenient End-To-End Encryption for E-Mail
131–140 of 190 posts
Re: Convenient End-To-End Encryption for E-Mail
#132Earlier quoted context omitted.
I have colleagues and students that don't use smart phones. As much as I agree with your sentiment, the unfortunate truth is that right now there isn't a good drop in replacement that we could move to. Signal is drop in for WhatsApp and I can tell everyone I talk to on WhatsApp to just contact me on Signal instead. What do I tell people to move to from EMail?
WhatsApp is an ok substitute for Email in my opinion. Sure, it is not open source and but federated. Signal, Wire, Matrix, etc should catch up in the next years. What do you need from Email that a messenger lacks?
Re: Convenient End-To-End Encryption for E-Mail
#133Unpopular but very probably true fact: email can't practicably be made secure, and people should stop trying. Email is itself archaic, and there aren't good reasons people should use it for routine peer-to-peer communications that need secrecy. Why? Because: * It's default-plaintext. We don't generally love the way websites ensure they're viewed securely, but email doesn't even have the basic mechanisms HTTP has to p…
Re: Convenient End-To-End Encryption for E-Mail
#134Earlier quoted context omitted.
> It's that we should stop using email pretty much altogether. Like I said: it's archaic Sorry but have you ever used Signal or any other IM to send anything longer than a few sentences? Email can be as long as you want, and it is totally appropriate when you want to write a longer document.
Yes, you can write as long a message as you want with signal. There are desktop clients. You can attach files. Or voice messages. Or use it to call them. Or video chat them. It’s a crazy robust full featured incredibly secure communications system.
You mean the ones with Electron, using 5% of your CPU idle, requiring you to have first registered your smartphone with it before it can even work? That's not what I call a functional desktop client.
Re: Convenient End-To-End Encryption for E-Mail
#135Earlier quoted context omitted.
> Lose that key, ever, and not only is every message you send in the future unsafe, but every message you've ever sent in the past is too. That's a terrible property for a secure messaging system. That's false. There are mechanisms for lost keys revocation. This is already a solved problem. > Email leaks metadata. In fact, some of what we call email "metadata" isn't even metadata --- stuff like subject lines are simp…
> That's false. There are mechanisms for lost keys revocation. This is already a solved problem. This is very dangerously wrong. Revoked keys decrypt old data just fine. Revocation is advisory. Your attacker will choose to disregard that advice and decrypt anyway. > And Email has a lot more benefits than your typical IM - it's a standard after all and can be used every everyone on Earth, you don't need to rely on any…
As long as an email leaves from your computer in encrypted form, what is the point of failure as long as you are careful with your private key?
Re: Convenient End-To-End Encryption for E-Mail
#136Earlier quoted context omitted.
I love signal and kinda-sorta agree, but a) Right now Signal is oriented around your hpone # and while most people have phones, they come at a cost, are less easy to acquire than an email address, and much less anonymous b) Signal (and slack and so on) organize conversations around individuals and groups, rather than around subject. That's OK for personal contacts (with whom you have conversational context) but not s…
Signal != Signal Protocol. I like Signal and prefer it to the other applications, but Wire (for instance) does not need your phone number.
Re: Convenient End-To-End Encryption for E-Mail
#137OPSEC is not retroactive.
Re: Convenient End-To-End Encryption for E-Mail
#138Earlier quoted context omitted.
> Most email users get their email from a website. I'd argue thats not the case. Business users are likely still using outlook/etc. Personal users are likely using their smart phone for email. Also by what standard is pgp "the most popular". Its popular with technical people sure, but there is fuck all support in commercial mail clients. S/mime is supported, and due to ca roots, doesnt require you keep using the sams…
Thunderbird and apple mail are both very popular clients that support PGP via plugins.
It's usually months after a macos/mail.app update before the plugin works again.
Theres no equivalent option for iOS. There are alternative solutions but nothing as seamless.
S/MIME is supported out of the box. For bonus ease of setup, I can install the current private key + cert pairs I need with a single provisioning profile.
Re: Convenient End-To-End Encryption for E-Mail
#139Unpopular but very probably true fact: email can't practicably be made secure, and people should stop trying. Email is itself archaic, and there aren't good reasons people should use it for routine peer-to-peer communications that need secrecy. Why? Because: * It's default-plaintext. We don't generally love the way websites ensure they're viewed securely, but email doesn't even have the basic mechanisms HTTP has to p…
Re: Convenient End-To-End Encryption for E-Mail
#140* https://autocrypt.org/examples.html
Basically you include your public key in a "Autocrypt:" header line added to all messages you send out. Then encryption transparently happens.
So we give up some protection against MITM attacks but get protection against passive surveillance for people who are not willing or able to participate in a web of trust. All and all a good idea. Because this works with standard OpenPGP messages it would be good if we could tell what level of protection we were getting when we view a message.