I don't understand the hype around end-to-end encrypted software where you have to trust the organization behind the software to not steal your data through their complete control of the endpoints.
However, you have reduced the attack surface to the organisation distributing a signed and compromised version of their software to your phone. This is much less likely than any admin in the company looking at your stuff, or anyone who can hack into the company.
Don't let the perfect be the enemy of the good.
After thinking about it for a bit, I find that argument rather convincing in the case of Signal: very few people would be in a position to add code to the distributed binary without it ending up in the git repo. So with E2EE, we still have to trust the organisation overall, but we don't have to trust any individuals with access to the servers, and the open-source nature lets us avoid trusting any of the individual app developers other than the person/group responsible for producing the final binaries.
It's slightly less convincing in the case of WhatsApp or this GMail thing though. You don't have to avoid a back-door ending up in the git repo, you just have to make it past code review. So in that case, with E2EE, we still have to trust the organisation overall, we have to trust the individuals with access to the app source-code, but it lets us avoid trusting any individuals with access to the back-end.
Still a win I suppose. Just a pretty far cry from how I usually see it advertised, which is more like "thanks to E2EE you don't even have to trust them".
And just to be clear, Signal says that they try to reduce the trust on them to as little as possible. Not zero trust/trustless. They sell "low trust" instead.
I don't understand what "low trust" means. It makes sense to talk about removing trust for individual employees in the organization, but when we're using a client distributed as a binary with no way to verify the source code used to compile it, we're forced to place 100% of our trust in Signal as an organization. Is that "low trust"?
Your messages are only as secure as the least secure part of the network. In an absurd example, that other client could take your messages and publish all conversations straight to Twitter in the public. Effectively rendering the encryption pointless. While this is an absurd example, there are things people do that aren't drastically different, including unencrypted plain text backups.
> I don't understand what "low trust" means.
Trust isn't a binary option of: I trust this person/thing/group vs I don't trust it. There is a spectrum. The question is not "do you trust x?" but "how much do you trust x?" This is more obvious with people you deal with in your daily life. There are people you trust with some things but not others. I am willing to bet that you don't have two sets of people in your life: those that you're a complete open book with and those you are a closed book with. You share different pages with different people and this is okay. Signal's mission is to read as little of that book as possible while maximizing your security and privacy. That is low trust. I'm actually not even aware of a zero trust system in existence. All the ZKPs I know still require a trust in the setup process, so aren't completely trustless. Either way, you still need to trust that things aren't improperly implemented. Even if you check it yourself, you have to trust that you yourself didn't make a mistake. Trust is not binary, but a spectrum. There is no global optima and we need to be aware of the trade-offs being made.
Wait, are you talking about malware clients now? Because the original example was a client which does what its user wants to. Nothing can save you if the human at the other end wants to do something evil with the messages you send them, you don't need to use a modified client to share screenshots on Twitter.
> [The trust thing]
I suppose I don't see what the difference is though. Signal has complete control of the app, which means they have full access to all my messages if they want. Where does the "low trust" come in? How is it different from, say, Facebook Messenger, where Facebook also has access to all my messages?
Not necessarily malware, but borderline malicious. I would consider someone uploading our chats in plain text (even to their backup) a "malicious" actor, even though they are probably naive. The point I'm making here is that modified clients can be harmful to _your_ security and that open sourcing a program makes it easier to modify in a way that does this. There are trade-offs here.
> I suppose I don't see what the difference is though.
I'm sorry, you don't see the difference between a binary outcome and spectrum? There just are very few things in the world that are actually binary. People trying to convince you that they are are typically bad actors.
> Signal has complete control of the app, which means they have full access to all my messages if they want.
Under what mechanism? The upside of an open sourced app is that you can actually verify that they don't have such a mechanism. That's where the low trust comes in. That they show evidence of their claims. They release court documents detailing exactly what they've released to governments[0], in combination with the ACLU. Which now means the ACLU is putting their reputation on the line as well. There's a lot of 3rd party actors that put their reputations on the line here and Signal going out of their way to demonstrate that they have nothing to hide. "Don't trust us, this is all the code here. Check it yourself."
Is there a reason Google and Apple couldn't change their deploy flow to pull from a git repository? As in:
1. Developer pushes to a specific remote (or pushes a specific tag or branch)
2. Apple/Google run the build on their systems, sign it, etc
3. If passed, the app deploys and the published app is annotated with the specific git hash (which can also be displayed in the app store)
For open source, it gives the public verification ability.
For closed source, it is still useful for internal verification. I work adjacent to some mobile teams and most still do builds on a developer's desktop and upload that. I am working towards getting CI for everything, partly to reduce dependence on any one developer's system (eg: I hear things like "Only Tom knows how to do builds to give to Apple, but he's out today") and partly for security. As much as I believe we don't have developers with malicious intent, there's still no way to know that a build uploaded from a developer's desktop really is what's in source control.
Because doing so isn't something they'd realistically care about. They'd still have to maintain the existing flow for closed-source apps (the vast majority of them) that don't want to give outside parties access to their source code, so this would just mean more work for them.
Another big downside is that app authors would not be signing the final product with their own keys. That would have to be done by Google/Apple, so authors would lose a bit of control over future distribution of their app.
[0]: https://developer.android.com/guide/app-bundle/code-transpar...
Take the case of WhatsApp. Without E2EE, you have to trust the platform (Apple) and the people behind the app (Facebook). With E2EE, you still have to trust Apple, but you also still have to trust Facebook, since Facebook controls the endpoint and you have no insight into what it does or if there are any back doors. The same applies to Signal obtained from the App Store or (AFAIK) Google Play. And Apple's E2EE stuff is obviously not adding anything, since we're already trusting them as the OS vendor.
Something like Signal on the desktop is different though. There, we still have to trust the OS vendor, but we and anyone else can inspect the source code, verify that it does what it's supposed to and doesn't have any back-doors, compile it for ourselves, and then we can exchange messages without trusting Signal. In the case of Signal on the desktop, E2EE lets us distrust the Signal organisation, which has value even though we still need to trust our OS and our hardware.
You could argue that we should trust the Signal organisation. That's not unreasonable, but that still makes E2EE no better than normal client-server encryption a la TLS and the promise of a solid no-logging policy.
(We could also discuss the feasibility of verifying that there are no back-doors purely from reading source code and how well a back-door could be hidden. But that's sort of a tangent.)
https://github.com/signalapp/Signal-Android/blob/main/reprod...
E2EE has value in the case where it (at least in principle) allows you to remove something from the list of trusted entities. Signal on the desktop is one such case, where E2EE lets us avoid trusting the Signal organisation.
Besides, they can afford better lawyers than Signal.
It is doable.
Telegram has a procedure you can run to verify the binaries, also from the Apple App Store.
Yes, it requires a jailbroken phone, but it is doable.
You can use another to run it on for daily use.
(I think it's not likely to be the case but if we are going all the way then it is what it is.)
Yes, eventually you'll be unable to install the latest versions of some apps on your increasingly-older-by-the-day version of iOS, but presumably some recent-enough version of iOS is jailbreakable at all times.
I mean different versions of the app can be shipped targeting different iOS versions, in which case it'd be a race.
At this point (attacks can only be done against users of the newest versions of the OS, and you still risk getting caught, squandering the whole operation) I say I cannot see how it is worth it.
(But unlike Signal Telegram also haven't been caught with glaring zero days or caught sending images to anyone except the intented recipient the last fee years.)
Source on this? Signal can't even send messages to users with their phones off. Telegram (like WhatsApp) will buffer the message on the server (to the best of my knowledge) and can relay that message quite some time after. Signal clearly provides E2EE chats and group chats, so I'm not sure why that's stated here. For point-to-point, my understanding is that the functionality is extremely limited here and that you can't actually chat. That's what I found googling anyways. While Signal doesn't have this, there is an open feature request for something like this[0], but traction is often low on topics like these. Maybe if HN users were as passionate on Signal forums as they were here we'd get more of these features? Who knows. Devs may just ignore those too.
> But unlike Signal Telegram also haven't been caught with glaring zero days or caught sending images to anyone except the intented recipient the last fee years.
I'd actually like a source on this. I'm not aware of any Signal zero days... ever. Or hearing about Signal users receiving wrong messages. I have heard about several zero days with Telegram though.
That is exactly what Signal has done for years (if not from the beginning?). It's why there's a distinction between one vs. two checkmarks on a sent message:
https://support.signal.org/hc/en-us/articles/360007320751-Ho...
Even if you trust Telegram's e2e it's not on by default. Secure chats are second class and missing lots of features (plus glitchy, I lost multiple entire chat histories), so almost no one uses them.
I have not seen anyone postin any reason to not trust their end-to-end-encryption, so this shortens to a criticisms of point-to-point-encryption, which is (abd I'm feeling generous here) as about as useful as criticism of postcards.
Note, I'm not going after you but after the HN tradition of trashing Telegram.
It doesn't require breaking e2e either to make an impact, since no one I know uses secret chats on the regular anyway
Durov claiming in 2014 to assist Russian government in fighting 'extremism' (we all know what it means) is enough for me. I couldn't find any debunking, clarification or walking back those words.
As for closed groups I think they claim they don't have access and police have to get someone on the inside.
As for cooperating with Russian authorities in particular, Telegram has a history of open confrontation with Russian authorities, and for a long time had to maintain a proxy network for Russian residents.
Today we also see that both Russians and Ukrainians use Telegram to reach out, but I suspect at least Ukrainians use something else between themselves.
That Russians and Ukrainians use Telegram is the exact issue here! Tons of my fellow Russians and I imagine most Ukrainians use Telegram to exchange statements that literally make them extremists or just criminals in the eyes of Russian gov, the very gov Durov declared collaboration with to get unblocked in the country where TG has the most users, they do it every day and without the impaired secret chats feature.
How do you think the secret chat is impaired?
Point-to-point-encrypted means it can theoretically[1] be read by the vendor (Telegram in this case) or anyone who can coerce the vendor. This is the standard for mail, online banking etc.
The reason for providing both end-to-end-encrypted and point-to-point-encrypted is that point-to-point-encryption is significantly simpler, which makes it easiee to create useful and or cool features.
[1]: vendors can do a nunber of things to make it hard/next to impossible for employees and others to access data, like for example restricting access to user data to service accounts, only allow debugging access in special circumstances and auditing such debugging access.
Telegram used to claim they solve it by sending/storing encrypted data through/in different data centers from the keys, and keeping these days centers in different jurisdictions. Done properly should mean that two or more employees across the company would have to conspire to get access to customer data, or two or more judges in different countries would have to demand data.
But unlike with end-to-end-encryption we have to take their word for it.
My most understanding reading is that you mean Telegram receives the data in plain text at their servers.
That reading implies that they don't do this whole "encrypted data one way, keys another way" thing. (If we know they don't do that I am interested in knowing.)
But a number of people here on HN will read it as "Telegram sends data unencrypted", which is definitely incorrect.
Signal has reproducible builds
https://github.com/signalapp/Signal-Android/blob/main/reprod...
While I agree with the concern here, is there an alternative mass market model in which software can be distributed in a way that ensures no one but the user controls the device? I mean mass market, so the barrier is that my tech illiterate grandma has to be able to install this with the help of my tech illiterate parents.
On both phones the keyboard software "listens" to what you type, how else would it function?
Also, wasn't Zoom sued for bastardizing the concept of "end-to-end encryption" to mislead people?
https://www.businessinsider.com/zoom-ftc-lawsuit-end-to-end-...
They're either stored in your choice of third party service or you can host it yourself if you really want.
I don't see if the private half of the key is shared with the web app to decrypt the cypher text, or if the cypher text is sent to the key service which responds with plain text.
> I also wouldn't be surprised if the shit only works in Chrome.
I don't see any evidence of this in the documentation. I can't think what API it would require beyond the widely adopted fetch API.
> Also, wasn't Zoom sued for bastardizing the concept of "end-to-end encryption" to mislead people?
I don't see any reason to think this is much different from any other end-to-end system. All the mobile end-to-end apps require you trust the code they run on your device. As described this requires you to trust the JavaScript they run on your browser.
> I don't see if the private half of the key is shared with the web app to decrypt the cypher text, or if the cypher text is sent to the key service which responds with plain text.
I checked out the ref for that encryption API. Seems like the service stores the key, and the API exposes encrypt/decrypt calls:
https://developers.google.com/workspace/cse/reference
So yeah, go trust that third-party provider, or if you have the technical skill, set up your own. Since most people would do the former, this is basically back to square one, and to call this "end-to-end" is misleading.
The idea of storing your keys on an Internet-facing server baffles me too. It will 100% get hacked sooner or later.
I'm not sure I agree that this is misleading. Google, who is storing the data, never holds the key. Likewise, the key provider never holds the data. To compromise the data you'd need to compromise both gmail and the key provider at the same time. The fact that organizations are delegating the key management is an implementation detail.
> The idea of storing your keys on an Internet-facing server baffles me too. It will 100% get hacked sooner or later.
I mean you can separate it out. You just need to implement the API on an internet-facing server.