XSF Discussion - 2022-05-25

hi, what's the status of https://xmpp.org/extensions/xep-0424.html ? It's in last-call which is supposed to be ended since 2022-01-04…

ping jcbrand ^

https://logs.xmpp.org/council/2022-01-05?p=h#2022-01-05-fa0ce69fd8b2d0be

Zash: Thanks. The XEP should not be updated to remove the last-call notice then?

Maybe, ask the editor?

right, I've let a note on editor@

jcbrand: any plan to update this XEP? I'm asking because I'm about to implement it.

goffi: AFAIK people didn't like the `<apply-to>` wrapper. It's already implemented in Converse and Gajim AFAIK. I've been meaning to study people's feedback and make adjustments but haven't found the time. Mainly because IMO it works well and I have many other things on my plate.

Probably one could get rid of `<apply-to>` and just have `<retract>` like we have for `<correction>` and then it might get accepted, unless there's something I forgot.

jcbrand: I see, thanks. Well I'll implement in current state, and will adapt when necessary.

jcbrand, XEP-0424 is also implemented in SiskinIM and BeagleIM, and it works as expected

Ah cool, good to know

how do implementations behave is someone smuggels in a message with an origin-id that is identical the origin-id of a previous message that got retracted? ✏

abolish origin-id!

halt and catch fire

in our case, we are accepting those, but during lookup we are looking for the newest message with matching origin-id

Andrzej, so I can un-retract a message by injecting a newer message with a duplicate origin-id?

no, it would result in a new message

only further references would be related to the new message

how do you treat LMC on a retracted message?

semantically, a message with the same origin-id should be treated as a duplicate of the original message, except when they have different stanza-ids. So I suppose it is safe to ignore everything with a seen-before origin-id.

The other part of the question is about "operator precedence" of message-modifying messages. Does LMC beat retraction? Does moderator retraction beat LMC?

Depends on what is received first? In any case, LMC on a retracted message is moot, since the message has been retracted

jcbrand: what about: I send something obscene, the message is retracted by mods, I edit it to remove the obscenity?

It's already retracted, so your correction can no longer be applied

TBH, I'm not sure how much I've tested such edge cases, but that's what I would expect

i.e. retraction has precedence over corrections

should perhaps be mentioned in the XEP

I'm pretty sure that if message would be retracted in my clients, you wouldn't be able to correct it ✏

No, but a cilent that doesn't support retractions could allow it

I am still very skeptical to reference previous messages by origin-id, as opposed to using stanza-id, i.e. the securely combined values of the stanza-id 'by' and 'id' attribute

You could race a retraction and an edit from different clients. Or just use an XML console

flow you don't always have the stanza-id. For example when you want to retract a message you just sent

flow: let's just get rid of origin-id then, okay?

jcbrand: that's a point I've tried to make for a while. I suppose you need to keep a list of in-flight messages and delay updates that reference them until they've been MAMed

jcbrand, surely you can wait till you observe the messsage reflection containing the stanza-id. you want to wait for it anyways before you show it as received by the channel

1:1 messages don't get reflected

jcbrand: that's another wart on the design of MAM

It's been a while, but I'm pretty sure Converse prioritizes stanza-id over oriring-id

jcbrand, yeah, what Ge0rG said. but you could always query your local MAM to get the stanza-id of the message

would be great to receive a carbon shell on each sent message that was put into MAM

flow: that's like the worst design idea ever

surely not ideal

Yeah, I'm not doing that

in any case, I believe it is possible to use stanza-id in the MUC(/MIX) case, and the XEPs should reflect that

as I wrote a while ago to standards@, using origin-id is prone to id-impersonating issues

origin-id should be matched with the `from` attribute

That's kind of obvious, no?

flow: let's just get rid of origin-id then, okay?

jcbrand, it isn't and afaik it's nowhere specified

If you match origin-id with `from` there's no impersonation risk

probably, but this should be explicitly spelled out then. I fear a lot of implementations treat origin-id as being magical by itself, when there is no authoritiy that authenticates those IDs

It's mentioned in the security considerations of XEP-424 https://xmpp.org/extensions/xep-0424.html#security

