On its 10th anniversary, Signal’s president wants to remind you that the world’s most secure communications platform is a nonprofit. It’s free. It doesn’t track you or serve you ads. It pays its engineers very well. And it’s a go-to app for hundreds of millions of people.
When you use a client, you are relying on the client’s crypto implementation to be correct. This is only one part of it and there’s a lot more to it when it comes to hardening the program. Signal focuses on their desktop and mobile clients and they hire actual security professionals and cryptographers (unlike the charlatans in this thread) to implement it correctly.
Having third party clients would not definitively mean the client is bad, but it most likely would break the security model. Just take a look at Matrix’s clients.
Appreciate the link. I still believe in Matrix, even if the client ecosystem isn’t there yet. There HAS to be something to replace discord, the enshitification has already begun.
Excellent point! If I’m sending someone information that could get me killed if it were intercepted by the state, I’d sure as hell want some guarantees about how the other side is handling my data. Disallowing third party clients gives me at least one such guarantee.
You have absolutely zero guarantees, with or without their policy on third party apps. You can not send sensitive information to someone else’s phone and tell yourself it couldn’t possibly have been intercepted, or that someone couldn’t get ahold of that phone, or that the person you’re sending it to won’t take a screenshot and save it to their cloud.
A lot of software nowadays is doing a real disservice to their users by continuing to lie to them like this by selling them the notion that they can control their information after it has been sent. It’s really making people forget basic information hygiene. No app can guarantee that message won’t be intercepted or mishandled. They can only give you tools to hopefully prevent that, but there are no guarantees.
Moreover, this policy does not exclude them from including third-party functionality and warning the user when they are communicating with somebody that isn’t using encryption.
Too many of these apps and services are getting away with the “security” excuse for what is effectively just creating a walled garden to lock users in. Ask yourself how you can get your own data out of these services when you decide to quit them, and it becomes more apparent what they’re doing.
A lot of software nowadays is doing a real disservice to their users by continuing to lie to them like this by selling them the notion that they can control their information after it has been sent. It’s really making people forget basic information hygiene. No app can guarantee that message won’t be intercepted or mishandled. They can only give you tools to hopefully prevent that, but there are no guarantees.
Oh, yes. These “deleted messages”, or these “hidden likes”, or whatever else.
I mean, there are fundamental things and algorithms allowing to create such a system, with blinded keys, ghost keys and what not, only these disgusting cheats have a centralized service where any employee can see everything, yet pretend that they have “a security feature”.
Of course, I fully agree! My point was just that you can eliminate the risk of poorly implemented cryptography at the endpoints. Obviously there’s a thousand and one other ways things could go wrong. But we do the best we can with security.
Anyway apparently third party clients are allowed after all? So it’s a moot point.
Signal doesn’t disallow third party clients, you should always understand the risk when messaging anyone on any platform. See my post here: https://lemmy.ml/post/19672991/13312234
No, if your system can’t support 3rd party clients properly, it is inherently insecure, especially in an e2ee context where you supposedly don’t have to trust the server/vendor. If a system claims to be e2ee, but tightly controls both clients and servers (for example WhatsApp), that means they can rug-pull that e2ee at any point in time and even selectively target people with custom updates to break that e2ee for them only.
The only way to realistically protect yourself from that is using a 3rd party client (and yes, I know, in case of Signal also theoretically reviewing every code change and using reproducible builds, but that’s not very realistic).
Now admittedly, Signal has started to be less hostile to 3rd party clients like Molly, so it’s not as bad anymore as it used to be.
Signal third party clients base off the Signal code base. They just add patches and remove certain dependencies. Also they are often more secure. You logic is from the Apple PR department.
Again, having third party clients would not definitively mean the client is bad. Obviously, if it’s a simple fork with hopefully small patches that are just UI changes, it’s probably not going to harm the security model.
I should have phrased this better in my original post. When I was thinking about third party clients, Matrix and XMPP immediately came to my mind. Not very simple forks. So I’ll phrase this better: “Having non-trivial third party clients is not good for security.” What non-trivial means is left to interpretation though, I suppose.
When you use a client, you are relying on the client’s crypto implementation to be correct. This is only one part of it and there’s a lot more to it when it comes to hardening the program. Signal focuses on their desktop and mobile clients and they hire actual security professionals and cryptographers (unlike the charlatans in this thread) to implement it correctly.
Having third party clients would not definitively mean the client is bad, but it most likely would break the security model. Just take a look at Matrix’s clients.
Appreciate the link. I still believe in Matrix, even if the client ecosystem isn’t there yet. There HAS to be something to replace discord, the enshitification has already begun.
I wouldn’t call it a discord alternative. It is closer to fancy IRC/live forms.
Then again I don’t really use Discord
Excellent point! If I’m sending someone information that could get me killed if it were intercepted by the state, I’d sure as hell want some guarantees about how the other side is handling my data. Disallowing third party clients gives me at least one such guarantee.
You have absolutely zero guarantees, with or without their policy on third party apps. You can not send sensitive information to someone else’s phone and tell yourself it couldn’t possibly have been intercepted, or that someone couldn’t get ahold of that phone, or that the person you’re sending it to won’t take a screenshot and save it to their cloud.
A lot of software nowadays is doing a real disservice to their users by continuing to lie to them like this by selling them the notion that they can control their information after it has been sent. It’s really making people forget basic information hygiene. No app can guarantee that message won’t be intercepted or mishandled. They can only give you tools to hopefully prevent that, but there are no guarantees.
Moreover, this policy does not exclude them from including third-party functionality and warning the user when they are communicating with somebody that isn’t using encryption.
Too many of these apps and services are getting away with the “security” excuse for what is effectively just creating a walled garden to lock users in. Ask yourself how you can get your own data out of these services when you decide to quit them, and it becomes more apparent what they’re doing.
Oh, yes. These “deleted messages”, or these “hidden likes”, or whatever else.
I mean, there are fundamental things and algorithms allowing to create such a system, with blinded keys, ghost keys and what not, only these disgusting cheats have a centralized service where any employee can see everything, yet pretend that they have “a security feature”.
Of course, I fully agree! My point was just that you can eliminate the risk of poorly implemented cryptography at the endpoints. Obviously there’s a thousand and one other ways things could go wrong. But we do the best we can with security.
Anyway apparently third party clients are allowed after all? So it’s a moot point.
Signal doesn’t disallow third party clients, you should always understand the risk when messaging anyone on any platform. See my post here: https://lemmy.ml/post/19672991/13312234
You have no control on the receiving end. Zero.
You do if third party clients aren’t possible? You have control over what client the receiving end is using.
But apparently third party clients are possible, so it’s moot.
No, if your system can’t support 3rd party clients properly, it is inherently insecure, especially in an e2ee context where you supposedly don’t have to trust the server/vendor. If a system claims to be e2ee, but tightly controls both clients and servers (for example WhatsApp), that means they can rug-pull that e2ee at any point in time and even selectively target people with custom updates to break that e2ee for them only. The only way to realistically protect yourself from that is using a 3rd party client (and yes, I know, in case of Signal also theoretically reviewing every code change and using reproducible builds, but that’s not very realistic).
Now admittedly, Signal has started to be less hostile to 3rd party clients like Molly, so it’s not as bad anymore as it used to be.
Signal third party clients base off the Signal code base. They just add patches and remove certain dependencies. Also they are often more secure. You logic is from the Apple PR department.
Again, having third party clients would not definitively mean the client is bad. Obviously, if it’s a simple fork with hopefully small patches that are just UI changes, it’s probably not going to harm the security model.
I should have phrased this better in my original post. When I was thinking about third party clients, Matrix and XMPP immediately came to my mind. Not very simple forks. So I’ll phrase this better: “Having non-trivial third party clients is not good for security.” What non-trivial means is left to interpretation though, I suppose.