jdev - 2025-10-31

hmm. wouldn't that depend on how routing from the occupant-id-ish thingy to your actual clients works? (the supposed guarantee of not routing an IQ to you)

> remember very recently when scammers found out they could send muc invites over muc and many clients would automatically join, revealing their jid to the attacker? imo automatically joining invites is bad behavior anyways... ↺

even if sent directly to the jid

Do you also think automatically showing people messages that are sent to them is bad behaviour? Because from a user PoV these are the same thing

no it's the automatic *response* that is bad

I think *some* automatic responses are fine. E.g. I can see an argument that allowing people in your roster to add you to chats transparently is reasonable.

Clearly automatically joining rooms based on invites from people with whom you have no connection is bad.

yep that's more like consenting to future responses up front

I can see some environments where being in a MUC with someone would be considered similar to having them in your roster, and others where it would be ludicrous to do so.

> Clearly automatically joining rooms based on invites from people with whom you have no connection is bad. Because of the presence leak? ↺

Presence leak, spam, abuse, I think there’s a bunch of reasons.

singpolyma: presence leak and fulljid leak, once you join channel controlled by the attacker

the technique rewtkid and other spammers found for harvesting JIDs was to send invites routed via MUC, knowing that some would be using one of the clients that autojoins, and then obtain the fulljid

even polarian has used that, to find rewt's jid, once

qy: lol, despite doing this himself, rewtkid still uses one of the clients that autojoins?

not certain it was an autojoin but essentially the same idea

> singpolyma: presence leak and fulljid leak, once you join channel controlled by the attacker Good point. That's an actual problem ↺

singpolyma: I've been distressed that neither conversations nor any of its forks even offer an option about invite behavior, for this reason. it seems to be an unthinking emulation of Whatsapp behavior, unfortunately with the side effect of emulating Whatsapp's susceptibility to this as a zero-click attack.

i would assume if i had such a autojoin feature that its limited to contacts in my roster

lovetox: in these clients, currently it works if they somehow sent it to your fulljid

and one way to do that is via unexpected-to-end-user routing via MUC

yes .. MUCs can route invites, but this is well known .. so only accepting direct invites automatically from roster contacts, is probably the safer way

but then you lose the auto member add from the mediated invite functionality

> lovetox: in these clients, currently it works if they somehow sent it to your fulljid I don't think it has anything to do with fulljid. It's a message so bare jid is fine ↺

singpolyma, you confuse sending with receiving

wgreenhouse, talks about receiving, and a message is received to the full jid always

> i would assume if i had such a autojoin feature that its limited to contacts in my roster Even then if a contact sent you 20,000 invites you probably shouldn't join them all ↺

clients need updated to ignore by default any message or iq routed over muc that they didn't expect in that context

not silently and automatically handle them like they would the same request from someone who knows their full jid, which is what seems to be the behavior now

moparisthebest: 20k successive invites is bad, so is silently being joined to just one channel where joining it will subject you to presence flood of 10k participants

so yeah I agree the safe default there is never

ok, but you realize that we cannot throw out every nice feature just because someone could abuse it

especially if the abuse follows no deeper purpose than just annoying a user

lovetox: well, the abuse in this case follows any purpose that can be served by learning the victim's fulljid

what feature is being thrown out?

moparisthebest: auto-following invites

autojoin on invite

from strangers? is that a feature anyone wants lol

all your examples apply also to non strangers

sorry, silently from any stranger in a public muc without being able to tell who invited you or block it?

find me one user that wants this behavior

> wgreenhouse, talks about receiving, and a message is received to the full jid always Yes but sender doesn't need to know your fulljid but then maybe knows it after. Which is a security problem ↺

yes, as said above should be limited to roster contacts

but again don't just fix this one issue with invites, fix the default for muc-routed-stanzas

In general I want to ignore all MUC PM that don't follow a specific format/payload anyway so it's just more reason to move toward that and not support generic MUC pm

MUC PM? not sure how we got to that from IQs

moparisthebest, invite has nothing to do with weird MUC routing, its completely separate to IQ topic

the only IQ i need in MUCs currently is the vcard iq

which should be intercepted by the server and not routed to the user

im fine with ignoring all incoming IQs from Groupchats, im not aware of a single one i would need to answer

Does gajim not have the plugin to show what client other MUC participants are using anymore? 🙂

> MUC PM? not sure how we got to that from IQs Because we switched to talking about invites which are PMs not IQs ↺

invites are not PMs, both messages have a different type attribute

I don't know what you mean? A muc invite is just a message. A PM is also a message. They are both type chat

i dont know a single server that sends type=chat invites

why would it, its not a chat related activity

its a message from a service, it should have type=normal

but its true that the XEP does not mandate a specific type

Direct invites don't come from a service

not sure how we jump now to direct invites, direct invites are even more not a PM, they come from your account jid

but also direct invites mandate no type

in Gajim i also only accept direct invites from type=normal messages

not saying this is right, just went after the examples

then you may not be affected. though I think normal type PM is possible?

a PM is currently defined as Message with - type=chat - from a full jid - has <x> element as child

> The message type SHOULD be "chat" and MUST NOT be "groupchat", but MAY be left unspecified (i.e., a normal message).

again, never saw anyone who sends type=normal, which would be very weird for a chat message

lovetox: gajim sure answers a lot of IQs routed from other MUC users now https://www.moparisthebest.com/jdev.xml

i hate it that this is all so loose defined ..

moparisthebest, i never said we dont answer IQs ..

i said im not against ignoring them because i dont need them

> Does gajim not have the plugin to show what client other MUC participants are using anymore? 🙂 no clients should return client or OS info automatically and silently though (if user consents sure) ↺

moparisthebest, client info is in disco info

> a PM is currently defined as > > Message with > - type=chat > - from a full jid > - has <x> element as child the x element won't necessarily be there, I think you have to basically have a list of all MUCs in memory and check the jid ↺

> moparisthebest, client info is in disco info and shouldn't be, shouldn't be replied to at all in this context ↺

the x element will not be there, then i dont treat it as PM

im not keeping a decade backwards compatibility for a broken feature as PM

> the x element will not be there, then i dont treat it as PM that means you treat it as a message or iq from a full jid that isn't a muc though? Which opens all of these problems, some security, some privacy, ones yet unknown could be worse ↺

i dont get why you are talking about IQ now

what has a IQ from a MUC to do with a Message from a MUC?

a chat message comes in 99% from a full jid, how can this be a security problem if i treat it as such :D

> what has a IQ from a MUC to do with a Message from a MUC? they both need handled the same as each other, ie coming from a nickname in a muc and not a full jid that isn't a muc ↺

they both come from _a_ jid, and thats the end of what they have in common

all i do with a message is store it in my database with certain values

an IQ i check and send an answer, or initiate some other process

> a chat message comes in 99% from a full jid, how can this be a security problem if i treat it as such :D because when a message comes in from a full jid that isn't a muc, you display it as from the bare jid right? "bob@example.org" sent you this when it comes from a muc nick displaying it the same way is wrong: "jdev@muc.xmpp.org" sent you this - wrong "user bob currently in jdev@muc.xmpp.org sent you this" - correct right? ↺

lets assume it would look this way, im eager to learn where the security problem is created

will you try to inpersonate the room and tell me to do something ?

the most basic example is I can spam you incessantly and you have no way to know who is doing it, or a way to block it ?

you can't even report it to moderators because they don't have a way to tell either

scary, you need to find a MUC server that does not add <x>, and a user where the client handles messages this way, and give the user no other means of ignoring the message

and of course the user must really really love that groupchat and not leave

Muc needs to allow PMs, and user must be not able to use debug logs

