From 64f87e1d2ac8c60edd1355bc96ecfda25a603fc8 Mon Sep 17 00:00:00 2001 From: Georg Lukas Date: Wed, 8 Sep 2021 18:58:36 +0200 Subject: [PATCH] XEP-0280: Remove the removal of the `` element The requirement to strip `` by the sending server was in the XEP from day 1. It was later changed from "MUST" to "SHOULD" and from "sending server" to "receiving server", so that the latter could also prevent normal message routing. As this behavior only ever affected the `` element and not the `` hint (introduced in 2017), which should be treated in a similar but not equal way, and there is a security benefit in letting the receiving client know that message routing was manipulated, it makes sense to remove this requirement. As there is no negative effect of keeping another element in delivered messages, nobody complained about `` not being stripped, and bumping Carbons today would be rather unfortunate, this is done without a namespace bump, despite "breaking" the specification. --- xep-0280.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xep-0280.xml b/xep-0280.xml index 10916709..fff54c11 100644 --- a/xep-0280.xml +++ b/xep-0280.xml @@ -466,9 +466,9 @@
  • The sending client MAY exclude a &MESSAGE; from being forwarded to other Carbons-enabled resources, by adding a <private/> element qualified by the namespace "urn:xmpp:carbons:2" and a <no-copy/> hint as described in &xep0334; as child elements of the &MESSAGE; stanza.
  • The sending server MUST NOT deliver forwarded &MESSAGE;s to the other Carbons-enabled resources of the sender.
  • The receiving server MUST NOT deliver forwarded &MESSAGE;s to the other Carbons-enabled resource of the recipient,
    • -
  • and the receiving server SHOULD remove the <private/> element before delivering to the recipient.
    • +

    Interoperability note: earlier versions of this XEP required or recommended the removal of the <private/> element (albeit not of the <no-copy/> hint) by one of the involved servers, but this behavior was considered as a potential security issue as the sender could silently manipulate the delivery of messages, so that the requirement was lifted. However, clients MUST NOT assume that a message without the element was actually routed to all other resources of the account.

    Note: Use of the private mechanism might lead to partial conversations on other devices. This is the intended effect. If the private &MESSAGE; stanza is addressed to a bare JID, the receiving server still delivers it according to RFC 6121. This might result in a copy being delivered to each resource for the recipient, which effectively negates the behavior of the <private/> element for recipients.