that could be enough, since it appears to limit retractions to be send only by the "owner" of the retracted message. But I always have the 'fastening' case in mind, where anyone can react with a +1 on somebody else's message, and it's IMHO also based on origin-id

Retracting someone else's message is XEP-425

which kinda makes it susceptible to the kind of attacks where I replace the message you just +1'ed with a different message…

yes, that sounds broken

`origin-id` works when the person doing the modification is always the sender of the original message ✏

which is the case with retractions

true, I am less concerned now, after discussing this ✏

although, I believe the buisness rules and security considerations of xep425 could be better stated (but isn't that always the case?)

Is there something specific that you're missing?

mostly discussion of the threats to motivate the buisness rules

Remind me why we're still using origin-id?

because you don't get reflection for 1:1 chats

Okay, but why origin-id when there's the stanza@id ?

because you don't have that without reflection

huh? but, _you_ set that?

do you set your own stanza-ids when you send messages?

`<message id="THIS"/>`

oh sorry, that id

because they have no guarantee of being unique

... when _you_ yourself set them?

and then later refer to your own messages (in the context of XEP-0424)

I see what you're getting at, but I don't see how this is better than using origin-id, particularly because clients (devs) have been conditioned to not trust the id to be unique

Right, is it wrong to question that conditioning?

Devs are also complaining about how many ids we have

And yes, it is getting a bit silly

Converse in any case makes the origin-id and the id the same, like Conversations

Every message needs at least 5 ids and 3 timestamps!

Obviously unique ids would have been ideal, but my impression was that that ship has sailed

The number of times I've had "oh no, when I said 'the id of the stanza' I meant..." conversations with devs ✏

I don't think it has, but people continue to push the ship further out, and I like to speak up when I see that happening. I and a number of other people really think that origin-id should be deprecated.

Not used in more and more specs

meh 🙂

I really don't see the harm here

```xml <message id='fa137ce375c641e5808cbcff88770973' type='groupchat' xml:lang='en' from='xsf@muc.xmpp.org/MattJ'> <origin-id id='fa137ce375c641e5808cbcff88770973' xmlns='urn:xmpp:sid:0'/> <body>And yes, it is getting a bit silly</body> <active xmlns='http://jabber.org/protocol/chatstates'/> <occupant-id id='Im3knKDDFlUHyEv8Cj9d/Vx/KnTelRKocoOQSB3SncM=' xmlns='urn:xmpp:occupant-id:0'/> <stanza-id id='2022-05-25-c7615d7b398f5235' xmlns='urn:xmpp:sid:0' by='xsf@muc.xmpp.org'/> <delay xmlns='urn:xmpp:delay' stamp='2022-05-25T12:31:52Z' from='xsf@muc.xmpp.org'/> </message> ``` Count the number of IDs!

It's more explicit than relying on an idea where there is no guarantee of uniqueness

If we assume that stanza@id is stable now, origin-id gives us nothing, does it?

There's also no guarantee that either 'id' or 'origin-id' even exist, so you still have to handle that case either way

it's not stable, there are still clients that don't have unique stanza@id

Kev, in-message promise that the id is unique?

So it could just be `<origin-id/>` without the id

MattJ: XEP-424 mandates origin-id, so it must be there

Ah, uniqueness between clients and sessions, right.

jcbrand, right, so why can't it just mandate that @id is unique?

How to know whether it's unique when you just create a random string?

Same thing

I guess it can, but since that was already mandated for origin-id, it seemed simpler to just use that.

`<message id="uuid"><{I-promise}id-is-unique/></>`

Zash, but even then you have to deal with the absence of that (e.g. if you have a legacy client on your account)

Same as if you "mandate" origin-id

To me, it seems like more dev overhead. Now you have to know that there are some cases where stanza@id is unique and others where you can't rely on it being unique

better to just say it's not unique

That's just the same as origin-id, though, where it might be missing.

Isn't it?

I don't see how it's the same

It's not more dev overhead, it's exactly the same but with additional useless syntax

explicit is better than implicit

implicit = more overhead

So state explicitly in the XEP that any client supporting MUST use unique @id attributes

it's not the same IMO

and that removes a needless dependency on a XEP that many of us want to deprecate

it's not explicit in the stanza in that case

why do you want to deprecate it?

Because it's additional overhead, duplicated information and confusing

so having stanza@id sometimes being unique and sometimes not is not confusing?

No, it should always be unique in any modern client, and we should push for that

yes but people us non-modern clients as well

But adding additional syntax doesn't really help, because you still have to deal with the case where it is not unique or missing

> you still have to deal with the case where it is not unique I don't agree, IMO you can assume that origin-id together with `from` is always unique

But origin-id is not always there

if it's missing, then that's also explicit

I'll have to go check, but IIRC I rely on origin-id quite a bit in Converse to dedupe messages

jcbrand, what about an attacker? :)

