Comparisons of XMPP, Signal, MQTT, Tox, Telegram

FWIW I can read about that microG, but when I click the link on ArrowOS I get "Please disable your adblock and script blockers to view this page". I have some non-uncommon adblockers enabled. Nothing special, same what millions (hopefully) others have, too.
 
I read that MQTT's authenticiation security is too basic to be used for secure conversation.


Matrix is basically a proprietary derivative of XMPP.

For open source messaging, it's between Signal and XMPP, depending on which one you're more comfortable with. Tox was mentioned, but its technical aspects are still a question mark.

It appears that XMPP isn't so bad for constrained networks, and with the right extensions and settings, the overhead isn't so overbearing. XMPP still needs learning about to use, and maintaining compatibility for features on different clients/servers isn't always easy. Privacy can easily be confirmed on XMPP. Thread xmpp-basics-security-constrained-networks.77220

SIP/SIMPLE requires a lot of expertise on both ends to know for certain if the communications are secure/private. Many clients don't have this ability by default. Thread how-is-sip-simple-for-an-xmpp-alternative.76331

SIP/SIMPLE and XMPP are the only open source standards for conversation recognized by IETF. OASIS offers its own open source standards such as: AMQP for secure business messaging, and MQTT. A standard is a different classification than a client or provider. Open source standards are meant for inter-organizational use that can be offered by different providers. For instance, many companies have had their own offerings on top of XMPP, some open source and some proprietary: ZOOM, Whatsapp, Jitsi. Google's and DuckDuckGo's offerings of XMPP are defunct. Signal is a client rather than a standard, as it's only offered by its own organization.

If one is looking to host their own communication server or have something that can be interoperable among different providers, then SIP/SIMPLE, XMPP and possibly AMQP are the only ways to go. If wanting a client provided by a single provider, Signal is opensource and has endorsements. Its technical aspects are also written about a lot in publications.

With this understanding, now opensource standards can be compared to opensource standards: Thread opensource-communication-frameworks-xmpp-sip-amqp-mqtt-cap-iax.79474. We can now better evaluate clients, which are under a different classification than standards, for what they are.
 
  • Thanks
Reactions: a6h
The one word I did not see-on-speed-scan in this thread was proxy.

That is what should be between your Instant Messenger and the text readodout of your Message and the text should be associated with the Proxy IP#, not yours.If you're not doing it that way now you are behind the curve of those that do.

They will be using a list of machines with open ports ( 21, 25 80, 110),fr om around the world. Who they belong to of less importance than the Country you want to be from. Use the standard greeting for that country when you enter the room for theatrics and style. (Hej, hola howdy, hi, hallo, etc.)

Nobody is going to pay attention to another automated scan and the first proxy off your machine is the only one that will see your IP, and if they were smart they wouldn't be used as a proxy. Or they are very cagey and hoping you will use a password while using a proxy they set up to sniff for passwords.

I no longer use IM and consider it a Security risk, so I am unfamiliar with every app you listed and how things are done today. But that's the way Agents of Chaos did it back in the day and pretty sure is still done today by those still at large. Using maybe net/proxychains and something like security/proxycheck.

That slightly naive 15 year old girl in the room might be me waiting on a pedophile to play bait and switch on.
 
So, Signal is now using closed sourced components. Omemo is a technology from Signal that was adopted by XMPP.

Telegram agreed to give Russia access to its information in 2020. Telegram was already under question in this thread.

Some on this forum have mentioned Delta, which uses email for an account. Email uses indirect federation, when direct federation would be better to reduce spoofing.
pocketnow.com

Like Whatsapp, Signal just “jumped the shark” and stops caring so much about privacy

Signal changes their policy about being completely open with users and decides to start adding closed-source components to their centralized servers.
pocketnow.com pocketnow.com
pocketnow.com

10 Ways Delta Chat is Better than WhatsApp, Signal, and Telegram

With everyone deleting WhatsApp and switching to Telegram or Signal, maybe there's something better that you haven't heard of yet. Here are 10 ways Delta Chat is better than the others.
pocketnow.com pocketnow.com
 
