search

matrix-org / matrix-spec

The Matrix protocol specification
Apache License 2.0
197 stars 97 forks source link

Cannot redact messages sent before a room was upgraded #1291

Open ell1e opened 2 years ago

ell1e commented 2 years ago

Description

(Forwarded from https://github.com/vector-im/element-web/issues/23446 )

The missing removal ability for messages in the old copies of upgraded rooms seems like a privacy flaw given the dumping of all "anyone" history rooms on the matrix.org homeserver into the Google index via view.matrix.org. Since not only will most people be unaware, once they find out they can't even remove their contents again since the old, otherwise inaccessible pre-upgraded rooms seem to remain indexed. I think that's pretty bad.

Steps to reproduce

  1. Speak in a room with history visibility "anyone"
  2. Room gets upgraded
  3. Before you click the upgrade button, search any of your old messages still in the old room view and try to delete it. Doesn't work.
  4. After clicking the upgrade button you can't even access your messages or see the history anymore, let alone delete it.
  5. Find your message on view.matrix.org in the google index and that there is no way to delete it, especially once you reached Step 4.

Homeserver

matrix.org

Synapse Version

1.69.0rc2 (b=matrix-org-hotfixes,3d5242da14)

Installation Method

No response

Platform

I'm using the home server with element on the official matrix.org server.

Relevant log output

I don't have server access

Anything else that would be useful to know?

I think there is one fundamental condition that should always be satisfied: I should EITHER still have both the permissions to delete all old messages and a practical way to do so after a room upgrade (which means also some easy to find way to access that history), OR all the pre-upgrade messages should get wiped from the homeserver and especially sharing mechanisms like view.matrix.org.

turt2live commented 2 years ago

This looks like an implementation error - upgrading the room does not inherently prevent redacting your messages.

richvdh commented 2 years ago

well maybe let's move it to the right place rather than just close it out of hand?

richvdh commented 2 years ago

https://spec.matrix.org/v1.4/client-server-api/#server-behaviour-16 says:

If possible, the power levels in the old room should also be modified to prevent sending of events and inviting new users.

As a reminder, redacting an event is implemented by sending an m.room.redaction event.

So, I'd say Synapse is following the spec by blocking these redactions.

ell1e commented 2 years ago

Oh, my bad, I actually mixed up the browser tabs and I'm pretty sure I meant to file this in the synapse server repository (after that being suggested in the element ticket). My apologies for the mix-up.

turt2live commented 2 years ago

well maybe let's move it to the right place rather than just close it out of hand?

without more information it's pretty difficult to tell who is at fault here, and the entity at fault could very well be in a different org.

https://spec.matrix.org/v1.4/client-server-api/#server-behaviour-16 says:

If possible, the power levels in the old room should also be modified to prevent sending of events and inviting new users.

As a reminder, redacting an event is implemented by sending an m.room.redaction event.

So, I'd say Synapse is following the spec by blocking these redactions.

Is Synapse actually preventing it? That would be extremely surprising given the context of the spec (I think the spec is lying). The issue also wasn't clear if Synapse was doing this.

richvdh commented 2 years ago

Oh, my bad, I actually mixed up the browser tabs and I'm pretty sure I meant to file this in the synapse server repository (after that being suggested in the element ticket). My apologies for the mix-up.

you did, and I moved it here, because I thought it was a protocol problem rather than a synapse one. As @turt2live is pointing out, it might be more complicated than this.

richvdh commented 2 years ago

So, I'd say Synapse is following the spec by blocking these redactions.

Is Synapse actually preventing it?

I believe so. It sends out an m.room.power_levels for the upgraded room with events_default:50, and no exception for m.room.redaction.

I think that's what the spec says, though maybe Synapse is interpreting it too literally.

turt2live commented 2 years ago

Worth noting that we've previously declared something like this a feature of the protocol: https://github.com/matrix-org/matrix-spec-proposals/issues/1071

However, this does appear to be a regrettable case dating back to MSC1501's original text:

  • Assuming Alice has the powers to do so, sets the power levels in the old room to stop people speaking. In practice, this means setting events_default and invite to the greater of 50 and users_default+1.

Which would indeed trigger the inability to self-redact, which we've also declared to be mostly a feature when done this way. Do we still think it's a feature? (this is a potentially larger question that doesn't actually need an aswer right away)

ell1e commented 1 year ago

FWIW, and IANAL, but maybe (and I could be entirely wrong) in some jurisdictions, especially EU, not being able to redact later seems like it's at least kind of against the spirit of the current trend of regulations although I wouldn't know at all how the legal situation of that is.