And I think a web-client has to care much more about deduping than other clients

someone maliciously setting origin-id to equal values

jonas’ If you match `from` and origin-id then attack doesn't work

depends on the attack I suppose

jonas’ In any case, that would apply to stanza@id also

exactly

making origin-id useless

there is no gain here, you need to be equipped to deal with duplicate or missing IDs, because clients can be legacy or malicious/buggy

and it shouldn't break your client

I never said that I'm pro origin-id to prevent attacks that can happen with stanza@id

that's not what I said either

The gain here is that you can safely assume that origin-id (with `from`) is unique

I just said that there is absolutely zero gain with origin-id

no, you can't

Yes you can

no, it's remote data. You can never assume any property like uniqueness about it.

Yeah, you can assume it is, but it might be wrong. But that's a whole other level :)

you can work on the basis that it probably is, but you absolutely need to gracefully handle cases where it isn't. and then there is zero (0) gain of using origin-id over @id

fair

words!

I don't agree

I finally get proper pressure values from my sensors now, so I'll tune out and bring my sensor network back up again.

You don't agree? I could modify my client today to send <origin-id id='hello world'/> on every message

and then that's your problem?

you're not following the spec

That depends what you're using it for

jcbrand, if that's just MattJs problem, then why not use message@id? :)

sigh

Sure I'm not following the spec, but if you're relying on every entity to follow spec behaviour, that could cause problems for you

because message@id is not guaranteed to be unique, so if he did that with message@id it would still be spec compliant

It really depends what you're using it for

to some extent

It wouldn't be compliant in any XEP-0424 client

Failed to connect, CredSSP required by server

sure, so your retractions don't work ✏

Correct

actually, if you had duplicate message@id your retractions will still work if you have unique origin-id

that's the whole point

In any case, I mentioned deduping, to which no-one responded

That doesn't make much sense, why would I have duplicate @id and unique origin-id?

it's not just about you, it's about the fact that other clients don't have unique message@id

Yes, definitely not denying that some clients might not send a unique @id, or not send any @id at all

But you also can't deny that such clients also don't send origin-id

Forget all about stanza@id except on iq, and only use origin-id. Best of all worlds ;D ✏

or that some clients send unique @id and no origin-id

I don't deny, to me this isn't only about XEP-424

Kev, and then error tracking becomes horrible

Note the ;D :)

Someone might take you seriously :P

It's about the fact that I use origin-id to dedupe

regardless of XEP-424

> Someone might take you seriously :P Not in my experience.

jcbrand, I understand that. And your mention of that wasn't ignored... all these arguments apply to de-dupe as well

And personally I'm not that interested in making even more complicated deduping rules because people want to remove origin-id and then have message@id be guaranteed unique in some cases but not in others

Note that it's not just about removing origin-id, it's not like it's universally sent today

ok, can someone please load a module on this MUC server which sets origin-id to hello world for all messages? kthxbai

So the point is that your de-dupe today is breaking with clients that don't send unique @id

(I assume)

It won't break if they send unique @id, I assume

jonas’ Converse gives priority to stanza-id

The presence of origin-id has no effect on the outcome

I've got an idea

MattJ: It has an effect in the sense that I can't know if someone's client sends a unique @id or not

except for certain edge cases like when a retraction is included

modify '359 to say: If the `id` attribute of `<origin-id/>` is empty, it MUST be assumed to be equal to the `id` attribute on the containing stanza and the sending entity MUST adhere to the same rules for that ID as it would have for `<origin-id/>`. ✏

😣

