-
goffi
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…
-
goffi
ping jcbrand ^
-
Zash
https://logs.xmpp.org/council/2022-01-05?p=h#2022-01-05-fa0ce69fd8b2d0be
-
goffi
Zash: Thanks. The XEP should not be updated to remove the last-call notice then?
-
Zash
Maybe, ask the editor?
-
goffi
right, I've let a note on editor@
-
goffi
jcbrand: any plan to update this XEP? I'm asking because I'm about to implement it.
-
jcbrand
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.
-
jcbrand
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.
-
goffi
jcbrand: I see, thanks. Well I'll implement in current state, and will adapt when necessary.
-
Andrzej
jcbrand, XEP-0424 is also implemented in SiskinIM and BeagleIM, and it works as expected
-
jcbrand
Ah cool, good to know
-
flow
how do implementations behave is someone smuggels in an message with an origin-id that is identical the origin-id of a previous message that got retracted?✎ -
flow
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? ✏
-
Zash
abolish origin-id!
-
Ge0rG
halt and catch fire
-
Andrzej
in our case, we are accepting those, but during lookup we are looking for the newest message with matching origin-id
-
flow
Andrzej, so I can un-retract a message by injecting a newer message with a duplicate origin-id?
-
Andrzej
no, it would result in a new message
-
Andrzej
only further references would be related to the new message
-
Ge0rG
how do you treat LMC on a retracted message?
-
Ge0rG
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.
-
Ge0rG
The other part of the question is about "operator precedence" of message-modifying messages. Does LMC beat retraction? Does moderator retraction beat LMC?
-
jcbrand
Depends on what is received first? In any case, LMC on a retracted message is moot, since the message has been retracted
-
Ge0rG
jcbrand: what about: I send something obscene, the message is retracted by mods, I edit it to remove the obscenity?
-
jcbrand
It's already retracted, so your correction can no longer be applied
-
jcbrand
TBH, I'm not sure how much I've tested such edge cases, but that's what I would expect
-
jcbrand
i.e. retraction has precedence over corrections
-
jcbrand
should perhaps be mentioned in the XEP
-
Andrzej
I'm pretty sure that if message would be retracted in my clients, you wouldn't be able to edit it✎ -
Andrzej
I'm pretty sure that if message would be retracted in my clients, you wouldn't be able to correct it ✏
-
jcbrand
No, but a cilent that doesn't support retractions could allow it
-
flow
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
-
Ge0rG
You could race a retraction and an edit from different clients. Or just use an XML console
-
jcbrand
flow you don't always have the stanza-id. For example when you want to retract a message you just sent
-
Ge0rG
flow: let's just get rid of origin-id then, okay?
-
Ge0rG
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
-
flow
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
-
jcbrand
1:1 messages don't get reflected
-
Ge0rG
jcbrand: that's another wart on the design of MAM
-
jcbrand
It's been a while, but I'm pretty sure Converse prioritizes stanza-id over oriring-id
-
flow
jcbrand, yeah, what Ge0rG said. but you could always query your local MAM to get the stanza-id of the message
-
Ge0rG
would be great to receive a carbon shell on each sent message that was put into MAM
-
Ge0rG
flow: that's like the worst design idea ever
-
flow
surely not ideal
-
jcbrand
Yeah, I'm not doing that
-
flow
in any case, I believe it is possible to use stanza-id in the MUC(/MIX) case, and the XEPs should reflect that
-
flow
as I wrote a while ago to standards@, using origin-id is prone to id-impersonating issues
-
jcbrand
origin-id should be matched with the `from` attribute
-
jcbrand
That's kind of obvious, no?
-
Ge0rG
flow: let's just get rid of origin-id then, okay?
-
flow
jcbrand, it isn't and afaik it's nowhere specified
- Ge0rG needs to put that on a key binding.
-
jcbrand
If you match origin-id with `from` there's no impersonation risk
-
flow
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
-
jcbrand
It's mentioned in the security considerations of XEP-424 https://xmpp.org/extensions/xep-0424.html#security
-
flow
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
-
jcbrand
Retracting someone else's message is XEP-425
-
flow
which kinda makes it susceptible to the kind of attacks where I replace the message you just +1'ed with a different message…
-
jcbrand
yes, that sounds broken
-
jcbrand
`origin-id` works when the person doing the modification is the sender of the original message✎ -
jcbrand
`origin-id` works when the person doing the modification is always the sender of the original message ✏
-
jcbrand
which is the case with retractions
-
flow
true, I am less concerned now, aftter discussing this✎ -
flow
true, I am less concerned now, after discussing this ✏
-
flow
although, I believe the buisness rules and security considerations of xep425 could be better stated (but isn't that always the case?)
-
jcbrand
Is there something specific that you're missing?
-
flow
mostly discussion of the threats to motivate the buisness rules
-
MattJ
Remind me why we're still using origin-id?
-
jcbrand
because you don't get reflection for 1:1 chats
-
Zash
Okay, but why origin-id when there's the stanza@id ?
-
jcbrand
because you don't have that without reflection
-
Zash
huh? but, _you_ set that?
-
jcbrand
do you set your own stanza-ids when you send messages?
-
Zash
`<message id="THIS"/>`
-
jcbrand
oh sorry, that id
-
jcbrand
because they have no guarantee of being unique
-
Zash
... when _you_ yourself set them?
-
Zash
and then later refer to your own messages (in the context of XEP-0424)
-
jcbrand
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
-
MattJ
Right, is it wrong to question that conditioning?
-
MattJ
Devs are also complaining about how many ids we have
-
MattJ
And yes, it is getting a bit silly
-
jcbrand
Converse in any case makes the origin-id and the id the same, like Conversations
-
MattJ
The number of times I've had "oh no, when I said 'the id of the stanza I meant...' conversations with devs"✎ -
Zash
Every message needs at least 5 ids and 3 timestamps!
-
jcbrand
Obviously unique ids would have been ideal, but my impression was that that ship has sailed
-
MattJ
The number of times I've had "oh no, when I said 'the id of the stanza' I meant..." conversations with devs ✏
-
MattJ
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.
-
MattJ
Not used in more and more specs
-
jcbrand
meh 🙂
-
jcbrand
I really don't see the harm here
-
Zash
```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!
-
jcbrand
It's more explicit than relying on an idea where there is no guarantee of uniqueness
-
Kev
If we assume that stanza@id is stable now, origin-id gives us nothing, does it?
-
MattJ
There's also no guarantee that either 'id' or 'origin-id' even exist, so you still have to handle that case either way
-
jcbrand
it's not stable, there are still clients that don't have unique stanza@id
-
Zash
Kev, in-message promise that the id is unique?
-
Zash
So it could just be `<origin-id/>` without the id
-
jcbrand
MattJ: XEP-424 mandates origin-id, so it must be there
-
Kev
Ah, uniqueness between clients and sessions, right.
-
MattJ
jcbrand, right, so why can't it just mandate that @id is unique?
-
mdosch
How to know whether it's unique when you just create a random string?
-
MattJ
Same thing
-
jcbrand
I guess it can, but since that was already mandated for origin-id, it seemed simpler to just use that.
-
Zash
`<message id="uuid"><{I-promise}id-is-unique/></>`
-
MattJ
Zash, but even then you have to deal with the absence of that (e.g. if you have a legacy client on your account)
-
MattJ
Same as if you "mandate" origin-id
-
jcbrand
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
-
jcbrand
better to just say it's not unique
-
Kev
That's just the same as origin-id, though, where it might be missing.
-
Kev
Isn't it?
-
jcbrand
I don't see how it's the same
-
MattJ
It's not more dev overhead, it's exactly the same but with additional useless syntax
-
jcbrand
explicit is better than implicit
-
jcbrand
implicit = more overhead
-
MattJ
So state explicitly in the XEP that any client supporting MUST use unique @id attributes
-
jcbrand
it's not the same IMO
-
MattJ
and that removes a needless dependency on a XEP that many of us want to deprecate
-
jcbrand
it's not explicit in the stanza in that case
-
jcbrand
why do you want to deprecate it?
-
MattJ
Because it's additional overhead, duplicated information and confusing
-
jcbrand
so having stanza@id sometimes being unique and sometimes not is not confusing?
-
MattJ
No, it should always be unique in any modern client, and we should push for that
-
jcbrand
yes but people us non-modern clients as well
-
MattJ
But adding additional syntax doesn't really help, because you still have to deal with the case where it is not unique or missing
-
jcbrand
> 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
-
MattJ
But origin-id is not always there
-
jcbrand
if it's missing, then that's also explicit
-
jcbrand
I'll have to go check, but IIRC I rely on origin-id quite a bit in Converse to dedupe messages
-
jonas’
jcbrand, what about an attacker? :)
-
jcbrand
And I think a web-client has to care much more about deduping than other clients
-
jonas’
someone maliciously setting origin-id to equal values
-
jcbrand
jonas’ If you match `from` and origin-id then attack doesn't work
-
jonas’
depends on the attack I suppose
-
jcbrand
jonas’ In any case, that would apply to stanza@id also
-
jonas’
exactly
-
jonas’
making origin-id useless
-
jonas’
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
-
jonas’
and it shouldn't break your client
-
jcbrand
I never said that I'm pro origin-id to prevent attacks that can happen with stanza@id
-
jonas’
that's not what I said either
-
jcbrand
The gain here is that you can safely assume that origin-id (with `from`) is unique
-
jonas’
I just said that there is absolutely zero gain with origin-id
-
jonas’
no, you can't
-
jcbrand
Yes you can
-
jonas’
no, it's remote data. You can never assume any property like uniqueness about it.
-
MattJ
Yeah, you can assume it is, but it might be wrong. But that's a whole other level :)
-
jonas’
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
-
jonas’
fair
-
jonas’
words!
-
jcbrand
I don't agree
-
jonas’
I finally get proper pressure values from my sensors now, so I'll tune out and bring my sensor network back up again.
-
MattJ
You don't agree? I could modify my client today to send <origin-id id='hello world'/> on every message
-
jcbrand
and then that's your problem?
-
jcbrand
you're not following the spec
-
MattJ
That depends what you're using it for
-
jonas’
jcbrand, if that's just MattJs problem, then why not use message@id? :)
-
jcbrand
sigh
-
MattJ
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
-
jcbrand
because message@id is not guaranteed to be unique, so if he did that with message@id it would still be spec compliant
-
MattJ
It really depends what you're using it for
-
jcbrand
to some extent
-
MattJ
It wouldn't be compliant in any XEP-0424 client
-
jcbrand
sure, so you're retractions don't work✎ -
Guus
Failed to connect, CredSSP required by server
-
jcbrand
sure, so your retractions don't work ✏
-
MattJ
Correct
-
jcbrand
actually, if you had duplicate message@id your retractions will still work if you have unique origin-id
-
jcbrand
that's the whole point
-
jcbrand
In any case, I mentioned deduping, to which no-one responded
-
MattJ
That doesn't make much sense, why would I have duplicate @id and unique origin-id?
-
jcbrand
it's not just about you, it's about the fact that other clients don't have unique message@id
-
MattJ
Yes, definitely not denying that some clients might not send a unique @id, or not send any @id at all
-
Kev
Forget all about stanza@id except on id, and only use origin-id. Best of all worlds ;D✎ -
MattJ
But you also can't deny that such clients also don't send origin-id
-
Kev
Forget all about stanza@id except on iq, and only use origin-id. Best of all worlds ;D ✏
-
MattJ
or that some clients send unique @id and no origin-id
-
jcbrand
I don't deny, to me this isn't only about XEP-424
-
MattJ
Kev, and then error tracking becomes horrible
-
Kev
Note the ;D :)
-
MattJ
Someone might take you seriously :P
-
jcbrand
It's about the fact that I use origin-id to dedupe
-
jcbrand
regardless of XEP-424
-
Kev
> Someone might take you seriously :P Not in my experience.
-
MattJ
jcbrand, I understand that. And your mention of that wasn't ignored... all these arguments apply to de-dupe as well
-
jcbrand
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
-
MattJ
Note that it's not just about removing origin-id, it's not like it's universally sent today
-
jonas’
ok, can someone please load a module on this MUC server which sets origin-id to hello world for all messages? kthxbai
-
MattJ
So the point is that your de-dupe today is breaking with clients that don't send unique @id
-
MattJ
(I assume)
-
MattJ
It won't break if they send unique @id, I assume
-
jcbrand
jonas’ Converse gives priority to stanza-id
-
MattJ
The presence of origin-id has no effect on the outcome
-
jonas’
I've got an idea
-
jcbrand
MattJ: It has an effect in the sense that I can't know if someone's client sends a unique @id or not
-
jcbrand
except for certain edge cases like when a retraction is included
-
jonas’
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.✎ -
jonas’
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/>`. ✏
-
MattJ
😣
-
MattJ
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?
-
jonas’
nah, we'll wait until most people have forgotten that it exists and just use @id directly and then drop it ;)
-
Zash
XMPP 2.0 can simply mandate that the id be unique on pain of ~DEATH~ stream:error
-
jcbrand
I have to leave
-
MattJ
jcbrand, you said origin-id tells you if the stanza id is unique. What do you do with this information?
-
Zash
Time to dig up the idea of IDs being based on a (stream-id, stanza-counter) tuple?
-
MattJ
Okay, later :)
-
jcbrand
MattJ use it to dedupe
-
Daniel
> XMPP 2.0 can simply mandate that the id be unique on pain of ~DEATH~ stream:error Unique and sequential UUIDv6
-
MattJ
and if it's not unique, no de-dupe happens?
-
jcbrand
I have other heuristics
-
MattJ
*if it may not be unique
-
jcbrand
but nothing as nice as having a unique id
-
Zash
Daniel, the time+random one? mmmmmmmmmmmmm
-
Zash
I just wish it was more compact
-
jcbrand
ok, bye, I'll be back later
-
Kev
Amusingly I've been looking at stuff recently where guaranteed-unique IDs are a problem and I need to get rid of them :D
-
MattJ
See you!
-
Seve
https://thehackernews.com/2022/05/new-zoom-flaws-could-let-attackers-hack.html?m=1
-
moparisthebest
Seve, sorry we already discussed that yesterday :D
-
Seve
Guessed so.. haha
-
Zash
Do you want to know more? https://logs.xmpp.org/xsf/2022-05-24?p=h#2022-05-24-7f462f13fbf0be1b
-
moparisthebest
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
-
moparisthebest
and, a (presumably novel) general XMPP attack we now need to watch out for
-
jonas’
what general xmpp attack?
-
Zash
HACK
-
moparisthebest
'stanza smuggling' to steal their name, where the server passes along 1 stanza that a client interprets as more-than-1
-
jonas’
ah
-
jonas’
I see I should've shouted louder when that happened in aioxmpp :)
-
moparisthebest
crazy thought here, what if XMPP 2.0 introduced framing, ie "this next stanza is X bytes"
-
Kev
Interestingly, if servers cared about validating things in jabber:(client|server), this wouldn't happen. normative schemas anyone? :)
-
Kev
> 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.
-
jonas’
please no normative schemas
-
moparisthebest
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
-
jonas’
moparisthebest, that requires to know the length ahead-of-time when sending
-
moparisthebest
right, which since we all agree on stanza size limits you must know anyway
-
Kev
It would make XML parsing in general quite a lot easier for clients and servers.
-
jonas’
well you could also just try ;)
-
jonas’
(and see if your peer kills you for it)
-
Kev
(Or, at least, in I think all the implementations I've worked with it would have reduced some complexity)
-
moparisthebest
the only argument for streaming stanzas of unknown-length is malicious https://www.moparisthebest.com/eatxmempp-cve-2021-32918/
-
jonas’
moparisthebest, no, I think arguments can be had which are not malicious, but likely not in federated networks
-
jonas’
(because generic XMPP software will suffer from stuff like eatxmempp indeed)
-
moparisthebest
then I don't care, they can use XMPP 1.0, or likely their own variant like whatsapp does
-
emus
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)
-
moparisthebest
> 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 ^
-
moparisthebest
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
-
emus
So, it was not know, but also no practice out there in the wild XMPP?
-
emus
but thanks for responding!
-
moparisthebest
not really known before, but apparantly jonas’ experienced similar in aioxmpp just didn't spread it around :D
-
moparisthebest
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
-
moparisthebest
"hi this is your admin" - from admin@yourserver
-
qy
can zoom federate?
-
moparisthebest
seriously doubt it
-
emus
moparisthebest: thanks
-
TheCoffeMaker
jonas’, ping sent u a message regarding a ping account for observe.jabber.network
-
jonas’
TheCoffeMaker, ah yes, I meant to reply to that
-
TheCoffeMaker
jonas’, no problem!