“Report Spam and Block” silently performs only a block when server-side reporting is unsupported #21
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
“Report Spam and Block” silently performs only a block when server-side reporting is unsupported
Severity: Major
When a user selects “Report Spam and Block”, they reasonably expect both actions to be performed. However, if the server does not support XEP-0377 reporting (urn:xmpp:reporting:1), libtacky silently performs only a regular block, and the iOS application provides no feedback that the spam report was not sent.
Environment
anotherim-swift
8f62071(feat/ui-redesign, build 94)libtacky 2f42a2f2 (v1.2.0-beta2)
Test server: ejabberd 26.09, configuration from anotherim-server b9e675d
The test server does not advertise urn:xmpp:reporting:1.
Steps to reproduce
Ensure the server does not advertise urn:xmpp:reporting:1 via disco#info.
Receive a message from a JID that is not in the user's roster.
Select Block → Report Spam and Block.
Inspect the outgoing stanza and the libtacky response.
The application invokes blocking report -jid -reason spam (ChatDetailsClient+Live.swift:276).
Actual result
No element is sent.The outgoing request contains only a regular block:
libtacky returns:
answer report ok blocked
The application discards the response:
_ = try await env.api().backend.request(...)
As a result, the user receives no indication that only blocking was performed.
Reproducibility: 2/2 test runs (223779c8, befb50b6).
Expected result
After selecting “Report Spam and Block”, either:
the spam report should be sent successfully; or
the user should be informed that the server does not support spam reporting and that only blocking was performed.
Root cause
libtacky checks for server support:
set reported [$client caps serverHas urn:xmpp:reporting:1]
When reporting is unsupported, it sends only a plain block request and returns blocked. The application already has a comment documenting this behavior but ignores the returned result.
Suggested fix
Read the result of the blocking report request and, when it returns blocked, inform the user that the server does not accept spam reports.
Alternatively, hide or disable “Report Spam and Block” when the server does not advertise urn:xmpp:reporting:1.
If spam reporting is required on another.im, enable XEP-0377 support server-side.
Note: Production another.im has not yet been checked for urn:xmpp:reporting:1. If production supports reporting, the issue should be narrowed to missing user feedback and the severity reconsidered.
4832765: if the server answers blocked (no XEP-0377 support), the user sees "Blocked, but your server does not accept spam reports, so none was sent."