That helps with the "too many ids" confusion, but it's still... meh. Now we have to send this tag in every message for the rest of eternity?

nah, we'll wait until most people have forgotten that it exists and just use @id directly and then drop it ;)

XMPP 2.0 can simply mandate that the id be unique on pain of ~DEATH~ stream:error

I have to leave

jcbrand, you said origin-id tells you if the stanza id is unique. What do you do with this information?

Time to dig up the idea of IDs being based on a (stream-id, stanza-counter) tuple?

Okay, later :)

MattJ use it to dedupe

> XMPP 2.0 can simply mandate that the id be unique on pain of ~DEATH~ stream:error Unique and sequential UUIDv6

and if it's not unique, no de-dupe happens?

I have other heuristics

*if it may not be unique

but nothing as nice as having a unique id

Daniel, the time+random one? mmmmmmmmmmmmm

I just wish it was more compact

ok, bye, I'll be back later

Amusingly I've been looking at stuff recently where guaranteed-unique IDs are a problem and I need to get rid of them :D

See you!

https://thehackernews.com/2022/05/new-zoom-flaws-could-let-attackers-hack.html?m=1

Seve, sorry we already discussed that yesterday :D

Guessed so.. haha

Do you want to know more? https://logs.xmpp.org/xsf/2022-05-24?p=h#2022-05-24-7f462f13fbf0be1b

it's a (unpatched) gloox bug, maintainer hasn't responded yet, 2 expat bugs, and an (unpatched, but may be mitigated by the expat fixes) ejabberd bug

and, a (presumably novel) general XMPP attack we now need to watch out for

what general xmpp attack?

HACK

'stanza smuggling' to steal their name, where the server passes along 1 stanza that a client interprets as more-than-1

ah

I see I should've shouted louder when that happened in aioxmpp :)

crazy thought here, what if XMPP 2.0 introduced framing, ie "this next stanza is X bytes"

Interestingly, if servers cared about validating things in jabber:(client|server), this wouldn't happen. normative schemas anyone? :)

> crazy thought here, what if XMPP 2.0 introduced framing, ie "this next stanza is X bytes" I struggle to produce an argument against it.

please no normative schemas

then servers+clients could read X more bytes, parse it to exactly 1 stanza, and if it parsed to more, hack, throw it away, stream error

moparisthebest, that requires to know the length ahead-of-time when sending

right, which since we all agree on stanza size limits you must know anyway

It would make XML parsing in general quite a lot easier for clients and servers.

well you could also just try ;)

(and see if your peer kills you for it)

(Or, at least, in I think all the implementations I've worked with it would have reduced some complexity)

the only argument for streaming stanzas of unknown-length is malicious https://www.moparisthebest.com/eatxmempp-cve-2021-32918/

moparisthebest, no, I think arguments can be had which are not malicious, but likely not in federated networks

(because generic XMPP software will suffer from stuff like eatxmempp indeed)

then I don't care, they can use XMPP 1.0, or likely their own variant like whatsapp does

I saw that has been a hot discussion. But could someone volunteer to summarize the issue with Zoom for me? On a rather general level, as I lag most knowledge :-/ (no troll)

> it's a (unpatched) gloox bug, maintainer hasn't responded yet, 2 expat bugs, and an (unpatched, but may be mitigated by the expat fixes) ejabberd bug > and, a (presumably novel) general XMPP attack we now need to watch out for > 'stanza smuggling' to steal their name, where the server passes along 1 stanza that a client interprets as more-than-1 emus I *think* that's a fair summary ^

the reason this was catastrophic in zoom is the second stanza smuggled in told the client to download a binary and execute it, don't think any XMPP things on the public federated network do anything that stupid

So, it was not know, but also no practice out there in the wild XMPP?

but thanks for responding!

not really known before, but apparantly jonas’ experienced similar in aioxmpp just didn't spread it around :D

you could pull off the same hack right now on a user of Renga if they were connected to a server without a patched expat

"hi this is your admin" - from admin@yourserver

can zoom federate?

seriously doubt it

moparisthebest: thanks

jonas’, ping sent u a message regarding a ping account for observe.jabber.network

TheCoffeMaker, ah yes, I meant to reply to that

jonas’, no problem!