E2EE doesn't mean anything if you have the same entity controlling the server as is controlling the endpoints.
If you control both ends of an E2EE communication and they are closed then you gain nothing over normal TLS encryption, you still trust the authority. (Whatsapp is obviously closed and yes, signal can be considered effectively closed as their client is not reliably or reproducably built from public sources and has hidden their agendas before[0]; and even depends on binary blobs from Google..)
I know your favourite closed/walled messenger platform is basically religion at this point: but for heavens sake; please understand that unless you're auditing your clients or you can run trustable third-party clients; then end-to-end doesn't mean anything at all.
If you say something ML thinks is wrong in Teams, you can be fired (at will).
If you say something to your colleague via Whatsapp, the only scenario it can be used against you is if you commit an actual crime with reasonable evidence, they subpoena the records, and FB will be willing to go on record to the entire world as lying about Whatsapp E2EE, all in the name of putting you behind bars.
(Also, maybe we can imagine that products actually do what they do and it is not normal to fear lies and nefarious agenda behind every offering?)
Maybe the implication is that it will leak info to your employer, but I think this is more like a general statement; one that is likely an attempt to discuss why we still put our conversations into the hands of large companies with potentially unknown motives; and the questionable state of using "end-to-end" where one entity controls the network, access to the network and both ends of the exchange.
2) Why not use something you can host yourself
to which a reasonable reply is: network effects; I already have signal/whatsapp/telegram and I do not worry about them sending information to my employer.
Unless your employer is facebook, then I think that's a perfectly legitimate rebuttal, but one nobody is making.
In fact, people would rather argue that signal/whatsapp is the best privacy platform in the universe due to e2ee!
I don't really know who you're arguing against, because I'm with you on the points you address. Why I care that its open is so that when they eventually pull a Microsoft, or Facebook style anti-consumer move, we can fork off and continue on how we see fit. It's about control of our communication.
Using signal is the same as using WhatsApp. Eventually Facebook will buy it.
Other people can audit it. That gives you a fair amount more assurance than non-E2E.
In addition to the theoretical benefits of E2E, I get actual noticeable behavior benefits. I've sent links to a family member on Facebook Messenger that it decided to censor and my messages didn't get sent. This happens to others as well[1]. There are reports of similar things happening with SMS[2]. That doesn't happen with WhatsApp or Signal.
- I don't have enough disposable income and disposable time to self host and then keep up to date some flavour of messaging protocol server.
- Everyone's understanding of this issue is different. It's hard enough to convince technical people to use matrix/element vs signal, vs what ever they already have installed. Non-Technical people will either just ignore you or trust you entirely, I'm not sure which is worse.
- When something goes wrong I have to fix it myself. now I'm 24/7 on call.
- Even If I have knowledge enough to run the infrastructure myself, to compile clients and servers myself, to register domains etc.. I cant understand the source code to identify every possible un-trust worthy thing. even if I could, system security is not just about the code.. what is a trusted architecture to run it on?
It just isn't in any way, by any stretch of the imagination, feasible to self host any messaging service myself, that I want to use with the aim of talking to a wide range of people, from all parts of my life.. When I just want to chat with my work colleagues and arrange to go to drinks, or about their break up, or some other company or whatever..
> 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.
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.
> 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.
A belief you hold strongly because you have never enjoyed the beauty of an operating system code you can actually read I guess: https://github.com/openbsd/src
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.
It's okay to be a fanboy! Evangelism is needed for any great product/company/ideology. But on HN you'll get typically called out for disingenuous or bad-faith lines of rhetoric.
The person above gave you a perfectly reasonable answer to your original question of "What about Signal is not trustworthy?". It'd be kind to acknowledge that they at least have a single iota of merit.
Their code, their decisions is why it's bad. If the decide to start tattling to Microsoft too, what are you going to do? If it's open, we can fork it and move on with your lives. Free and open gives you and me the power to control our own communication.
