Hi, I just want to briefly mention that I agree with Marvin here.
The rules in XEP-0461 (Message Replies) and XEP-0444 (Message Reactions) are good. We don’t need to make the stanza-id XEP more complicated. We should however outsource the two-three paragraphs on what ID to use into it’s own XEP. (Marvin suggested this; I'm just repeating this because I agree) If fastening had security issues (I didn’t check) I don’t think it matters anymore because we are in the process of phasing that out. cheers Daniel On Tue, Feb 21, 2023 at 9:20 PM Marvin W <[email protected]> wrote: > > Hi, > > This is feedback for the latest PR to XEP-0359. > > > The value of origin-id is spoofable and hence MUST not be used when > referencing other stanzas. > > - This doesn't explain at all what "spoofable" means. > - origin-id's are supposed to be unique only within the scope of the > origin. In semi-anonymous MUCs, the origin is typically unknown, thus > the uniqueness scope is unknown and the origin-id can't be assumed > unique at all. > - I do think that using origin-id to reference other stanzas is still > possible with reasonable security for several usecases in "trusted" > conversations (e.g. direct chats, non-anonymous MUCs). > > > The value tuple of 'id' and 'by' of the stanza-id element is > unspoofable iff all involved implementations follow the requirements of > this specification. > > - This doesn't explain at all what "unspoofable" means. > - The sender or any relay of a message can insert or modify stanza-id's > with the by-attribute set to a third-party, as long as that message is > not routed through that third-party afterwards. > - A user's server can modify the stanza-id of MUC messages sent to > that user. > - The sender can add stanza-id of a third-party server. Depending on > the usecase (for example semi-anonymous MUC messages), the recipient > will be unable to decide if the message was actually routed through > that server or not. > - All involved implementations include the sender and all entities in- > between, i.e. everyone that could spoof. Saying that something is > unspoofable just because the specification forbids everyone involved to > spoof sounds superfluous to me. > > > The <referenced-stanza/> element can be used to reference another > stanza. > > I don't think it's a good idea to add this element, for a lot of > reasons. > > This XEP itself is (even if it was in Deferred state) widely > implemented. Adding something entirely new to it instead of in a new > XEP should be well-reasoned IMO. > > This newly added element is not within the self-imposed usecase of the > XEP (as is written in the abstract and introduction). > > As I wrote in my previous message [1], I don't think requiring a by- > attribute is a good idea or even adding any value when referencing > messages. > > For all practical usecases, there will always only be a single by- > attribute that is valid (the bare JID of the MUC [2]) and for every > incoming message from a MUC, that value is already known implicitly. If > our current documentation/specification leads to people incorrectly > accepting stanza-id's with other values for the by-attribute, that's an > issue on it's own which may not even be solved by adding this > attribute. > > In non-MUC messages, there generally is no stanza-id that could be used > for referencing a message in a way that can be understood by the > counterparties, so this newly proposed element would not even work for > referencing outside MUCs, making every XEP that would adopt this > element no longer work outside MUCs. > > For MAM purposes, the stanza-id is used inside data forms, where using > this element is not really feasible. > > > > > All in all, I get the feeling this is a rushed change caused by > incorrect wording in XEP-0422 that caused misunderstanding while > creating XEP-0424. As we're currently in the process of deprecating > XEP-0422 and removing it from XEP-0424, we can take the opportunity to > also fix XEP-0424 to use the correct stanza-id instead. > > Adding hints/notes to XEP-0359 to ensure this doesn't happen again is > probably a good idea though (even if I don't think the current wording > is good), as is to create a new informational XEP that describes the > rules for referencing messages in direct chats and groupchats, > including developer notes on what to take care of to implement this > correctly and spoof-safe. > > If there is consensus that the latter is a good idea, I can create a > first draft for this. > > Marvin > > > [1] > https://mail.jabber.org/pipermail/standards/2023-February/039171.html > [2] While I'm talking about MUCs exclusively here, I'd assume the same > to apply for any other groupchat system we may come up with that works > based on a single forwarding relay (MIX, etc) > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: [email protected] > _______________________________________________ _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
