Skip to main content


"Tool allows stealthy tracking of #Signal and #WhatsApp users through delivery receipts"

cyberinsider.com/tool-allows-s…

Another privacy vulnerability caused by the dependency on phone numbers.

In #ArcaneChat (and other #chatmail clients like #DeltaChat) you don't need a phone number (or any private data at all!) to register, so such attacks are simply impossible, keep your family safe, join arcanechat.me

in reply to ArcaneChat

in reply to David Chisnall (*Now with 50% more sarcasm!*)

@david_chisnall by saying "requires phone numbers" I was implying that you can discover people by phone numbers since that is the case in 99% if not 100% of all apps that offer phone number registration, that you can disable this feature is meaningless if it is opt-out and most people will leave it like that, by saying ArcaneChat is immune to this I meant because you can't discover people like that, people must get in contact directly via QR or invite link
in reply to ArcaneChat

So there is no way for anyone to use a public identifier like an email address or similar to reach you?

What do you put on business cards or similar if you want people to contact you? An invite link?

in reply to David Chisnall (*Now with 50% more sarcasm!*)

#DeltaChat is for private chatting, so you normally don't put your link anywhere publicly, you could create a dedicated profile for public interactions tho, which, unlike in signal, it is super easy to do and you can have as many as you want,

and notice the use case I am talking here is family chat, not business and public interactions, that is why I said "keep your family safe" I am talking about family chat solution here

This entry was edited (1 week ago)
in reply to ArcaneChat

#DeltaChat is for private chatting, so you normally don't put your link anywhere publicly, you could create a dedicated profile for public interactions tho, which, unlike in signal, it is super easy to do and you can have as many as you want,


Okay, so your use case for 'private chatting' excludes journalists publishing contact information for whistleblowers? It excludes union organisation? It excludes protest organisation?

I guess that's fine, but maybe don't claim to be operating in the same space as Signal then.

and notice the use case I am talking here is family chat, not business and public interactions, that is why I said "keep your family safe" I am talking about family chat solution here


Then you need to learn about the concept of an anonymity set. If you have one mechanism for talking to your family and another different one for talking to your union rep, it's really easy for a passive adversary to track when you suddenly start using a different mechanism for high-value conversations.

in reply to David Chisnall (*Now with 50% more sarcasm!*)

@david_chisnall
what kind of passive adversary are you talking about here? server, provider, global?

Identifying whether you are using this or that chat profile is not necessarily trivial, especially since the 2.33 releases which introduced multi-relay profiles. A single chat profile can jump between using different relays/hosts.

FWIW we share the recommendation of @arcanechat to split between a public profile (invite link published etc.) and private ones (no publishing).

in reply to David Chisnall (*Now with 50% more sarcasm!*)

> Okay, so your use case for 'private chatting' excludes journalists publishing contact information for whistleblowers? It excludes union organisation? It excludes protest organisation?

> I guess that's fine, but maybe don't claim to be operating in the same space as Signal then.

the ArcaneChat slogan is "private chats for the family" I don't get why you jump angry into my thread to attack, I never said anything about "whistleblowers" whatsoever, please, calm down 😅

This entry was edited (1 week ago)
in reply to David Chisnall (*Now with 50% more sarcasm!*)

@david_chisnall

> rather than just say ‘I don’t understand this attacks but the researchers who published it didn’t bother trying to attack the protocol I use and so I’m sure it is secure!’ That is exactly the attitude to security that makes me distrust DeltaChat.

I don't understand why do you seem so upset, #DeltaChat has received several REAL PROFESSIONAL INDEPENDENT security audits, all listed here: delta.chat/en/help#security-au…
can you provide a similar list of REAL sec. audits for Signal?

in reply to ArcaneChat

I don't understand why do you seem so upset,


Because you're spreading misinformation to score marketing points and spreading misinformation about secure messengers gets people killed.

I don't understand why do you seem so upset, #DeltaChat has received several REAL PROFESSIONAL INDEPENDENT security audits, all listed here: delta.chat/en/help#security-au


So, none after this particular class of attack was discovered and therefore none that include this in the threat model?

in reply to David Chisnall (*Now with 50% more sarcasm!*)

The attack class is not really new though, for Signal "delivery receipts" it is known that they can be used to track when devices get online since at least 2018: anarc.at/blog/2018-07-27-signa…

It is also very similar to "Silent SMS" problem.

in reply to David Chisnall (*Now with 50% more sarcasm!*)

@david_chisnall being careful of claiming that something is "secure" is good advise/critique. Users are easily misled other ways. As to delivery receipts, it's unlikely there is a big problem with #chatmail clients (of which delta chat and arcanechat are two) because you can not cause a delivery receipt from a peer. But there are likely online-leakage issues with the invite protocols securejoin.readthedocs.io like github.com/chatmail/core/issue… that require work and independent audits.
in reply to Delta Chat (39c3)

@delta @david_chisnall
Delta(s). Your design -- separation of chatting logic from transport -- is what will allow to overcome this observation and correlation constructions.
You can swap to different transport, like ASMail from 3NWeb set, it is web-style federation, reducing metadata on servers, and correlations between servers.
And then clients and servers may sit on mixnet, like Nym (say hi to them at 39c3).
in reply to David Chisnall (*Now with 50% more sarcasm!*)

@david_chisnall In Delta Chat there are no device-to-device delivery receipts ("two empty checkmarks" in Signal: support.signal.org/hc/en-us/ar…) and no automatic error responses. There are read receipts, but they require displaying the message, so cannot be silent and are not sent for reactions. There is a known issue with long-living QR codes/invite links, but this cannot be used to probe online status of someone you just happen to be in the chat with, I posted about it here:
support.delta.chat/t/careless-…
in reply to David Chisnall (*Now with 50% more sarcasm!*)

@david_chisnall
Re XMPP:
> And this is impossible to fix without redesigning the protocol because unknown iq stanzas must be forwarded to the client to enable future extension and clients must respond with errors.

I guess the client can still pretend to fail to receive it? Just like responding with TCP RST or ICMP echo-response, technically yes, you MUST respond according to the spec, but in practice you can just firewall it away to slow down network scans.

in reply to l

@link2xt

Maybe, as long as you have a good allow list, because there are a bunch of extensions that do feature discovery by sending an iq stanza and handling an error as a ‘I don’t know what this feature even is’ response. You might be able to get away with ignoring them for people not in your roster, but that would probably break other things in subtle ways.

Pings are a bit different because the sender expects them to be dropped in some cases. XMPP is built around the idea that you have a mostly reliable network once you have connected and stanzas will either be buffered by a server and delivered eventually or delivered immediately, and that they will be delivered in order between two peers. Breaking that will have a bunch of knock-on effects that are hard to predict because it’s such an ingrained assumption in how every higher-level bit of the extended protocol is designed.

@l