As the other commenter mentioned, your best bet is being selective about which services you use to communicate.
Unencrypted (plain text) is the worst, since data is easy for a third party to sniff (think of it as a wiretap). For example, HTTP and SMS are unencrypted.
Encrypted is a good start, since third parties can’t sniff your traffic, but the server handling your communications can usually see everything that passes through it. For example, HTTPS is an SSL-encrypted variant of HTTP, and services like Facebook messenger are encrypted, but Facebook can still see all of your messages, since it’s stored on their servers.
End to End Encrypted (E2EE) is the golden standard. Only the endpoints (i.e. you and your friend) can see the content of your messages, and all traffic is encrypted in a way that even the server cannot view it. Signal is end to end encrypted, as are many other modern messaging platforms (WhatsApp is E2EE in theory, as is Google Meet, but we can’t verify this ourselves).
Metadata and the comm endpoints is one of the hardest parts to deal with. If an intermediary doesn’t have a pointer to a destination then delivering a message becomes problematic, envelopes without an address tend to sit in bins. It would be possible to simply store messages and allow recipients to poll for them but that gets really inefficient at scale. Plus it creates a central repo where messages sit until retrieved which is a liability in itself.
Things like OTR encryption are interesting as a transient system ad-hoc type encryption for things that don’t need or even want absolute assurance of identity, but if I want to talk to Alice and be sure it’s not Eve then it’s not ideal.
As the other commenter mentioned, your best bet is being selective about which services you use to communicate.
Unencrypted (plain text) is the worst, since data is easy for a third party to sniff (think of it as a wiretap). For example, HTTP and SMS are unencrypted.
Encrypted is a good start, since third parties can’t sniff your traffic, but the server handling your communications can usually see everything that passes through it. For example, HTTPS is an SSL-encrypted variant of HTTP, and services like Facebook messenger are encrypted, but Facebook can still see all of your messages, since it’s stored on their servers.
End to End Encrypted (E2EE) is the golden standard. Only the endpoints (i.e. you and your friend) can see the content of your messages, and all traffic is encrypted in a way that even the server cannot view it. Signal is end to end encrypted, as are many other modern messaging platforms (WhatsApp is E2EE in theory, as is Google Meet, but we can’t verify this ourselves).
Didn’t Signal even work together with them, to implement their protocol?
But anyway, as far as I know, WhatsApp only encrypts message contents, not the associated metadata. So they’re still able to learn a lot about you.
I believe WhatsApp uses the same protocol (or at least the same crypto algorithms), though I’m not sure if they were involved in its development.
Good point on the metadata. Signal has the “sealed sender” thing, which (I think) helps with the metadata problem somewhat.
Metadata and the comm endpoints is one of the hardest parts to deal with. If an intermediary doesn’t have a pointer to a destination then delivering a message becomes problematic, envelopes without an address tend to sit in bins. It would be possible to simply store messages and allow recipients to poll for them but that gets really inefficient at scale. Plus it creates a central repo where messages sit until retrieved which is a liability in itself.
Things like OTR encryption are interesting as a transient system ad-hoc type encryption for things that don’t need or even want absolute assurance of identity, but if I want to talk to Alice and be sure it’s not Eve then it’s not ideal.