The Matrix.org network has great potential, but after years of dealing with glitches, slow performance, poor UX, and one too many failures, I’m done with it.
Significant improvements to certificate pinning and validation have been added to all major XMPP clients as a result of this incident, but it should also be clear that hosting a server on infrastructure under control by an antagonist government (see also Signal) is a very bad idea and hard to mitigate against.
So Signal does not have reproducible builds, which are very concerning securitywise. I talk about it in this comment: https://programming.dev/post/33557941/18030327 . The TLDR is that no reproducible builds = impossible to detect if you are getting an unmodified version of the client.
Centralized servers compound these security issues and make it worse. If the client is vulnerable to some form of replacement attack, then they could use a much more subtle, difficult to detect backdoor, like a weaker crypto implementation, which leaks meta/userdata.
With decentralized/federated services, if a client is using other servers other than the “main” one, you either have to compromise both the client and the server, or compromise the client in a very obvious way that causes the client to send extra data to server’s it shouldn’t be sending data too.
A big part of the problem comes with what Github calls “bugdoors”. These are “accidental” bugs that are backdoors. With a centralized service, it becomes much easier to introduce “bugdoors” because all the data routes through one service, which could then silently take advantage of this bug on their own servers.
This is my concern with Signal being centralized. But mostly I’d say don’t worry about it, threat model and all that.
I’m just gonna @ everybody who was in the conversation. I posted this top level for visibility.
For a similar threat model, signal is simply not adequate for reasons I mentioned above, and that’s probably what poqVoq was referring to when he mentioned how it was discussed here.
The only timestamps shared are when they signed up and when they last connected. This is well established by court documents that Signal themselves share publicly.
This of course, assumes I trust the courts. But if I am seeking maximum privacy/security, I should not have to do that.
The infrastructure is under control of an antagonistic government, yes. Hetzner is also technically a private company, but they obviously willingly complied with requests from the German government.
They have live access to all of the metadata and can easily correlate that with phone numbers that Signal stores and shares on request of governments. Just because Signal claims they don’t store anything doesn’t mean that the ones that 100% run all the servers Signal uses don’t access and store anything. You are being extremely naive if you believe Signals BS marketing.
Look, if you run the server you have access to metadata of clients connecting to it. That is networking 101. And that Signal shares phone numbers and connection timestamps is well established by court documents.
The security audits are of the code and encryption algorithm, not the infrastructure.
Signal doesn’t suffer anything worse than DoS if a hostile party controls the central service. That’s its point and role. It’s based on the assumption that such hostile parties as governments don’t like DoS’ing central services, they prefer to be invisible.
For other points and roles other solutions exist. One can’t make an application covering them all, that never happens.
Briar again (I’ve finally read on it and installed it, and I love how it works and also the authors’ plans on the future possibilities based on the same protocols, but not for IM, say, there’s an article discussing possibility of RPC over those, which, for example, can give us something like the Web ; I mean, those plans are ambitious and if I want them to succeed so much, I should look for ways to defeat my executive dysfunction and distractions and learn Java). Except it would be cool if it allowed to toss data over untrusted parties, say, now if two Briar users in the same group are not in each other’s range, but there’s a third Briar user not in that group between them, their group won’t synchronize (provided they don’t have Internet connectivity). If one could allow allocating some space for such piggybacked data, or create some mesh routing functionality, then it would become a bit cooler.
Whenever anybody on the internet tells you to educate yourself, but refuses to provide the information they allude to, they’re lying. They know they’re lying.
Signal has issues, like SVR… which are worth discussing on their own without this weird vague eliteism
Especially the “this has been discussed before” thing, I dunno about other countries and cultures, but in Russia this is the most common obnoxious shit people without arguments and thinking they have authority use.
End to end encryption between clients (also for groups) seems to partly address the issue of a bad server. As for self-hosting, any rented or cloud sevices are very vulnerable to an evil maid. So either in-house hosting or locked cages with tamper-proof hardware remain an option.
Significant improvements to certificate pinning and validation have been added to all major XMPP clients as a result of this incident, but it should also be clear that hosting a server on infrastructure under control by an antagonist government (see also Signal) is a very bad idea and hard to mitigate against.
So Signal does not have reproducible builds, which are very concerning securitywise. I talk about it in this comment: https://programming.dev/post/33557941/18030327 . The TLDR is that no reproducible builds = impossible to detect if you are getting an unmodified version of the client.
Centralized servers compound these security issues and make it worse. If the client is vulnerable to some form of replacement attack, then they could use a much more subtle, difficult to detect backdoor, like a weaker crypto implementation, which leaks meta/userdata.
With decentralized/federated services, if a client is using other servers other than the “main” one, you either have to compromise both the client and the server, or compromise the client in a very obvious way that causes the client to send extra data to server’s it shouldn’t be sending data too.
A big part of the problem comes with what Github calls “bugdoors”. These are “accidental” bugs that are backdoors. With a centralized service, it becomes much easier to introduce “bugdoors” because all the data routes through one service, which could then silently take advantage of this bug on their own servers.
This is my concern with Signal being centralized. But mostly I’d say don’t worry about it, threat model and all that.
I’m just gonna @ everybody who was in the conversation. I posted this top level for visibility.
@Ulrich@feddit.org @rottingleaf@lemmy.world @jet@hackertalks.com @eleitl@lemmy.world @Damage@feddit.it
EDIT: elsewhere in the thread it is talked about what is probably a nation state wiretapping attempt on an XMPP service: https://www.devever.net/~hl/xmpp-incident
For a similar threat model, signal is simply not adequate for reasons I mentioned above, and that’s probably what poqVoq was referring to when he mentioned how it was discussed here.
This of course, assumes I trust the courts. But if I am seeking maximum privacy/security, I should not have to do that.
Signal is under control by the government? 🤔
Their server infrastructure is (run by Pentagon and NSA best buddies AWS).
And that means the government controls it?
The infrastructure is under control of an antagonistic government, yes. Hetzner is also technically a private company, but they obviously willingly complied with requests from the German government.
And what are the implications of that control? It doesn’t mean they can access anything on it. Especially not data that doesn’t exist.
They have live access to all of the metadata and can easily correlate that with phone numbers that Signal stores and shares on request of governments. Just because Signal claims they don’t store anything doesn’t mean that the ones that 100% run all the servers Signal uses don’t access and store anything. You are being extremely naive if you believe Signals BS marketing.
I’d love to see the evidence you have for this.
I don’t believe in marketing. I believe in open source code, security audits, and the entirety of the privacy and security community.
Look, if you run the server you have access to metadata of clients connecting to it. That is networking 101. And that Signal shares phone numbers and connection timestamps is well established by court documents.
The security audits are of the code and encryption algorithm, not the infrastructure.
Signal doesn’t suffer anything worse than DoS if a hostile party controls the central service. That’s its point and role. It’s based on the assumption that such hostile parties as governments don’t like DoS’ing central services, they prefer to be invisible.
For other points and roles other solutions exist. One can’t make an application covering them all, that never happens.
Briar again (I’ve finally read on it and installed it, and I love how it works and also the authors’ plans on the future possibilities based on the same protocols, but not for IM, say, there’s an article discussing possibility of RPC over those, which, for example, can give us something like the Web ; I mean, those plans are ambitious and if I want them to succeed so much, I should look for ways to defeat my executive dysfunction and distractions and learn Java). Except it would be cool if it allowed to toss data over untrusted parties, say, now if two Briar users in the same group are not in each other’s range, but there’s a third Briar user not in that group between them, their group won’t synchronize (provided they don’t have Internet connectivity). If one could allow allocating some space for such piggybacked data, or create some mesh routing functionality, then it would become a bit cooler.
You are very naive if you think that is all the US government can do in regards to Signal, but suit yourself 🤷
Anything that’s been proven/confirmed?
OK, so what else in your opinion can it do?
A lot, but please educate yourself, this topic has been extensively discussed here and in other places.
Thanks for the advice.
This is noise, not an argument.
I dunno what’s the purpose of this comment. I asked for specific things, not for noise.
Whenever anybody on the internet tells you to educate yourself, but refuses to provide the information they allude to, they’re lying. They know they’re lying.
Signal has issues, like SVR… which are worth discussing on their own without this weird vague eliteism
Yes, I know that.
Especially the “this has been discussed before” thing, I dunno about other countries and cultures, but in Russia this is the most common obnoxious shit people without arguments and thinking they have authority use.
Yeah it’s like appealing to authority and social pressure all in one. We already discussed it. Bah.
End to end encryption between clients (also for groups) seems to partly address the issue of a bad server. As for self-hosting, any rented or cloud sevices are very vulnerable to an evil maid. So either in-house hosting or locked cages with tamper-proof hardware remain an option.