Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
matrixbot opened this issue Feb 20, 2015 · 14 comments

Comments

@matrixbot
Copy link
Member

commented Feb 20, 2015

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

This comment has been minimized.

Copy link
Member Author

commented Feb 20, 2015

Jira watchers: @erikjohnston @ara4n

@matrixbot

This comment has been minimized.

Copy link
Member Author

commented Feb 20, 2015

Links exported from Jira:

is duplicated by SYN-493

@matrixbot

This comment has been minimized.

Copy link
Member Author

commented Jan 6, 2016

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

@matrixbot matrixbot added p2 bug labels Nov 7, 2016
@matrixbot matrixbot changed the title We need to actually censor redactions from the DB (SYN-284) We need to actually censor redactions from the DB (https://github.com/matrix-org/synapse/issues/1287) Nov 7, 2016
@matrixbot matrixbot changed the title We need to actually censor redactions from the DB (https://github.com/matrix-org/synapse/issues/1287) We need to actually censor redactions from the DB (SYN-284) Nov 7, 2016
@Mikaela

This comment has been minimized.

Copy link

commented Jul 14, 2017

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

@Mikaela

This comment has been minimized.

Copy link

commented Dec 10, 2018

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

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

@Mikaela

This comment has been minimized.

Copy link

commented Dec 19, 2018

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 comment has been minimized.

Copy link
Contributor

commented Jul 25, 2019

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
  1. 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

This comment has been minimized.

Copy link
Contributor

commented Jul 25, 2019

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

This comment has been minimized.

Copy link
Member

commented Jul 25, 2019

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.

@neilisfragile neilisfragile added this to Holding Pen in Homeserver Task Board via automation Jul 31, 2019
@neilisfragile neilisfragile moved this from Holding Pen to To Do in Homeserver Task Board Jul 31, 2019
@JonahAragon

This comment has been minimized.

Copy link

commented Aug 6, 2019

it could probably default to 0

To be clear, 0 means immediate deletion correct?

@cjdelisle

This comment has been minimized.

Copy link
Contributor

commented Aug 6, 2019

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

This comment has been minimized.

Copy link
Member

commented Aug 12, 2019

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

@cjdelisle

This comment has been minimized.

Copy link
Contributor

commented Aug 12, 2019

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

@erikjohnston erikjohnston self-assigned this Aug 29, 2019
@Mikaela Mikaela referenced this issue Sep 15, 2019
0 of 6 tasks complete
Homeserver Task Board automation moved this from To Do to Done Sep 23, 2019
@neilisfragile neilisfragile reopened this Sep 23, 2019
Homeserver Task Board automation moved this from Done to Holding Pen Sep 23, 2019
@neilisfragile neilisfragile moved this from Holding Pen to In progress in Homeserver Task Board Sep 23, 2019
@neilisfragile neilisfragile moved this from In progress to Review in Homeserver Task Board Sep 26, 2019
@neilisfragile neilisfragile moved this from Review to Done in Homeserver Task Board Sep 26, 2019
@erikjohnston

This comment has been minimized.

Copy link
Member

commented Sep 26, 2019

Fixed by #5934

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
10 participants
You can’t perform that action at this time.