|
|
|
@ -13,7 +13,7 @@
@@ -13,7 +13,7 @@
|
|
|
|
|
</abstract> |
|
|
|
|
&LEGALNOTICE; |
|
|
|
|
<number>0377</number> |
|
|
|
|
<status>Deferred</status> |
|
|
|
|
<status>Experimental</status> |
|
|
|
|
<type>Standards Track</type> |
|
|
|
|
<sig>Standards</sig> |
|
|
|
|
<approver>Council</approver> |
|
|
|
@ -26,6 +26,12 @@
@@ -26,6 +26,12 @@
|
|
|
|
|
<supersededby/> |
|
|
|
|
<shortname>NOT_YET_ASSIGNED</shortname> |
|
|
|
|
&sam; |
|
|
|
|
<revision> |
|
|
|
|
<version>0.3</version> |
|
|
|
|
<date>2021-06-21</date> |
|
|
|
|
<initials>ssw</initials> |
|
|
|
|
<remark>Rework based on list feedback.</remark> |
|
|
|
|
</revision> |
|
|
|
|
<revision> |
|
|
|
|
<version>0.2</version> |
|
|
|
|
<date>2017-09-11</date> |
|
|
|
@ -49,75 +55,84 @@
@@ -49,75 +55,84 @@
|
|
|
|
|
<p> |
|
|
|
|
Many spam and abuse prevention techniques rely on users being able to report |
|
|
|
|
other users who are sending unwanted messages, or specific instances of |
|
|
|
|
abuse. &xep0191; allows users to block spammers, but does not provide a |
|
|
|
|
mechanism for them to report a reason for the block to the server operator. |
|
|
|
|
abuse. |
|
|
|
|
&xep0191; allows users to block spammers, but does not provide a mechanism |
|
|
|
|
for them to report a reason for the block to the server operator. |
|
|
|
|
This specification extends the blocking command to optionally provide an |
|
|
|
|
abuse report. |
|
|
|
|
</p> |
|
|
|
|
</section1> |
|
|
|
|
<section1 topic='Background' anchor='background'> |
|
|
|
|
<p> |
|
|
|
|
This document extends the blocking command instead of providing a separate |
|
|
|
|
reporting IQ because we hypothesize that this will slightly lower the levels |
|
|
|
|
of false reports received by service operators. |
|
|
|
|
We have observed a common pattern on the internet where a user becomes mad |
|
|
|
|
at or disagrees with another user and begins harassing them by replying to |
|
|
|
|
or reporting their every comment even if it is not itself spam or abusive. |
|
|
|
|
However, this sort of behavior cannot continue if the harasser can no longer |
|
|
|
|
read the messages of the person they are stalking. |
|
|
|
|
Giving them a choice between their abusive behavior and being able to |
|
|
|
|
read their targets can possibly force them to break the cycle and only |
|
|
|
|
create valid reports. |
|
|
|
|
</p> |
|
|
|
|
</section1> |
|
|
|
|
<section1 topic='Discovering Support' anchor='disco'> |
|
|
|
|
<p> |
|
|
|
|
Entities that support &xep0030; and abuse reporting MUST respond to service |
|
|
|
|
discovery requests with a feature of 'urn:xmpp:reporting:0' and with a |
|
|
|
|
feature for each reason supported by the responding entity as described in |
|
|
|
|
the relavant specifications. Eg. a response from a server that supports |
|
|
|
|
reporting and understands the abuse and spam reasons defined later in this |
|
|
|
|
specification might look like the following: |
|
|
|
|
Entities that support &xep0030; and abuse reporting using the blocking |
|
|
|
|
command as defined in this spec MUST respond to service discovery requests |
|
|
|
|
with a feature of 'urn:xmpp:reporting:1'. |
|
|
|
|
Support for this namespace also indicates support for the abuse reporting |
|
|
|
|
reasons defined in this document. |
|
|
|
|
For example, a response from a server that supports reporting and |
|
|
|
|
understands the abuse and spam reasons defined later in this specification |
|
|
|
|
might look like the following: |
|
|
|
|
</p> |
|
|
|
|
<example caption="Service discovery information response"><![CDATA[ |
|
|
|
|
<iq from='shakespeare.lit' |
|
|
|
|
<iq from='example.net' |
|
|
|
|
id='ku6e51v3' |
|
|
|
|
to='kingclaudius@shakespeare.lit/castle' |
|
|
|
|
to='kingclaudius@example.net/castle' |
|
|
|
|
type='result'> |
|
|
|
|
<query xmlns='http://jabber.org/protocol/disco#info'> |
|
|
|
|
<feature var='urn:xmpp:reporting:0'/> |
|
|
|
|
<feature var='urn:xmpp:reporting:reason:abuse:0'/> |
|
|
|
|
<feature var='urn:xmpp:reporting:reason:spam:0'/> |
|
|
|
|
<feature var='urn:xmpp:reporting:1'/> |
|
|
|
|
… |
|
|
|
|
</query> |
|
|
|
|
</iq>]]></example> |
|
|
|
|
</section1> |
|
|
|
|
<section1 topic='Payload' anchor='payload'> |
|
|
|
|
<p> |
|
|
|
|
The payload for reporting abuse to the server takes the form of a |
|
|
|
|
<report/> qualified by the 'urn:xmpp:reporting:0' namespace &VNOTE;. |
|
|
|
|
Report payloads are reusable and MUST NOT be sent without first being |
|
|
|
|
wrapped in a stanza. |
|
|
|
|
<report/> qualified by the 'urn:xmpp:reporting:1' namespace &VNOTE;. |
|
|
|
|
</p> |
|
|
|
|
<example caption='The most basic report payload'><![CDATA[ |
|
|
|
|
<report xmlns="urn:xmpp:reporting:0" />]]></example> |
|
|
|
|
<report xmlns="urn:xmpp:reporting:1" reason="urn:xmpp:reporting:spam"/>]]></example> |
|
|
|
|
<p> |
|
|
|
|
Abuse reports MAY include a reason for the report and servers MUST tolerate |
|
|
|
|
unknown XML elements in a report without making assumptions about the |
|
|
|
|
semantic meaning of unknown elements. |
|
|
|
|
Abuse reports MUST include a reason for the report in the "reason" attribute. |
|
|
|
|
</p> |
|
|
|
|
<p> |
|
|
|
|
This document defines the following reasons for a report: |
|
|
|
|
</p> |
|
|
|
|
<dl> |
|
|
|
|
<di> |
|
|
|
|
<dt><spam/></dt> |
|
|
|
|
<dt>urn:xmpp:reporting:spam</dt> |
|
|
|
|
<dd>Used for reporting a JID that is sending unwanted messages.</dd> |
|
|
|
|
</di> |
|
|
|
|
<di> |
|
|
|
|
<dt><abuse/></dt> |
|
|
|
|
<dt>urn:xmpp:reporting:abuse</dt> |
|
|
|
|
<dd>Used for reporting general abuse.</dd> |
|
|
|
|
</di> |
|
|
|
|
</dl> |
|
|
|
|
<p> |
|
|
|
|
Clients MUST include only one reason per report. |
|
|
|
|
</p> |
|
|
|
|
<p> |
|
|
|
|
Reports MAY contain a user provided message explaining or providing context |
|
|
|
|
about the reason for the report. See also the |
|
|
|
|
<link url='#i18n'>Internationalization Considerations</link> section of this |
|
|
|
|
document. |
|
|
|
|
about the reason for the report. |
|
|
|
|
See also the <link url='#i18n'>Internationalization Considerations</link> |
|
|
|
|
section of this document. |
|
|
|
|
</p> |
|
|
|
|
<example caption='Report with optional reason and text'><![CDATA[ |
|
|
|
|
<report xmlns="urn:xmpp:reporting:0"> |
|
|
|
|
<report xmlns="urn:xmpp:reporting:1" reason="urn:xmpp:reporting:spam"> |
|
|
|
|
<text xml:lang="en"> |
|
|
|
|
Never came trouble to my house like this. |
|
|
|
|
</text> |
|
|
|
|
<spam/> |
|
|
|
|
</report>]]></example> |
|
|
|
|
</section1> |
|
|
|
|
<section1 topic='Use with the Blocking Command' anchor='blocking'> |
|
|
|
@ -127,27 +142,57 @@
@@ -127,27 +142,57 @@
|
|
|
|
|
For example: |
|
|
|
|
</p> |
|
|
|
|
<example caption='Report sent with blocking command'><![CDATA[ |
|
|
|
|
<iq from='juliet@capulet.com/chamber' type='set' id='block1'> |
|
|
|
|
<iq from='juliet@example.com/chamber' type='set' id='block1'> |
|
|
|
|
<block xmlns='urn:xmpp:blocking'> |
|
|
|
|
<item jid='romeo@montague.net'> |
|
|
|
|
<report xmlns="urn:xmpp:reporting:0"> |
|
|
|
|
<abuse/> |
|
|
|
|
</report> |
|
|
|
|
<item jid='romeo@example.net'> |
|
|
|
|
<report xmlns="urn:xmpp:reporting:1" reason="urn:xmpp:reporting:abuse"/> |
|
|
|
|
</item> |
|
|
|
|
</block> |
|
|
|
|
</iq>]]></example> |
|
|
|
|
<p> |
|
|
|
|
Servers that receive a blocking command with a report MUST block the JID or |
|
|
|
|
return an error just as they would if no report were present. Servers then |
|
|
|
|
MAY take other actions based on the report, however, such actions are |
|
|
|
|
outside the scope of this document. |
|
|
|
|
return an error just as they would if no report were present. |
|
|
|
|
Servers then MAY take other actions based on the report, however, such |
|
|
|
|
actions are outside the scope of this document. |
|
|
|
|
</p> |
|
|
|
|
<p> |
|
|
|
|
If the server supports &xep0313; the report MAY also include the stanza-id |
|
|
|
|
of specific messages being reported. |
|
|
|
|
This is done by including copies of each <stanza-id/> element that the |
|
|
|
|
user wishes to report as a child of the <report/> element. |
|
|
|
|
The stanza indicated by the provided stanza-id SHOULD be by the same JID |
|
|
|
|
being reported and blocked. |
|
|
|
|
</p> |
|
|
|
|
<example caption='Report sent with stanza IDs'><![CDATA[ |
|
|
|
|
<iq from='juliet@example.com/chamber' type='set' id='block1'> |
|
|
|
|
<block xmlns='urn:xmpp:blocking'> |
|
|
|
|
<item jid='romeo@example.net'> |
|
|
|
|
<report xmlns="urn:xmpp:reporting:1" reason="urn:xmpp:reporting:spam"> |
|
|
|
|
<stanza-id xmlns='urn:xmpp:sid:0' by='romeo@example.net' id='28482-98726-73623'/> |
|
|
|
|
<stanza-id xmlns='urn:xmpp:sid:0' by='romeo@example.net' id='38383-38018-18385'/> |
|
|
|
|
<text xml:lang="en"> |
|
|
|
|
Never came trouble to my house like this. |
|
|
|
|
</text> |
|
|
|
|
</report> |
|
|
|
|
</item> |
|
|
|
|
</block> |
|
|
|
|
</iq>]]></example> |
|
|
|
|
</section1> |
|
|
|
|
<section1 topic='Implementation Notes' anchor='impl'> |
|
|
|
|
<p> |
|
|
|
|
Clients that support sending reports as part of the blocking command SHOULD |
|
|
|
|
expose interfaces to both block a JID without reporting it as abusive, and |
|
|
|
|
to block and report a JID. |
|
|
|
|
expose interfaces to both block a JID without reporting it as abuse, and to |
|
|
|
|
block and report a JID. |
|
|
|
|
</p> |
|
|
|
|
<p> |
|
|
|
|
The blocking command may be used to block multiple JIDs at the same time. |
|
|
|
|
When blocking multiple JIDs any abuse report only applies to a single JID. |
|
|
|
|
If the client allows selecting multiple JIDs in an abuse reporting dialog |
|
|
|
|
they SHOULD also allow choosing a separate reason, text, and messages for |
|
|
|
|
each JID. |
|
|
|
|
They MAY choose to only allow reporting a single JID at a time as well when |
|
|
|
|
the "block and report" dialog is accessed, and multiple JIDs when the |
|
|
|
|
"block" dialog is accessed. |
|
|
|
|
</p> |
|
|
|
|
</section1> |
|
|
|
|
<section1 topic='Internationalization Considerations' anchor='i18n'> |
|
|
|
@ -170,7 +215,7 @@
@@ -170,7 +215,7 @@
|
|
|
|
|
<section2 topic='Protocol Namespaces' anchor='registrar-ns'> |
|
|
|
|
<p>This specification defines the following XML namespace:</p> |
|
|
|
|
<ul> |
|
|
|
|
<li>urn:xmpp:reporting:0</li> |
|
|
|
|
<li>urn:xmpp:reporting:1</li> |
|
|
|
|
</ul> |
|
|
|
|
<p> |
|
|
|
|
Upon advancement of this specification from a status of Experimental to |
|
|
|
@ -188,15 +233,13 @@
@@ -188,15 +233,13 @@
|
|
|
|
|
All abuse report reason registrations shall be defined in separate |
|
|
|
|
specifications (not in this document). Application types defined within |
|
|
|
|
the XEP series MUST be registered with the XMPP Registrar, resulting in |
|
|
|
|
protocol URNs of the form "urn:xmpp:reporting:reason:name:X" (where |
|
|
|
|
"name" is the registered name of the reason and "X" is a non-negative |
|
|
|
|
integer). |
|
|
|
|
protocol URNs representing the reason. |
|
|
|
|
</p> |
|
|
|
|
®PROCESS; |
|
|
|
|
<code> |
|
|
|
|
<![CDATA[<reason> |
|
|
|
|
<name>The name of the abuse report reason.</name> |
|
|
|
|
<urn>urn:xmpp:reporting:reason:{name}:{ver}</urn> |
|
|
|
|
<name>The human-readable name of the abuse report reason.</name> |
|
|
|
|
<feature>URN representing the reason.</feature> |
|
|
|
|
<desc>A natural-language summary of the reason.</desc> |
|
|
|
|
<doc> |
|
|
|
|
The document in which the report reason is specified. |
|
|
|
@ -206,8 +249,8 @@
@@ -206,8 +249,8 @@
|
|
|
|
|
<section2 topic='Abuse Reporting Reasons' anchor='registrar-reasons'> |
|
|
|
|
<p>This specification defines the following abuse reporting reasons:</p> |
|
|
|
|
<ul> |
|
|
|
|
<li>urn:xmpp:reporting:reason:spam:0</li> |
|
|
|
|
<li>urn:xmpp:reporting:reason:abuse:0</li> |
|
|
|
|
<li>urn:xmpp:reporting:spam</li> |
|
|
|
|
<li>urn:xmpp:reporting:abuse</li> |
|
|
|
|
</ul> |
|
|
|
|
<p> |
|
|
|
|
Upon advancement of this specification from a status of Experimental to |
|
|
|
@ -216,15 +259,15 @@
@@ -216,15 +259,15 @@
|
|
|
|
|
</p> |
|
|
|
|
<code><![CDATA[ |
|
|
|
|
<reason> |
|
|
|
|
<name>Spam</name> |
|
|
|
|
<urn>urn:xmpp:reporting:reason:spam:0</urn> |
|
|
|
|
<name>spam</name> |
|
|
|
|
<feature>urn:xmpp:reporting:spam</feature> |
|
|
|
|
<desc>Used to report a JID that was sending spam messages.</desc> |
|
|
|
|
<doc>XEP-0377</doc> |
|
|
|
|
</reason>]]></code> |
|
|
|
|
<code><![CDATA[ |
|
|
|
|
<reason> |
|
|
|
|
<name>Abuse</name> |
|
|
|
|
<urn>urn:xmpp:reporting:reason:abuse:0</urn> |
|
|
|
|
<name>abuse</name> |
|
|
|
|
<feature>urn:xmpp:reporting:abuse</feature> |
|
|
|
|
<desc>Used to report general abuse that is not covered by a more specific reason.</desc> |
|
|
|
|
<doc>XEP-0377</doc> |
|
|
|
|
</reason>]]></code> |
|
|
|
@ -243,5 +286,9 @@
@@ -243,5 +286,9 @@
|
|
|
|
|
Stout, and Matthew Wild. A special thanks to Daniel Wisnewski for giving |
|
|
|
|
the presentation that kicked off the anti-abuse work. |
|
|
|
|
</p> |
|
|
|
|
<p> |
|
|
|
|
Thanks also (in no particular order) to Jonas Wielicki, Georg Lukas, |
|
|
|
|
Daniel Gultsch, and Matthew Wild for their feedback. |
|
|
|
|
</p> |
|
|
|
|
</section1> |
|
|
|
|
</xep> |
|
|
|
|