I'm already not wanting to have personal conversations on teams. My tech savvy colleagues and the ones who can be convinced are on signal, where we talk about job offers and relationships. A few others do Instagram, and get to see my art photography. And occasionally I'll bump into someone when we're both in the office and be able to say whatever not looked over by AI. There's a real chilling effect on getting to know people.
Signal and WhatsApp aren't 100% trust worthy though. Why not pick something you can host yourself?
Signal is open source. What's not trust worthy exactly?
1) You need to audit that code, which.. everyone will have to do on both sides of the communication channel.
2) https://signal.org/blog/reproducible-android/
> the Signal Android codebase includes some native shared libraries that we employ for voice calls (WebRTC, etc). At the time this native code was added, there was no Gradle NDK support yet, so the shared libraries aren’t compiled with the project build.
A good answer in my opinion, but it does mean that what you install from the play store is not reproducible and thus can never really be confirmed to be the same as public sources. There are also binary blobs needed for interacting with Google Play.
3) Signal is openly hostile to third party client implementations: https://github.com/LibreSignal/LibreSignal/issues/37 Meaning they have a near monopoly on all signal communications through their client.. and since it's not reproducible, I hope everyone is building from source.
1) Nonsense. If you don't trust other people's code, you're screwed. You put yourself into the position where you have to audit your OS code, your CPU code, code of every driver that runs in your system. None of which you did.
2) Isn't WebRTC open source too?
3) Their code, their decisions.
These are extremely unconvincing and rather shallow refutations.
I expect more of people on this forum honestly.
Taking the core of your argument: "Trust".
The point of E2EE is that we don't trust the network. We put all the trust in the client, something we control. Or at the very least we seperate our concerns. (please refer to this lovely interactive "Tor" diagram by the EFF for what I mean by splitting out concerns: https://www.eff.org/pages/tor-and-https )
Not being able to run your own client is a pretty big problem. At the very least in that case you should expect to be able to run on another network.. Otherwise that's a lot of trust for one entity and it's not different than just using TLS with HPKP/CA pinning
To give a direct refutation to one of your points: "Isn't WebRTC open source too?"
It is, but they're using native libraries which are compiled. Like I said, it's a good argument, but the result is that they don't have reproducible builds.
> Their code, their decisions.
Extremely dismissive, almost to the point of insulting.
It is absolutely not true that they are above criticism because they built something. They've positioned their product as a security product. Thus it will be judged on those merits. There are many pro-signal zealots who will bend over backwards to defend it in all circumstances. It's intellectually dishonest to do so in the face of valid criticisms.
I will shut up when federation is supported, or you can run your own network, or you can bring third party clients.
You need this to be able to trust your client, because the point is to decouple some trust from a single entity.
that's what e2ee is!
> These are extremely unconvincing and rather shallow refutations.
That's not a refutation of my counterarguments at all. It just shows you're frustrated and talked yourself into a corner. We both know you don't audit your OS code, your drivers code, your hardware. All of them can be leaking your secret messages.
> Extremely dismissive, almost to the point of insulting.
Another non-refutation, another frustration, because you have no counterargument.
> It is absolutely not true that they are above criticism
Straw man logical fallacy. I never claimed they were above criticism. Criticize all you want. But expect your arguments disassembled.
> You need this to be able to trust your client, because the point is to decouple some trust from a single entity.
Without auditing your OS, your drivers and your hardware it's pointless. Any of them can leak your messages. Yet you're fine with it.
Oh dear, you definitely chose the wrong person to accuse of not auditing their code.
I'm typing this from my OpenBSD laptop, which, I assure you, I have audited extensively; but that's hardly relevant to this topic.. I just think it's funny that you would assume this of me. I'm also big on system-transparency[0] and micro systems like Oasis Linux[1] which attempt to limit things being able to hide.
Granted, nothing is perfectly secure.
But, again, besides the point entirely.
Your central thesis is that nothing is safe.
Why, then, should I not just use telegram? Or VK, or WeChat?
We have consensus in the HN community that those chat systems (especially telegram) are inherently insecure. Why?
Don't worry, I'll answer for you: Because they do not support E2EE except when specifically asked to, and because they used their own encryption.
This is enough for the security community to decide that Telegram is a bad product(tm).
I'm not arguing in defense of telegram, I'm just letting you know what happens to "secure messengers" under a microscope.
The same criticism has not been levied to Signal, despite them offering no more protection in real terms than HTTPS would. There are theoretical safety-nets but nothing you can concretely audit.
Your argument that "it's their code they can do what they like" holds as much water as an inverted plate, given the context that they've chosen to live under.
So, instead of attempting to talk me down with and Argument from fallacy[2] perhaps you can talk about this point.
[0]: https://www.system-transparency.org/
> which, I assure you, I have audited extensively;
For which I call BS.
Did you audit your OS code, drivers code and your laptop's hardware? We both know you didn't. Why do you make such an obvious lie?
If it's magically not a lie, how exactly did you do it and how long did it take?
OpenBSD is a lot of code, sure, but far from insurmountable, the drivers are few and quite generalised.
I can’t really say how long it took me to read it because it was over a few years of getting curious and diving in, but it wasn’t much.
I’d say if you were to study the code for 8 hours a day it would probably take about 3-5 weeks.
That said: I’m not claiming that I did a full security audit and found all the bugs: I am stating outright that I have read every line of code in the source tree, and the majority of the code that I run from ports, it’s simple enough that you can do that.
And yes; I still get horrified at a lot of the ports; not everything is perfect.
Exceptions to my curious browsing include Chromium and firefox due to sheer complexity, (and I have had reason to dive into those: the tweaks file is fun); and I have read the majority of the GCC code too (which somehow is much less complex and is quite easy to wrap your head around once you’ve read the dragon book than the browsers).
But the OS. Like you claimed. Is not a binary blob, at least to me. I compile it myself, with a compiler I understand, and with code I have read and understand; this is not uncommon in OpenBSD users; the OS is literally designed in a way that is easy to read; because being easy to read means security bugs have less places to hide. (As per the OpenBSD philosophy).
All of the above notwithstanding, I’m writing this message from an iPhone so not everything in my life is so rigorously understood; I’m not a purist, just a curious tinkerer, like most Linux enthusiasts used to be before the ecosystem became a bit too complex to understand for any one person.
You could argue my phone can leak my chats, to which I say: your matter of “trust” comes back, and I don’t think I would trust my phone with my life to not leak my secrets (signal is asking people to trust them with their lives; journalists and dissidents). But I would trust my laptop.