Well what Signal is doing is in-house development of an anti spam solution which will remain closed source. That is all.

If this is enough to destroy your trust in it, you could still give Swiss made Threema a try.
 
Signal and Telegram had centralized servers, so this made it easier for the companies to change their model.

XMPP and Matrix are both open-source standards and decentralized networks. XMPP is recognized as a standard by IETF: Thread opensource-communication-frameworks-xmpp-sip-amqp-mqtt-cap-iax.79474/. The major issue with XMPP is that Omemo doesn't seem compatible across different clients. SIP/SIMPLE is an open standard for VOIP and text that goes with VOIP.

pocketnow.com

Stop being naive when it comes to things like WhatsApp, Telegram, Signal, etc.

Facebook is breaking promises about WhatsApp, as expected. Learn how to tell if your next messaging app is going to last or will eventually become horrible just like the others.
pocketnow.com pocketnow.com
 
sidetone said:
Some on this forum have mentioned Delta, which uses email for an account. Email uses indirect federation, when direct federation would be better to reduce spoofing.
Click to expand...
What's the difference between indirect and direct federation?


sidetone said:
Signal and Telegram had centralized servers, so this made it easier for the companies to change their model.
Click to expand...
Skype was peer-to-peer, and Microsoft still found a way.
 
Thread xmpp-basics-security-constrained-networks.77220.

Direct federation uses the fewest routes from clients. Each client has a server or uses the same server. These servers connect to each other directly, unless they are both the same server used by both clients. The server manages its own clients. The only potential for spoofing here, is if unicode is used for very similar lettering.

