We need to actually censor redactions from the DB (SYN-284)

[matrixbot]

We don't seem to remove redacted event contents from the DB when they are redacted. This kinda defeats the point; we should.

(Imported from https://matrix.org/jira/browse/SYN-284)

(Reported by @ara4n)

[matrixbot]

Jira watchers: @erikjohnston @ara4n

[matrixbot]

Links exported from Jira:

is duplicated by SYN-493

[matrixbot]

My first question is: what is the point of the current redactions system? The current implementation of it seems to be trying to do two separate things.

Originally, the intent was that redactions should be used to remove content that server admins wouldn't want on their server, e.g. illegal content. In this scenario it's important that admins can cause redacted content to be deleted. The idea was to have an admin API that allowed you to look at the redacted event before deciding whether or not to delete it.

However, people can now redact their own events, which is used as a crude "retraction" mechanism. In my opinion these shouldn't be auto deleted (and also shouldn't be flagged to server admins lest they look at the retracted content). For example, if someone sends a bunch of abusive messages into Matrix HQ and later retracts them, moderators still need to be able to see what those messages were when people complain so that they can take the appropriate action.

On a more practical level, whether we delete content or not is not something we can enforce on a server. Certainly the first thing I would do would be to disable it on my server, and I'm fairly sure I would not be in the minority in doing that. Why? Because its infuriating to have messages disappear while I'm reading/responding simply because the author decided to or accidentally redacted their event, which has happened several times now. Given this, I'm not entirely sure what the purpose or need of having redacted events auto deleted from any server really is.

My opinion on this mess is: we should have separate redact and retract mechanisms and implement the admin API for dealing with redactions, but never delete retractions from the DB (we could possibly have a separate flag for asking server admins to redact the event).

-- @erikjohnston

[Mikaela]

Is this the issue behind matrix-org/matrix-appservice-irc#473 or should I open a new one?

[Mikaela]

Are there any news on this or how does GDPR affect this and referenced issues?

I started thinking about this/them more, because of mautrix/telegram#248 and t2bot/t2bot.io#15.

[Mikaela]

From the duplicate #3211 (comment):

@richvdh commented on May 11:
(we'll be fixing this for GDPR)

GDPR has been in force for months. Is anyone from Matrix.org following this issue? I seem to have asked previously asked about this nine days ago.

[cjdelisle]

This is kind of an important issue AFAICT because redactions are the only way to signal non-consent to processing of data. Imagine the following:

1. Person joins #matrix and sends a message
2. They decide that message was not what they want to send

• Consent can be withdrawn
• In a most obvious case, lets imagine a 12 year old sent their name and address and then a parent noticed what was happening and intervened. When the data subject is a minor, no justification needs to be given

3. Knowing that the "remove" button doesn't actually delete the message, the person is completely within their rights to send a GDPR request to the operators of each and every synapse server that federates #matrix

• If this issue is fixed, then the person is nolonger within their rights to send a GDPR request to each server operator because there is an obvious technical solution
• This has a high probability of being attacked to grief the network in one of two ways:
  a. Create an undelete bot which is able to repeat the content of a deleted message, thus illustrating the elusiveness of the remove button
  b. Create a service which sends GDPR email to every known server operator
• To add to the mess, the griefter might also begin recommending people upgrade to their "gdpr-compliant" fork of synapse, giving them a user base and thus a seat at the table in protocol design discussions.

[t3chguy]

within their rights to send a GDPR request to the operators of each and every synapse server that federates #matrix

I'm not so sure this is actually true, assume for a second that my homeserver serves only users outside of the EU, but is in the room, I would have no reason to comply with GDPR.
I mean similarly, if I GDPR gmail, do I really have a stance to GDPR the mail server of every person I have ever emailed?

[ara4n]

the right soln here imo is to provide a server admin specific setting for how long to keep redactions before GCing them. it could probably default to 0 other than for server admins who need an audit trail of the abuse on their platform.

[jonaharagon]

it could probably default to 0

To be clear, 0 means immediate deletion correct?

[cjdelisle]

FYI there's a temporary fix which people can implement on their own homeserver in order to:

1. Clear redacted messages
2. Drop rooms which nolonger have any members on your HS

https://github.com/xwiki-labs/synapse_scripts/blob/master/synapse_janitor.sql

On a synapse which I used to administer, this is setup in a crontab which brings the server down once per week, runs these, and then re-launches it.

[anoadragon453]

Is this going to be covered by Brendan's PR? #5815

[cjdelisle]

I just checked the code and it looks like a no.

[erikjohnston]

Fixed by #5934