5 Feb
2025
5 Feb
'25
2:53 p.m.
Hello,
After writing my original email, I got a bit of feedback from the XEP's
author out-of-band. They suggested making the additional field less
'vague', by using more explicit options. We briefly discussed the options
provided by equivalent functionality in Mastodon. I can see the value in
that.
I'd like to avoid introducing a large amount of options, as those would
probably confuse and/or be ignored by end-users.
Instead of the one field that I originally suggested, lets have two
boolean-based fields:
- Report to origin server
- Share with third-party services collecting statistics
These options roughly correspond with the options given in the "software
support" listing on xmppbl.org (see https://xmppbl.org/software )
Furthermore, I suggest that the XEP:
- Explicitly mentions that clients may offer the options to an end-user
whenever they are reporting a spam message, but also could use a
(configurable) default that is automatically applied.
- Define that servers MAY ignore 'true' values when their implementation
does not provide the corresponding functionality.
- Define that servers MUST NOT invoke corresponding functionality when
the fields are provided with a 'false' value.
- Discourages (SHOULD NOT) anonymizing the report to the origin server,
as it hurts processing without adding any significant protection: it is
likely that the origin server can easily look up the original stanza in
their local message archive anyway.
- Allows (MAY) anonymizing any submission to third-party analytical
services (with instructions: remove the 'to' but not 'from' address,
to
protect the reporter, but not the spammer)
- Define what the servers should do when the fields are not provided,
but when the server does implement the corresponding functionality. Should
that be a SHOULD NOT?
Unless there's feedback on this list within the next few days, I'll draft a
PR that applies these suggested changes to the XEP.
Kind regards,
Guus
On Mon, Feb 3, 2025 at 10:29 PM Guus der Kinderen <
guus.der.kinderen(a)gmail.com> wrote:
Hello,
XEP-0377 describes a mechanism to report spam or abusive content to the
local domain. While implementing the server-sided part of this, I was
trying to think of useful processes that could follow a report.
Some of those actions could include sharing the report with third parties,
such as the origin server of the spam, or a centralized spam-related
collection service (like xmppbl).
There is a privacy aspect to this. An end-user that flags a particular
message or entity might not realize or even appreciate that their report is
being forwarded to others than the local domain.
I suggest having an additional field added to the data structure that is
already defined in the XEP. This field is used by the reporter to signal if
they agree to share the report with third parties. Clients could present
this option as a checkbox that reads something like "Allow this report to
be shared with relevant third parties" (or better words).
Kind regards,
Guus