* Dave Cridland <[email protected]> [2021-09-08 10:50]: [Spoofing of the Forwarded element] > I can agree with this in principle, though the query id within MAM > queries dramatically lessens the scope for an attack here.
I'm aware of this point. However, many implementations process stanzas in callback functions and might not have the query ID as a context, and furthermore there is no place in 0313 that requires clients to drop responses that don't match the initial query-id. I think the yet-to-write security section should contain that requirement as well as checking for the appropiate from address. > I'm unconvinced that trying to "fix" XEP-0045's various deficiencies is a > useful use of what energy we have. I would be content with not worsening the status quo of 0045 by introducing things like "your MAM archive might flood your client with 0045 messages without you asking and without any context". > For persistent groupchat protocols (MUC-SUB, Muclight, MIX) storing > groupchat messages in the personal archive is very useful indeed. That's an excellent point. I would suggest documenting the interop of these protocols with 0313 in the respective protocol specifications, and changing the wording in 0313 to something like "SHOULD NOT store and return type=groupchat messages unless defined by a separate specification", but the second part is implicit in all our XEPs anyway. > For XEP-0045, it's complicated, sometimes entirely undesirable, and > sometimes very useful, and usually weird. Could you further elaborate when specifically it is useful to have? > How would a "if you didn't specify, we won't either" model go with you? > That is, we add a flag in the query to specify whether or not > groupchat messages are included, but we explicitly do not include a default > value. This was exactly what I was thinking about. A feature telling clients that they may ask for type=groupchat / MUC messages, and a query parameter (even if it's just the <x/> element from MUC) telling the archive that the client explicitly wishes for MUC message history. Thanks, Georg
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
