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 < [email protected]> 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 >
_______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
