Abuse and spam are common issues on any open network. XMPP is no exception, and we have a range of protocols and tools to tackle various aspects of the problem. Until now, however, there has been no standard in-band way to report abuse in group chats.
This specification describes a protocol to report messages as abuse/spam, report problematic participants to group chat admins, and to report problematic group chats to server admins.
The requirements this specification aims to meet include:
The specification aims to reuse existing protocol containers which fit the
data being transported. For example, it uses the report syntax from Blocking Command Reports (XEP-0377)
The protocol is designed to work within the context of Multi-User Chat (XEP-0045)
A participant in the chat reports this message, e.g. so it can be moderated using Message Moderation (XEP-0425)
Reporting happens via an <iq/> of type 'set' containing a <submit/> payload element qualified by the 'urn:xmpp:gcreport:0' namespace.
The <submit/> element MUST contain one <occupant-id/> (defined in XEP-0421) which identifies the participant being reported.
It MUST also contain a single <report/> element, as defined by XEP-0377.
Per the rules of XEP-0377, the <stanza-id/> element is not required, but SHOULD be included if the reporter is reporting a specific message. This can help provide additional context to the recipients of the report, which helps improve incident resolution times. When provided, the referenced stanza MUST be a stanza sent by the reported participant, otherwise the server SHOULD ignore it.
In some cases, a user may want to report an entire group chat to the server operator. For example, if the chat, its subject or administrators violate the server’s policies.
Reports about a group chat are sent via an <iq/> of type 'set' to the MUC service JID. The payload of the stanza MUST be a <report-chat/> element qualified by the 'urn:xmpp:gcreport:0' namespace.
Within this element MUST be a single <jid/> element (also in the 'urn:xmpp:gcreport:0' namespace).
Finally, a single <report/> element (as defined in XEP-0377) MUST be included, specifying the reason for the report and any supporting evidence.
Group chats which support reporting participants and services which support reporting chats MUST both advertise the 'urn:xmpp:gcreport:0' feature in their XEP-0030 service discovery features.
Upon receipt of a report, a service SHOULD perform an appropriate action, such as immediately notifying appropriate people in an appropriate manner, and/or automatically moderating reported messages or hiding groups from public listings. Any automated actions MUST be reversible upon review,to minimise the consequences of malicious reports.
For reports about participants, JIDs with an affiliation of 'owner' or 'admin' are generally the appropriate recipients of any report notifications.
For reports about chats, the responsible entity is usually the server administrator
However, this XEP does not mandate any specific actions as the appropriate action may depend on context such as the nature of the deployment, the reporter and the reported entity.
No special accessibility concerns have been identified.
None.
Implementations MUST consider various attack vectors in reporting systems built upon this protocol. This includes:
These issues can typically be tackled using standard techniques such as rate limiting, and trust-based approaches based on the reporter (for example, reports from long-standing affiliated members may take priority over reports from new/untrusted users).
When processing reports, servers MUST consider the privacy of the reporter. Appropriate measures would include anonymization (including at least removal of the reporter’s JID) before forwarding the report to any third parties (such as a server where the abuse originated). If abuse originates from a remote server (e.g. a reported user hosts their account there), it cannot be assumed that the remote server can necessarily be trusted.
Likewise, the privacy of reported entities MUST also be considered - not least because false and malicious reports are entirely possible within this protocol. Servers MUST NOT cause any private data to be exposed to untrusted entities in response to a report.
None.
None.
This document aims to fill a gap in spam/abuse reporting, which already works well for direct (one-to-one) chats. It reuses existing protocols which have already been widely implemented and deployed.
TBD.