jdev - 2025-10-30

> it's going to be a case by case basis, but the default should be if you don't understand something or why someone would be sending it to you, do not respond except that we have a safe and specified response you can always send. because you *do* understand "this is an iq" and there is 100% of the time a safe response to an iq (iq error service-unavailable) ↺

that can't possibly be true, also if it was you still wouldn't want to respond every time what if some remote thing malfunctions and starts sending you IQ requests 100 times per second? You should keep replying forever?

https://googleprojectzero.blogspot.com/2020/08/exploiting-android-messengers-part-3.html is what I was looking for, just a dozen or so of the many vulns caused by exchanging data with attackers without human interaction

Literally everything works this way yes. if you send an HTTP request to an HTTP server it always replies too. this isn't a security hole it's just functioning as intended...

if you send an http server random garbage then no promises. but we're not talking about random garbage we're talking about a valid iq request

> Literally everything works this way yes. if you send an HTTP request to an HTTP server it always replies too. this isn't a security hole it's just functioning as intended... since when? Literally never been the case, unless you think IP blocking and such doesn't work? ↺

literally the advice most are following with AI scraping is DO NOT send a response, just close the connection right? *technically* an RFC violation but still the right thing to do

also not in any way related to what we're discussing here...

blocking is a whole different thign

so you just want me to word it a different way? responses to IQ requests you don't expect/understand should be blocked

But there's no such thing as "an iq request you don't understand"

that's my point

or expect*

at this point you seem to just be ignoring the topic so I'm gonna stop trying to reason with you

if a user blocks someone should the client still respond to their IQs ?

what "topic" ? I haven't changed it from the start

> if a user blocks someone should the client still respond to their IQs ? The client can't even get their iqs in this case ↺

> what "topic" ? I haven't changed it from the start The topic is making a testing script to check that a client behaves sensibly such as by replying to disco info requests and other basic things ↺

>> if a user blocks someone should the client still respond to their IQs ? > The client can't even get their iqs in this case oh you mean the server side blocking, sure if the server supports (btw does a server reply to an IQ from a blocked user since it won't route it?) what about client-side blocking though? eg your server doesn't support or in MUCs ↺

> an occupant wants to send an IQ stanza to another user in a semi-anonymous room, the sender can direct the stanza to the recipient's occupant JID and the service SHOULD forward the stanza to the recipient's real JID. hmm '45 says SHOULD here... what happens if it doesn't? what replies? or does this violate the RFC :)

sure. You could debate what it should do in such a case. But that doesn't change what it will do in the normal case. which means a test script is possible

we talk about different stuff all the time in here, clearly the topic has long since changed from that lol, sure some basic test script could be shared by clients

now back to the "silently and automatically handling or replying to potentially malicious input from internet strangers is dangerous and should be avoided" topic...

I'm starting to think instead of trying to convince people that problems exist I should just write easy to run PoCs and share them publicly... easier for sure, probably more effective

1 / 2 / 3

1st, the reason it triggered me to say something: ``` so not responding can't actually break anything that isn't already broken ```

...pure science, pure wisdom !

now, what about my experiment, and the `fact`,

said some nonce, and while someone could say: - kapad, go to sleep... - ~ 0.16666666666 - or anything

the real results, were: ... (nothing)

So, are we gonna build programs, apps, clients, internet itself the way human feel and act, or we gonna try to change user to act to what some business model wish to ?

kapad, what was the experiment ?

... noboby have to answer anyway, to anything. That is what people do

I'm not sure what you are saying

well, i said: `1/2/3`, but none gave a f*ck to say something, ( i would did the same of course )

if of course say something more interesting, maybe someone answer

so people choose, and react to what they interesting in, and don't feel forced to react to anything

oh right, well obviously I agree, but the RFC doesn't say anyone has to respond to messages, it does say IQs MUST be responded to but yea obviously I disagree

