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: standards-unsubscr...@xmpp.org _______________________________________________
