Reply fallbacks leak room history

[NotAFile]

This isn't really a big issue, but when joining a room which only allows you to view messages after you join, you can see earlier messages by looking into the fallback of replies.

[t3chguy]

But you have no way of verifying them and knowing if they are the true history, its the same as someone posting a screenshot/quote of the history you do not have access to

[NotAFile]

sure, but chances are usually low that it's fake. Users might rely on the fact that e.g. riot doesn't let them access the message, without realizing the message is also embedded in the event data

[Half-Shot]

As per #14824, reply fallbacks also leak participant servers with the?via attribute in the permalinks. This isn't a problem if you are in the same room because you can easily determine this by looking at room state, but this is a problem if a reply fallback is forwarded to another room.

[turt2live]

@Half-Shot how is that any more problematic than someone dumping a permalink to the same event in the other room?

[Half-Shot]

A permalink is visible, and so the user can immediate see that they fucked up and can remove it. A reply fallback is rendered as "unable to render" in Element, but the source of the event contains the via data.

Ergo, one is a visible mistake and can be corrected immediately, the other is invisible.

[KitsuneRal]

Tbh (albeit offtopic here), the fact that reply fallbacks survive redactions seems a much bigger issue to me.

[Half-Shot]

I'm surprised that the fallback is not redacted. If so, that probably just makes the issue even worse as you can't redact the leak at all :| Misunderstood, not relevant to the issue after all.

[KitsuneRal]

If you redact the reply, the fallback gets redacted along with it. If you redact the message replied to, the reply fallback survives.

[MazeChaZer]

This problem is approached in MSC matrix-org/matrix-spec-proposals#2781.