i also think, we sometimes have to define, what is a server HAVE to do, and what a client. while in action things are bidirectional, in the process of protocol there are strictly roles, what is a `server` and what is a `client`. ✏

also, in my nginx, when someone ( probably a python script ) says: `http://server.tld/` i really dont bother and i return a `444` ( empty response/close connection). That human behaviour, have save a lot resources, and in long term the scanning and the crawling rates have decreased. So obvious, maybe not all, but a lot a `playing` scanners dont find me interesting and ignore me from their lists

does my above behaviour, broke things ? Maybe in theory, but in real life what browser in 2025 would did a http request. The only possible scenario is a crawler script. so, really dont care to be polite, or to say `301 https://server.tld' please.... ✏

and in xmpp, especially while people using their mobiles, things are more important, there is bandwidth, people pay. i mean the `official tension` should be sensitive with such things, and not with a `flood the world with stanzas` approach

> does my above behaviour, broke things ? Maybe in theory, but in real life what browser in 2025 would did a http request. The only possible scenario is a crawler script. so, really dont care to be polite, or to say `301 https://server.tld' please.... i still make plain http requests all the time lmao; its definitely not "the only possible scenario" ↺

`flood with stanzas` was an expression a person used some years before, in @disroot room, while try to describe how serious things can be. for example, as in his case, open your mobile and have 1000 messages, and your device crashed. is not a good experience, and i'd expected a `serious` client to `protected` me even if i'm part of shitty rooms...

snit: you should care to use https, even if not something important, i think it would be nice, users build an `ethic` that encryption is not something special, but something simple that i have to use it anyway

also, is cheap in resources, a free of charge for servers

lastly, as of the script that testing things, Yes, it would be nice but not only the users, but also the `xmpp heads` in their site, to take this `script`, and **they** to test the clients they want, their new versions, their features, and publish the result in an official page, so users could select their clients, but also developers advertise their products ( in relation to the script ), and so how serious or not serious they are.

On the other hand, an online tool and `come users leak you data`, it's an approach that personally think that just sucks, is not responsible at all, and dont promote the idea of what xmpp should be or how to be used.

that's all._

here's one: ``` <iq id='jn3h8g65' to='muc@whatever/nick' type='set'> <open xmlns='http://jabber.org/protocol/ibb' block-size='4096' sid='i781hf64' stanza='iq'/> </iq> ``` what should a client do when it gets this ?

cheogram: no response OH NO BROKEN RFC dino: ``` <iq id='jn3h8g65' xml:lang='en' type='error'><error type='modify'><not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/><text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas' xml:lang='en'>unexpected IBB connection</text></error></iq> ``` psi: ``` <iq id='jn3h8g65' xml:lang='en' type='error' '> <error type='cancel' code='403'> <forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>Rejected</text> </error> </iq> ``` ✏

...the protocol says: you should return something

when sent some data over ibb anyway, cheogram is silent again, dino & psi both send: error with <item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>, presumably this means I made them do a lookup, if version info told me their map/database impl told me they had some type of vuln this could get fun, all because these clients are *by default* silently handling messages and responding

i think if the client advertise the xep it should reply, otherwise could ignore.

tested in psi get also the `cancel` response even if both users uses psi and disco list the `ibb`. While in a room that query users is not allowed get the `<text xmlns="urn:ietf:params:xml:ns:xmpp-stanzas" xml:lang="en">Queries to the conference members are not allowed in this room</text>`...

but i would consider a good client: if the client advertise the xep it should reply, otherwise could ignore.

...and after this, a more good client to give user the option to ignore/reject things according to his/her needs._

anyway singpolyma and whoever else might be interested, this is a perfectly fine amount of data to be able to pull from every muc participant in a few seconds and I should just post the source or ? https://www.moparisthebest.com/jdev.xml (I redacted to/from) also trivial to slightly modify the script to send a ~100 byte disco#info to each JID on an interval (a few times a second?) and get a ~2900 byte response constantly and silently, we could call it the secret-muc-participant-battery-and-bandwidth-killer ? 💀

