MSC4084: Improving security of MSC2244 (Mass redactions)

[turt2live]

Rendered

Implementation requirements:

• Unstable room version containing both MSC2244 and this MSC's changes.
• Example of a server processing redactions safely.
• Example of a client engaging in these rooms.

[ara4n]

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@...)

[turt2live]

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.

[KitsuneRal]

I guess MSC4117 is a potential answer to this?