> a PM is currently defined as > > Message with > - type=chat > - from a full jid > - has <x> element as child I did some testing, my prosody does always add the <x> but does *not* require type=chat, do you rely on that? ↺

but also I don't see how the <x> helps ? it's not added to muc-routed-IQs for obvious reasons so if you have to detect them by looking at the JID anyway why not do it for both ?

iqs don't go in mam so you always know what your mucs are (mostly) when getting one

vs pm can come from mam later

so need the <x/> to be sure

that's a great point thanks

to be clear I sent this: ``` <message type='chat' to='muc@muc.example.org/fourthwitch'><body>test1</body></message> <message to='muc@muc.example.org/fourthwitch'><body>test2</body></message> <iq type='get' to='muc@muc.example.org/fourthwitch' id='info1'> <query xmlns='http://jabber.org/protocol/disco#info'/> </iq> ``` and got this: ``` <message xml:lang='en' from='muc@muc.example.org/thirdwitch' type='chat' to='local@example.org/resource'><body>test1</body><x xmlns='http://jabber.org/protocol/muc#user'/></message> <message from='muc@muc.example.org/thirdwitch' xml:lang='en' to='local@example.org/resource'><body>test2</body><x xmlns='http://jabber.org/protocol/muc#user'></message> <iq id='bXl0b3JyZW50Zmx1eEBidXJ0cnVtLm9yZy8yMkowQXlZQXppR0wAaW5mbzEAIEXgoebf0u4=' xml:lang='en' from='muc@muc.example.org/thirdwitch' type='get' to='local@example.org/resource'> <query xmlns='http://jabber.org/protocol/disco#info'/> </iq> ```

yes i rely on that

Gajim does not store type=normal messages

<message to='muc@muc.example.org/fourthwitch' type='headline'><body>headline 1</body></message> <message to='muc@muc.example.org/fourthwitch' type='normal'><body>normal 1</body></message> <message to='muc@muc.example.org/fourthwitch' type='chat'><body>chat 1</body></message>

all of those, and no type, are routed by the muc no problem, does gajim handle all of them correctly ? what about other clients...

yeah i just looked it up, as long as there is a body, headline/normal -> chat, groupchat -> groupchat

but it would not be wrong to ignore these messages

cheogram does, Dino bug...

most clients are chat clients, so i think its fine to ignore non-chat messages

moparisthebest, there is nothing that says a client needs to handle all types of messages

dino opened a new chat with "muc@muc.example.org" who sent me 2 messages: headline 1 normal 1

> moparisthebest, there is nothing that says a client needs to handle all types of messages I'm the one saying clients should change to by default not handling any messages or iqs routed from muc nicks :D ↺

but thats not what you did there

the resource = nick is only true for type=groupchat

or pm, but then you need the <x>

otherwise the resource is just a resource of a possible client

and IQ

its irrelevant for IQ

because you dont differentiate between bare jids and full jids

its just a JID

which you are going to answer

it's not, you need to detect whether IQs are from muc nicks and handle them specially, mostly by ignoring them

no you dont

depends on what your logic is

i can just say "is jid in my roster"?

no then ignore

i dont need to know if its a muc, a nick or anything

if you do that for 100% of IQs sure, but you don't

not sure what you mean, why cant i do that?

current clients in the wild make assumptions like "if I get a message to my full jid, it's slightly more trusted than one to my bare jid" and that assumption is wrong in public mucs

everything goes to your full jid

you are a client

right that wording was wrong lol

current clients in the wild make assumptions like "if I get an iq, it's from someone slightly trusted since they have my full jid" and that assumption is wrong in public mucs

thats what singpolyma, said i think, i never made that assumption

i just answer all IQs, as the RFC demands

with various content of course, if its a nontrusted entity e.g. with an error

> i just answer all IQs, as the RFC demands and you should not, that's my entire damn point lol ↺

