MSC2723: Forwarded message metadata #2723

hummlbach · 2020-08-12T14:14:00Z

Signed-off-by: Johannes Renkl hummlbach@posteo.de

A proposal to properly support marking forwards as what they are.

Thx to @Sorunome and @krille for getting things straight.

- m.forward -> m.forwarded - added unstable prefix section - added event_id

turt2live · 2020-08-12T14:16:10Z

@hummlbach when you get the chance, please sign off on the changes and line wrap them for review.

hummlbach · 2020-08-12T14:19:02Z

Okay, will do.

proposals/2723-add-forward-info.md

Half-Shot

(part one of review - github ate my review comments)

Half-Shot · 2020-08-12T14:16:29Z

proposals/2717-add-forward-info.md

+1. The forwarder adds `displayname` and `avatar_url` to `m.forwarded`.
+2. The receiving client resolves the `displayname` and the `avatar_url` from the user id given by `sender` using `/_matrix/client/r0/profile/{userId}`.
+
+Both solutions have a drawback. In case of 1., changing the display name or the avatar would not be reflected in forwards. And the avatar URL may even become invalid(?). The second solution may cause confusion is the original sender has set different display names and avatars for different rooms. I.e. if the original sender is in the room where the message is forwarded to, it may appear there under a different display name and avatar.


Probably the gravest drawback is you can forge the identity of the sender entirely and there isn't much you can do to verify it if you aren't in the room. Given there is huge scope for abuse in writing nasty messages in a private room that you own, and then forwarding them as @alice:example.com, we should be careful there.

The one thing clients could do is highlight the unreliable-ness of the information, but I worry that's a pretty weak defense.

Half-Shot · 2020-08-12T14:20:12Z

proposals/2717-add-forward-info.md

+            "sender": "@someone:example.org",
+            "origin_server_ts": 1432735824141
+        },
+        "msgtype": "m.location"


personal nit: probably would be better to use a simple m.text to explain this, as the m.location format adds additional complexity to the example.

Half-Shot · 2020-08-12T14:23:07Z

proposals/2717-add-forward-info.md

+Both solutions have a drawback. In case of 1., changing the display name or the avatar would not be reflected in forwards. And the avatar URL may even become invalid(?). The second solution may cause confusion is the original sender has set different display names and avatars for different rooms. I.e. if the original sender is in the room where the message is forwarded to, it may appear there under a different display name and avatar.
+
+### Clients can fake forwards
+Should we care of/can we avoid "fake forwards"? Does it make sense/is it possible at all to only add the original `event_id` when sending a forward and assign the server the responsibility of adding the forward information?


I think you're going to have to accept that fake forwards will exist in the federation and there is little you can do to avoid them, and the onus should be on the recipient to verify what it can. Even if the server is responsible for adding the metadata, the servers can lie just as easily as a client.

proposals/2723-add-forward-info.md

tulir · 2020-08-12T14:33:12Z

proposals/2723-add-forward-info.md

+### Clients can fake forwards
+Should we care of/can we avoid "fake forwards"? Does it make sense/is it possible at all to only add the original `event_id` when sending a forward and assign the server the responsibility of adding the forward information?
+
+## Alternatives


Has including the whole federation event data been considered (i.e. include the signatures and everything)? Having the signatures and exact content would allow the recipient servers to validate the event and thus prevent faking forwards.

The only drawbacks I can think of are:

it needs server support to send and validate forwards

forwarding big events (close to the 64 KiB federation limit) wouldn't be possible

I might be missing something, but even if it's not a viable option, the reasoning should be documented.

No, we haven't considered that yet (at least not me).

Then the client would need to verify the federation signatures, though, can it even do that?

The server could verify that the signatures / content of the included event were signed by the homeserver that originally sent it. The homeserver could include a key in unsigned to notify the client about it's trustworthyness.

I went ahead and drafted something for this: #2730

The problem with forwarding the whole event with signatures is that it becomes impossible to redact data that should not be shared. This means that we are committing to including all data covered by the signature in a forward which may be more information than was intended to be shared.

- fixed typos - fixed title - removed dead link - removed obsolete line regaring event_id - line wrap

erkinalp · 2021-03-23T20:11:41Z

proposals/2723-add-forward-info.md

@@ -0,0 +1,116 @@
+# MSC2723: Forwardes message metadata


Suggested change

# MSC2723: Forwardes message metadata

# MSC2723: Forwarded message metadata

kevincox · 2021-03-26T00:13:21Z

proposals/2723-add-forward-info.md