hmm maybe I could grep out all the unique iq examples from all the XEPs and just send them all, could get even more interesting

Info and version lots of stuff expects to work in MUC so yes this seems mostly expected?

It's yet another of the nice things we have today that GC3 proposes to kill due to it being unreliable

Yet GC3 adds nice things in return, like persistent routing to offline participants 🙂

So to me it means some things will change, but we don't have to lose anything permanently. Some kind of negotiation to allow full JID communication seems like a sensible thing to have.

Yeah I'm not meaninging to say the way things are is ideal, since the IQ stuff only sort of works in MUC anyway and is a mess. I'm just thinking out loud about stuff we may want to have an answer for

I think it's not the routing that is the problem. The problem is the invisible automatic responses

> I think it's not the routing that is the problem. The problem is the invisible automatic responses You keep saying this but then you point to responses we want as though they are the issue ↺

and you can still have them if you want them, just not silently with no indication to anyone except when they notice their battery dead or mobile data depleted

but on a different note, clearly much of this info shouldn't be sent at all, client, platform, Linux kernel version? These help attackers and no one else

You're free to not implement that xep if you don't want it 🙂

? you seem to be missing all the points

I'd be happy if you got to the point instead of observing things functioning as designed

and that design is broken and vulnerable and must be fixed

Wrong

It's more a question of where you set your paranoia threshold

> It's more a question of where you set your paranoia threshold 👍 ↺

there are a few distinct problems with some overlap: 1. invisibly+automatically sending data to attackers by default is bad. Instead it should be on a strictly need-to-know basis. If you don't have a *reason* to respond you should not. 2. Sending sensitive personally identifying info should never be done silently and automatically to whoever asks. Both for pervasive tracking privacy reasons, and security reasons (I can just look for people still vulnerable to X and target them) 3. Even if you somehow believe all of the above is fine, it enables quickly and silently draining the battery and data from anyone, silently, with no way to block, by default.

> It's more a question of where you set your paranoia threshold no it's nothing at all to do with paranoia ↺

these aren't some theoretical problems that only the NSA can pull off, it only requires a script kiddy a few minutes to write it from scratch, or if no one else thinks it's a problem I can just release my 30 minutes of work ?

real long term fixes are more important than public MUCs being a living hell temporarily /shrug

> anyway singpolyma and whoever else might be interested, this is a perfectly fine amount of data to be able to pull from every muc participant in a few seconds and I should just post the source or ? > https://www.moparisthebest.com/jdev.xml (I redacted to/from) > > also trivial to slightly modify the script to send a ~100 byte disco#info to each JID on an interval (a few times a second?) and get a ~2900 byte response constantly and silently, we could call it the secret-muc-participant-battery-and-bandwidth-killer ? 💀 being able to ratelimit version queries is probably a good feature ↺

Rate-limiting all responses isn't a bad idea (could be more relaxed with known/select contacts)

also this is a way to spam users without having voice

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?

that's just one of many, playing whack-a-mole blocking one at a time is the wrong approach, the right approach is blocking everything as default, and special casing the allows

> Rate-limiting all responses isn't a bad idea (could be more relaxed with known/select contacts) anyone with your full jid is a select/known contact ↺

that's not right, especially for all the ones sent over muc to your full jid ?

public semi-anonynous muc

As said many times this is generally considered a bug in MUC

what is? who's fixing it and where

GC3 is fixing it

what's it fixing specifically? and only for clients that support GC3 or also current MUC ?

GC3 groups will never route IQ or message to the full jid of a participant

where's the current working spec? I seem to only have https://matthewwild.co.uk/uploads/xmpp-gc3-jan-2025.pdf in my browser history

There isn't a canonical spec right now

regardless in the meantime clients need fixes, and maybe server modules can help out?