Matrix-doc: Users should always be able to self-redact.

[ara4n]

It's a basic data protection right that users should be able to have a chance to try to redact messages they accidentally send, wherever they send the. GDPR legislation probably makes this a requirement anyway come May 2018.

Right now we can apparently disable self-redactions by setting the m.room.redaction event threshold in the m.room.power_levels state event. We should consider how best to stop this from working.

(Yes, I agree that self-redactions can be very annoying, but I'm hoping that once we have editable messages the most annoying usage of them will go away).

[turt2live]

Some issues that reference this are:

• https://github.com/vector-im/riot-web/issues/5270
• https://github.com/vector-im/riot-web/issues/4005
• https://github.com/matrix-org/matrix-react-sdk/pull/1511
• https://github.com/matrix-org/matrix-react-sdk/pull/1477
• https://github.com/matrix-org/matrix-react-sdk/pull/1476
• https://github.com/matrix-org/matrix-doc/issues/720

[turt2live]

There's also a bit of discussion about the problem scenario around here in #riot-dev https://matrix.to/#/!DdJkzRliezrwpNebLk:matrix.org/$15107004782379424SKIJk:matrix.org

[richvdh]

I'm keen not to special-case m.room.redaction as far as the power_levels go (and in any case changing the interpretation of power_levels is hard without forking the federation protocol).

So if we were to do this I guess I would prefer it to be done at the C-S level by looking for attempts to send a power_levels event which set the m.room.redaction level above that of an m.room.message. Of course that might still allow people to send such events via other server implementations.

However, in practice I'm not sure how much of a problem this is. We can advise people not to configure their rooms to block redactions, but even if the GDPR mandates that ability, I'm not convinced it's the protocol's job to enforce it. There are plenty of other ways that the matrix protocol lets you break the law if you want to.

In conclusion: my vote would be to leave this as-is from the protocol point of view. Not exposing the option in Riot is sufficient.

[ara4n]

Okay, @richvdh has convinced me to his point of view. We can make it a client problem to decide how/if to expose it.

[saurik]

OK, so given this discussion, how can people who believe the exact opposite—specifically, that the ability for people to delete one part of a multi-user conversation has absolutely nothing to do with "controlling their data" and is in fact a way of "destroying other peoples'" data, and that this feature is primarily used by people attempting to "gaslight" other users (by deleting any record that they said something evil)—change this setting? (FWIW, I absolutely do not believe that the GDPR requires this of a service; in fact, the entire notion is "absurd": it is like some kind of weird mechanism where I can remotely delete an e-mail message. This is a fundamentally different use case to something like a photo album where you simply gave other people access: this is a mechanism whereby people can somehow delete information from the public record. I mean, let's even attack it from this angle: I'm an elected government official, and the data retention policies that apply to me make it so that if you send me something and then somehow can retroactively unsend it then I'm no longer in legal compliance for being able to satisfy public information requests.)

[ara4n]

Hi @saurik - thanks for dropping by. The conclusion here is that today you can set the access threshold required for m.room.redaction in a room such that users are unable to self-redact.

Our current understanding of the GDPR requirements are that in a public room, the data is probably considered owned solely by the author, and they should have the right to erase whatever idiocy they posted on the public internet. However, in a private room, the data should be considered jointly owned by all participants, and those rooms can be configured if desired to stop self-redactions if desired (e.g. for public officials).

One could also configure redactions to quarantine but not delete content on a given server, as another way of tackling the 'public official' problem.