+        "geo_uri": "geo:51.5008,0.1247",
+        "m.forwarded": {
+            "event_id": "$123275682943PhrSn:example.org",
+            "room_id": "!jEsTZKDJdhfrheTzSU:example.org",


In some cases rooms are "private by knowledge" in this case sharing the room_id may inadvertently let point join. This has to be considered carefully and I think this MSC should at least include a warning that implementing clients should warn users.

kevincox · 2021-03-26T00:15:58Z

proposals/2723-add-forward-info.md

+### Clients can fake forwards
+Should we care of/can we avoid "fake forwards"? Does it make sense/is it possible at all to only add the original `event_id` when sending a forward and assign the server the responsibility of adding the forward information?
+
+## Alternatives


The problem with forwarding the whole event with signatures is that it becomes impossible to redact data that should not be shared. This means that we are committing to including all data covered by the signature in a forward which may be more information than was intended to be shared.

shoqvalue · 2022-12-22T23:33:14Z

I can't tell what the status of this is now, but I have problems with this issue every day. It creates a situation where someone forwards something by someone else, and everyone thinks they said it. Why not at least let the user caption their forwarded message. Or just say "shoq forwarded this" automatically. That doesn't require anything but what you have now with a caption added and solves most of the problem. It doesn't attempt a to find a perfect forward solution, just something that helps stop misattribution and misunderstandings. It's quite disruptive to the chat to have to backtrack and say "hey, I didn't write that, I just forwarded it."

Johannes Renkl added 6 commits July 31, 2020 03:47

Very early draft of forward info proposal

ad720c4

This and that

29c7cb9

Details about resolving displayname and avatar

d8d6628

According to review by @Sorunome

6c20d89

- m.forward -> m.forwarded - added unstable prefix section - added event_id

Rename according to pull request number

110bd6a

Okay, guessed PR number wasn't right, fixed it

26e3524

turt2live added kind:feature MSC for not-core and not-maintenance stuff proposal A matrix spec change proposal proposal-in-review labels Aug 12, 2020

turt2live changed the title ~~Proposal forward info~~ MSC2723: Forwarded message metadata Aug 12, 2020

uhoreg reviewed Aug 12, 2020

View reviewed changes

proposals/2723-add-forward-info.md Outdated Show resolved Hide resolved

uhoreg reviewed Aug 12, 2020

View reviewed changes

proposals/2723-add-forward-info.md Outdated Show resolved Hide resolved

Half-Shot reviewed Aug 12, 2020

View reviewed changes

proposals/2723-add-forward-info.md Outdated Show resolved Hide resolved

Half-Shot reviewed Aug 12, 2020

View reviewed changes

proposals/2723-add-forward-info.md Outdated Show resolved Hide resolved

Half-Shot reviewed Aug 12, 2020

View reviewed changes

proposals/2723-add-forward-info.md Outdated Show resolved Hide resolved

tulir reviewed Aug 12, 2020

View reviewed changes

Easy fixes according to review

acea085

- fixed typos - fixed title - removed dead link - removed obsolete line regaring event_id - line wrap

This was referenced Aug 12, 2020

MSC2730: Verifiable forwarded events #2730

Open

Forwarding a message should show who it was from element-hq/element-meta#884

Closed

tulir mentioned this pull request Mar 7, 2021

Don't reupload media when sharing to another room element-hq/element-android#2967

Open

erkinalp suggested changes Mar 23, 2021

View reviewed changes

kevincox reviewed Mar 26, 2021

View reviewed changes

turt2live added the needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. label Jun 8, 2021

turt2live force-pushed the old_master branch from e895827 to dca99ee Compare August 30, 2021 22:34

MadLittleMods mentioned this pull request Oct 13, 2021

MSC2923: Connect Matrix room to another Matrix room #2923

Draft

2 tasks

stefanceriu mentioned this pull request Oct 19, 2021

Message forwarding element-hq/element-ios#5014

Merged

turt2live removed the proposal-in-review label May 5, 2022

Sazu-bit mentioned this pull request Dec 22, 2022

Add "Forwarded by" to Forwarding option element-hq/element-web#24096

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

MSC2723: Forwarded message metadata #2723

MSC2723: Forwarded message metadata #2723

hummlbach commented Aug 12, 2020 •

edited

Loading

turt2live commented Aug 12, 2020

hummlbach commented Aug 12, 2020

Half-Shot left a comment

Half-Shot Aug 12, 2020

Half-Shot Aug 12, 2020

Half-Shot Aug 12, 2020

tulir Aug 12, 2020 •

edited

Loading

hummlbach Aug 12, 2020

Sorunome Aug 12, 2020

Half-Shot Aug 12, 2020

tulir Aug 12, 2020

kevincox Mar 26, 2021

erkinalp Mar 23, 2021

kevincox Mar 26, 2021

kevincox Mar 26, 2021

shoqvalue commented Dec 22, 2022

	# MSC2723: Forwardes message metadata
	# MSC2723: Forwarded message metadata

MSC2723: Forwarded message metadata #2723

Are you sure you want to change the base?

MSC2723: Forwarded message metadata #2723

Conversation

hummlbach commented Aug 12, 2020 • edited Loading

turt2live commented Aug 12, 2020

hummlbach commented Aug 12, 2020

Half-Shot left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tulir Aug 12, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

shoqvalue commented Dec 22, 2022

hummlbach commented Aug 12, 2020 •

edited

Loading

tulir Aug 12, 2020 •

edited

Loading