> with various content of course, if its a nontrusted entity e.g. with an error and how are you determining trust ? like I think you are assuming the sender has your full JID, and that's wrong for IQs relayed from public mucs ✏ ↺

Why are you on this assumption

Because wgreenhouse put it an hour ago in this room

?

> i just answer all IQs, as the RFC demands 👍 ↺

>> i just answer all IQs, as the RFC demands > and you should not, that's my entire damn point lol 👎 ↺

In Gajim I check if I have full presence subscription

But that only determines the content of my reply, not *if* I reply

> But that only determines the content of my reply, not *if* I reply 👍 ↺

it should determine both, also you are replying to a bunch of stuff you shouldn't now

*with a bunch of content you shouldn't be sending to strangers

You said that but that's not what the RFC says

And if you mean I answer disco requests I don't consider that private info

Also its very hard to filter, because of pep all servers need your disco

it doesn't matter what the RFC says here, the RFC doesn't cover or know about MUC, and MUC is what introduced IQs-from-strangers, right ?

I'm in full agreement if you want to call this a bug in XEP-0045, but even if we fix it and servers now, clients still need fixed to deal with the issue until the whole world upgrades

ah you mean without MUC a stranger cannot know your full jid? ✏

i didnt even grasp that, i just assumed an IQ can come from everywhere

i mean its just a resource i will not keep it secret at all costs, i need to assume my resource can be leaked, hence anyone can send me an IQ not just a MUC

so i would say MUC did not introduce something new, it just made it more likely to happen

MUC creates a situation where humans feel assured their fulljid is not exposed to non admins, but that's not the case if you use this One Weird Trick

specifically when MUC routes invites that are automatically followed, or sends call initiations that ring

i dont think humans think about fulljids at all

as client it does not matter if MUC exists or not, you need to assume a IQ can come from anywhere

or a message

or a stanza

i cannot follow that mindset at all, as a xmpp developer, i handle stanzas, and i make no assumption from which JID they can or cannot originate

make so assumptions is right, hence all the incorrect handling :P

*no

as a public muc user, I don't want: 1. to be spammed with messages or calls where I can't see who's doing it or block them 2. to have my private data leaked to strangers, some of which is also a security problem in addition to privacy 3. to have my mobile battery and data silently drained feels likely all users expect this no ?

so create a tickets on the server projects

in ejabberd you can disable IQ in MUC already

so I've already PM'd the devs of clients I've found that violate #1 all clients currently do 2 which sucks, imho they should fix it, but in the meantime... I'm going to work on a prosody MUC module that solves 2 & 3 (3 can only be fully fixed on the server), and then release some easy to run PoC's to exploit all the above, if client devs will release fixes *soon* I'll wait until after that, otherwise yolo

just remember that iq requests for vcards need to work :)

moparisthebest: what about when you're being spammed but you can't do anything about it because your client freezes up from the spam

haven't experienced that one yet... how much bandwidth do you have damn

moparisthebest: i'm talking about the client freezing up, not the internet

Cynthia: I've had that happen just from perfectly legitimate presence or MAM spam on joining a big and/or active room

or not spam but rather activity

wgreenhouse: most of it is due to the client logging everything

and writing to disk immediately

I/O bogs down the client massively during activity

yes, database-first is a valid approach in lots of ways but can create this bottleneck I guess

jabber.el currently has a weirdness where drawing the UI and logging stuff are independent

database accesses should at least be non-blocking and done on seperate (async) threads

what i've seen is that the client waits for the database write to finish, then do everything else after

or atleast, cache the stuff before writing it all in one burst

you imagine that a bit easy

usually your disk is not slower than your internet, and also it blends out everything you can do wrong inbetween as client

> i mean its just a resource i will not keep it secret at all costs, i need to assume my resource can be leaked, hence anyone can send me an IQ not just a MUC If your resource leaks your presence effectively leaks though. So some caution is prudent ↺

