LOL no it's not.

Yeah it's like appealing to authority and social pressure all in one. We already discussed it. Bah.

The argument has always been, if when chat rooms are public, anyone can join and start logging the chats, encryption does nothing.

It has the ability to connect over TLS, but that's about it.

I loved using it for its simplicity, except when using all the different flavours of nick registration (Q, NickServ, ...).

The clients are pretty slick now too, such as Cheogram or Monocles

I wouldn't call either of those, or any other XMPP clients "slick" and it's my biggest complaint about the protocol.

The argument has always been, if when chat rooms are public, anyone can join and start logging the chats, encryption does nothing.

It has the ability to connect over TLS, but that's about it.

I loved using it for its simplicity, except when using all the different flavours of nick registration (Q, NickServ, ...).

What's the protection in the clients assuming compromised infrastructure, like e.g. in https://notes.valdikss.org.ru/jabber.ru-mitm/ ?

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.

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.

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.

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.

They do have reproducible builds for android though? https://signal.org/blog/reproducible-android/

They can't for iOS because it's just not a feature there

Else, there's Molly you can use, but yea, Signal doesn't like it

Signal's reproducible builds are broken: https://github.com/signalapp/Signal-Android/issues/13565