There can be an additional point called the Client Manager (usually on the same location as the XMPP server, that has a client point, where the data goes to the end user's web browser), as a layer for HTTPS. BOSH (Bidirectional-streams Over Synchronized HTTP) was an older method for a Client Manager for using XMPP over a webbrowser. Websocket is the current way for a CM to broweser over HTML5. XEP's (XMPP extensions) have made Websockets better for intermittent connections.

Indirect federation has plenty of connection routes to multiple servers between email ends. There's a lot of potential for spoofing and unsecure entrances between these points.

There was something mentioned about Skype that I recently read. It explained why its use has declined.
 
sidetone said:
Indirect federation has plenty of connection routes to multiple servers between email ends. There's a lot of potential for spoofing and unsecure entrances between these points.
Click to expand...
Which also makes the protocol more resilient and harder to block.
 
Alternate routing availability through indirect federation? It's still less secure, unless all of the points are determined and known to be secured from the start. Signal and Telegram were blocked in some countries, which was mentioned in the article about Delta, though these are centralized rather than any kind of Federated network.

With XMPP (or direct federation), the best way is to use a server that's geographically closer to the client being used on that end. Server to server connections are usually stable, reliable and fast despite distance.

Maybe a better method would be to have 1 alternate or duplicate server for each server for XMPP, which can accept the same client.


On another note, instead of certificate authority (CA) for security handshakes, XMPP needs an opensource standard for secure server negotiations, perhaps on multiple XMPP servers that replaces the CA for that purpose. Perhaps an XMPP extention thats purpose is to replace CA, which is used by trusted sister XMPP servers to verify connections.
 
sidetone said:
Alternate routing availability through indirect federation? It's still less secure, unless all of the points are determined and known to be secured from the start. Signal and Telegram were blocked in some countries, which was mentioned in the article about Delta, though these are centralized rather than any kind of Federated network.
Click to expand...
I'm not sure I agree with your direct-indirect federation taxonomy, and you really shouldn't accept mail from a domain that doesn't use an SPF record anyway. The ability to have multiple intermediate hops as needed adds resiliency and scalability to the protocol.

sidetone said:
On another note, instead of certificate authority (CA) for security handshakes, XMPP needs an opensource standard for secure server negotiations, perhaps on the same machines or location that hosts an XMPP server that replaces the CA for that purpose. Perhaps an XMPP extention thats purpose is to replace CA, which is used by trusted sister XMPP servers to verify connections.
Click to expand...
Well, the Gnupg web of trust didn't work out so well. The CA situation has improved dramatically with the rise of Let's Encrypt. Maybe just a better curated and smaller set of roots will do. In any case, I think the Openssl monoculture is a far bigger problem.
 
XMPP servers are offered free CA's (https://xmpp.org/2009/09/ca-updates/). They were still working on other alternatives (https://blog.prosody.im/mandatory-encryption-on-xmpp-starts-today/), like DNSSEC, Monkeysphere (http://web.monkeysphere.info/) and using manual fingerprints.

I worried about spoofing from emails, and didn't know if an email's domain were spoofed. I know for https, the domain name can't be spoofed as long as the tld and domain name read the same. So, one way to tell is to check if the email address in the inbox has an SPF record?

PGP Web of Trust looks like a good experiment where a lot was learned from signature abuse through overload. I was thinking that only confirmed XMPP servers could be trusted, than other types of servers/applications.

Problems with centralized servers become apparent after reading about them. Direct federation would be better than that, and perhaps Indirect federation is a way. If not, some type of indirect/direct hybrid.

This can be narrowed down to XMPP, Matrix and Delta. IETF accepted standards are a big deal for XMPP, though Matrix claims it learned from other messenger products. Depending on opinion, Signal could still be viable, except for those where a centralized server is blocked.

Here's a good comparison between XMPP and Matrix: https://lukesmith.xyz/articles/matrix-vs-xmpp.
 
Sender Policy Framework records are DNS records that identify the mail exchangers that are allowed to forward mail from a given domain. You should reject and probably blacklist any MXs that don't match the SPF record. Unfortunately, not everyone publishes SPF records.

sidetone said:
Here's a good comparison between XMPP and Matrix: https://lukesmith.xyz/articles/matrix-vs-xmpp.
Click to expand...
Good lord!

Matrix is a metadata disaster.​


It gets worse. Because Matrix doesn't really just exchange individual messages, but because it syncs entire chats to all involved servers, this means that while all messages might be end-to-end encrypted, the conversation metadata is known to all servers, including what accounts are involved, when messages are sent and other account information made public (for example, users can add their emails and phone numbers to their accounts). See more here.


That means that all Matrix servers, especially Matrix.org, has a huge repository of metadata. Although chats are thankfully encrypted, encrypted chat logs are synced between all relevant servers, spreading metadata far and wide, and nearly always back to Matrix.org.
Click to expand...
 
Jose said:
Sender Policy Framework records are DNS records that identify the mail exchangers that are allowed to forward mail from a given domain. You should reject and probably blacklist any MXs that don't match the SPF record. Unfortunately, not everyone publishes SPF records.
Click to expand...
Reason why is quite simple: because take John Doe user as roadwarrior abroad, just sending some mail using a different MX host with that SPF protected company domain name. Mail gets lost.

This should not happen, but in reality it happens all the time.
 
hardworkingnewbie said:
Reason why is quite simple: because take John Doe user as roadwarrior abroad, just sending some mail using a different MX host with that SPF protected company domain name. Mail gets lost.

This should not happen, but in reality it happens all the time.
Click to expand...
Open relays are a thing of the past. They either get shut down or blocked in minutes nowadays. That road warrior must have an account that requires authentication on some private mail exchanger. That MX should either be listed in the organization's SPF record or should only forward to an MX that is.
 
Yes, open relays are a past. But it's entirely possible to put in any sending address into Gmail that you want to use, for example. And some people are just exactly doing that. Also mailing lists are another problem which SPF alone probably breaks, which is why SRS came into existance.

SPF is just one technic which can be used to restrain some abuse of your domain, and keep its reputation high amongst MTAs evaluations SPF records. That's all about it.
 
Signal is a drop-in replacement for SMS (except for communicating to those who don't have Signal). Contacts' phone numbers are needed, so it's only for communicating with those you would give your number to. Although, Signal also allows you to use messaging from other devices which aren't your phone as well. It has ways to prevent or reduce spoofing from other devices. For those without Signal, it seems like texting defaults to SMS.

Line is similar that it needs a phone number to sign up. With this one, a user ID can be used as well as telephone numbers to communicate.

Telegram also needs a telephone number to use the service. IDs or phone numbers can be used for communicating with others. Contacts can be added from a global search of their ID. Telegram is widely used, and while it claims to be highly secure, it lacks security.

Edit: SMS is standard with phones and is used anyway. Signal is an upgrade from that to those who also have the service. That's why its use is limited to those you would share your number with. These 3 applications require phone numbers; two of them can be used without exchanging numbers. Its to give an idea for what kind to use for which purpose.

Late edit: It seems that only 1 piece of hardware is allowed to use Signal at a time.
 
Last edited:
Threema and Session are similar to Signal but don't ask for a phone number.

I don't use Threema nor Signal because they require a phone to be the primary device of any account (you need your phone even to login on desktop) and I don't usually connect my phone to the internet so I want the desktop client to be self-sufficient.

Session looks more interesting to me, but the desktop client isn't ported to FreeBSD yet and isn't available as a web application either. I could probably use it through Linux emulation or in a Linux VM but I like to keep things simple and since I don't have either of them in use for other software I don't really want to set it up just for a messenger.

For my limited instant messenging needs I currently use:

Wire. Despite zero mention of it on its website mostly geared towards business clients, it's actually available as a free personal messenger, you can create an account on https://app.wire.com (or from the phone app). It offers audio and video calls too.

Tox. I like the idea of peer-to-peer messenging as opposed to a system relying on centralised servers, but that isn't a proper replacement for mainstream messengers or SMS since a message won't be sent until both the emitter and the receiver are online.
 
hardworkingnewbie said:
Yes, open relays are a past. But it's entirely possible to put in any sending address into Gmail that you want to use, for example. And some people are just exactly doing that.
Click to expand...
Yes, you can put any email you like in the from: header. That is not a way around SPF. SPF check will fail with forged from: headers.
hardworkingnewbie said:
Also mailing lists are another problem which SPF alone probably breaks
Click to expand...
How?
hardworkingnewbie said:
SPF is just one technic which can be used to restrain some abuse of your domain, and keep its reputation high amongst MTAs evaluations SPF records. That's all about it.
Click to expand...
No, you can also use it to reject messages with a forged from: sender. There's no legitimate reason to do that.
 
hardworkingnewbie said:
Never heared about SRS?
Click to expand...
No, I'd never heard of of that, and reading that Wikipedia page, I'm not surprised. It lists two authorities for this scheme. The first one is a draft standard that expired in 2003 and doesn't mention mailing lists at all. The second one is another draft standard, this time from 2004 (no expiration date) that explicitly says:
SRS must be implemented by all mail servers which forward mail from a domain which does not designate
the sender of that mail in its SPF record. This includes:
• Many servers which support .forward files.
• Third party mail forwarders.
This does not include:
• All mail user agents.
• Most mailing list providers.
Click to expand...
Emphasis mine.

Let's look at actual headers sent by and actual mailing list to me today, in 2022:
Code: 
Received: from mx2.freebsd.org (mx2.freebsd.org [96.47.72.81])
    (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
    key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
    (No client certificate requested)
    by myserver (Postfix) with ESMTPS id 4D5EC21D9A6
    for <me>; Wed,  4 May 2022 20:46:15 +0000 (UTC)
    (envelope-from freebsd-ports+bounces-1867-myemailaddress@FreeBSD.org)
Sender: owner-freebsd-ports@freebsd.org
The sender and the envelope-from are both from the freebsd.org domain. Let's check its SPF record.
Code: 
$ drill freebsd.org txt | grep spf                                                  
freebsd.org.    3600    IN    TXT    "v=spf1 redirect=_spf.freebsd.org"
$ drill _spf.freebsd.org txt | grep spf                                             
;; _spf.freebsd.org.    IN    TXT
_spf.freebsd.org.    242    IN    TXT    "v=spf1 ip4:96.47.72.81 ip6:2610:1c1:1:606c::19:2 ~all"
As you can see, the sending host's IP address is listed in the domain's SPF record. The SPF check passes.

hardworkingnewbie said:
That's what was introduced to overcome those problems.
Click to expand...
What problems?
 
You must log in or register to reply here.
Back
Top