> as a public muc user, I don't want: > > 1. to be spammed with messages or calls where I can't see who's doing it or block them > 2. to have my private data leaked to strangers, some of which is also a security problem in addition to privacy > 3. to have my mobile battery and data silently drained > > feels likely all users expect this no ? (1) seems like a straw man there's no way in the protocol to do that ↺

> just remember that iq requests for vcards need to work :) Those go to server not to fulljid ↺

> moparisthebest: i'm talking about the client freezing up, not the internet I mean normally machines don't have a big enough internet pipe to serve enough XML to bog down a client ↺

> I/O bogs down the client massively during activity shouldn't... modern disks handle like 4000 mbit and no seek times ↺

>> as a public muc user, I don't want: >> >> 1. to be spammed with messages or calls where I can't see who's doing it or block them >> 2. to have my private data leaked to strangers, some of which is also a security problem in addition to privacy >> 3. to have my mobile battery and data silently drained >> >> feels likely all users expect this no ? > (1) seems like a straw man there's no way in the protocol to do that agree, but not handling messages from MUCs specially has revealed this bug in at least 3 clients I've looked at so far ↺

so not a straw man, not a protocol problem, yes a problem in how many clients do it

Amazingly, not everyone has the latest hardware. Some clients update the database in the same single thread that handles the XML stream, so everything stops for each db transaction - so then it doesn't take much to clog things up, especially when joined to several busy MUCs

theTedd: +1

singpolyma, vcard IQs go to full jid

its just that the remote server choses not to forward it to the client

theTedd: yeah I think the popular Android clients all have ths architecture for one

theTedd, you say this like its some kind of weird application design, this is the most normal application design there is

I said it like it's the cause of the issue. I'm aware of how 'normal' (common) it is; but that doesn't make it a good design.

i dont see how putting things in a thread is any better, you just trade in other problems

mostly problems that people cannot understand any more and hence are reluctant to implement it that way

> its just that the remote server choses not to forward it to the client ... by not sending to the fulljid... I don't see how this is not what I said ↺

its always better to deal with problems you actually understand

singpolyma, moparisthebest, proposed that a MUC forwards no IQ anymore to remote servers

hence also not vcard IQs

what the remote server does with the IQ is irrelevant

it will not get it anymore

> singpolyma, moparisthebest, proposed that a MUC forwards no IQ anymore to remote servers Oh not. Just all iq could go to bare jid instead of the hack where see go to bare and some go to full ↺

Multithreading can be complexity that people don't want to deal with - coroutines can help a bit. And just batching database updates would help with the above issue.

singpolyma, no IQ goes to bare jid, the bare jid is the MUC room

...

how would the server know where to which remote server to root, if you address the IQ to the room itself ..

Not that bare jid. The bare jid of the user

we are talking about mediated IQ requests in a MUC

Yes

there is no bare jid of a user

MUC sends some mediated IQs to fulljid of user and some to bare jid of user

no why do you think that

Because that's how it works

?! and how do you think it decides that?

By namespace. It's a giant hack. Getting rid of this is a major motivation for gc3

thats crazy

so MUCs implement now VCard IQ forwarding :D

i thought the MUC sends it to the full jid, and the users server then simply does not forward it

but seeing the spec, it actually expects a request to the bare jid

are there other xeps that expect an IQ to the bare jid? or is vcard the only one

In any case switching the rule from "always to user fulljid (with some hacks)" to "always to user bare jid (with some hacks)" will probably be a net win

Pep

Disco info about the account instead of the client

I'm sure other stuff. User nickname. I guess that's just pep again

> Amazingly, not everyone has the latest hardware. Some clients update the database in the same single thread that handles the XML stream, so everything stops for each db transaction - so then it doesn't take much to clog things up, especially when joined to several busy MUCs sure, the hardware I was describing is a decade old though. I do agree MUCs should be joined on a seperate connection though ↺