MSC4084: Improving security of MSC2244 (Mass redactions) #4084
Conversation
turt2live
changed the title
turt2live
added
proposal
|
|
||
| ## Alternatives | ||
|
|
||
| No significant alternatives not already discussed identified. |
There was a problem hiding this comment.
One thing that could mitigate abuse of this would be if it was reversible within a given timeframe - ie a cooling off or antiabuse or remorse timeframe. Same for account deactivation. Both could give the user a one-time code they could use to countermand the previous destructive action. If combined with a grace period for redactions in general (which most servers implement), this could be best of both worlds? (And stop floods of reactivation requests to support@...)
There was a problem hiding this comment.
The DAG level gets complicated for all kinds of reasons, but a possible approach here might be to split redactions into two events: one which applies the redaction, and another which actually commits to it. #3531 kinda does this, though a more direct approach would be to have m.room.soft_redaction go out to apply a redaction pending formal redaction. The operation would apply to clients (and maybe servers over the CS API but not storage?) so the effect can be quickly realized. Then, if the moderator or sender regrets that decision they can redact the soft redaction to "cancel" it. If not cancelled, either the client or the server could commit the redaction with today's m.room.redaction event.
Something to consider is who has the ability to undo a redaction, as it'd be a bit weird to think you've redacted your password from the public chat but then a moderator reveals it again.
There was a problem hiding this comment.
alternatively, we could mandate that servers should do a two-phase deletion, and put a recommended grace period on the (mass-)redactions? Then unredacting is "just" a case of someone sending an m.room.unredaction within the grace period (and you wouldn't need to include the content, given servers should still have it to hand).
There was a problem hiding this comment.
m.room.soft_redaction is additive to m.room.redaction, I don't think it would even require a new room version. Changing the semantics of m.room.redaction would probably require a new room version to make sure users can tell between reversible and irreversible redactions.
reivilibre
changed the title
|
|
||
| To help ensure that malicious actors are not able to effectively deactivate a user's account, the | ||
| existing [`PUT /_matrix/client/v3/rooms/:roomId/send/:eventType/:txnId`](https://spec.matrix.org/v1.9/client-server-api/#put_matrixclientv3roomsroomidsendeventtypetxnid) | ||
| endpoint MUST NOT accept `m.room.redaction` events in room versions supporting mass redactions. The |
There was a problem hiding this comment.
this can probably be relaxed to "m.room.redaction events targeting more than one event" rather than "thou shall not redact"
| To ensure that clients are able to actually use mass redactions, a copy of `/send` is introduced with | ||
| [User-Interactive Authentication](https://spec.matrix.org/v1.9/client-server-api/#user-interactive-authentication-api) | ||
| (UIA) optionally used by the server. The new `PUT /_matrix/client/v4/rooms/:roomId/send/:eventType/:txnId` |
There was a problem hiding this comment.
UIA is now "legacy" and replaced in part by OAuth2: https://spec.matrix.org/v1.15/client-server-api/#client-authentication
It's not clear how to use OAuth2 for UIA-like features like this.
Rendered
Implementation requirements: