MSC4202: Reporting User Profiles #4202
Conversation
tcpipuk
changed the title
tcpipuk
force-pushed
the
user-reporting
branch
from
a0f12c7
to
b5bdc5e
Compare
tcpipuk
force-pushed
the
user-reporting
branch
from
b5bdc5e
to
bedd16c
Compare
|
This MSC is dependent on #3843 to allow users to report inappropriate users (e.g. offensive MXID, or inappropriate user profile content) rather than a specific event. |
tulir
added
proposal
There was a problem hiding this comment.
Implementation requirements:
- Client
(as this MSC depends on #3843, a server implementation is only needed for that MSC and not this one)
There was a problem hiding this comment.
@tulir would it be ok to amend this requirement following the removal of the API change?
proposals/4202-user-reporting.md
Outdated
| } | ||
| ``` | ||
|
|
||
| The homeserver SHOULD ensure that the `event_id` being reported corresponds to an `m.room.member` |
There was a problem hiding this comment.
Could the homeserver actually do this given that the client uses the generic POST /_matrix/client/v3/rooms/{roomId}/report/{eventId} endpoint which is also going to be used for reporting other events?
There was a problem hiding this comment.
Ah yes, thanks for catching that - I think it's left over from when I was modifying the endpoint to accept MXIDs!
I'll fix it this morning 🙂
There was a problem hiding this comment.
The homeserver SHOULD ensure that the event_id corresponds to an event in the room and SHOULD verify that the event was issued by the reported user's homeserver.
I think the second part of this sentence might still be a leftover? The reported user is only identified implicitly via the event ID pointing to a membership event. So I suppose there's no way the server could verify that event against the user that was intended to be reported?
For the first part of the sentence, I'm actually surprised this isn't already spelled out as a MUST in the spec. I suppose this is what the 404 response was meant for. Would there be any cases in which the server should accept an event report for an event that's not in the room? 🤔
There was a problem hiding this comment.
Ah, I agree the wording is a bit awkward... I meant to say the server should verify it owns the user that created the event being reported. I'll have another go!
To your second point, I also agree. I suppose it's possible this server may not be aware of the event anymore (e.g. we lost our database) but we could backfill that event if necessary to verify that event comes from this room. I'd hope most implementations will perform those kind of sanity checks, but I didn't want to go so far as to apply a "must" to it.
There was a problem hiding this comment.
To your second point, I also agree. I suppose it's possible this server may not be aware of the event anymore (e.g. we lost our database) but we could backfill that event if necessary to verify that event comes from this room. I'd hope most implementations will perform those kind of sanity checks, but I didn't want to go so far as to apply a "must" to it.
Makes sense, yeah. 👍
tcpipuk
changed the title
| - **Privacy**: Reporting an `m.room.member` event includes the profile information set by the user | ||
| in that room. Servers SHOULD handle this data appropriately and respect user privacy. | ||
|
|
||
| ## Potential Issues |
There was a problem hiding this comment.
One to add is that this might (as like with most moderation things on server level) have the issue that server and room rules may differ. A profile might be considered ok by the server admin, while it isn't ok for the room where the user is in. So this proposal only adds server level moderation but still no full room level moderation imho. It solves parts of the issues, but not all of them, imho.
There was a problem hiding this comment.
Agreed, do you know if there's an MSC for reporting events to room admins so I could perhaps add that as a dependency here too?
Rendered
Signed-off-by: Tom Foster tom@tcpip.uk
Known Implementations: