MSC2192: Inline widgets

[turt2live]

Rendered

Disclaimer: This is currently a set of ideas and may not be complete or ideal.

Early implementation: matrix-org/matrix-react-sdk#3252
For https://github.com/vector-im/riot-web/issues/10060 and related issues.

[turt2live]

@BillCarsonFr please always use threads so things can be replied to. I've moved your comments.

[NotAFile]

I think this concept is really flawed and this msc should not be accepted with it in place, for a few reasons:

• Embedding arbitrary, interactive, user-defined content directly into the timeline is an absolute dream for phishers. Since clients like Riot already often ask users for passwords, a correctly styled "Enter your password to view message" widget would likely trick most users.
• Embedding widgets is also a dream for tracking and de-anonymisation. Get people's IP addresses, fingerprint their browsers, and connect it to their mxid.
• The above applies to room widgets too but: the nature of them being embedded in the timeline makes the required level of education infeasible. Since they are ephemeral, a confirmation would be required every time the widget is viewed. Big scary popups will quickly lead to dialog fatigue.
• It makes non-web clients second class citizens and more or less forces all clients which want to provide a full-featured room timeline view to more or less embed chromium inside their app. Widgets made specifically for matrix will be styled to match a specific client, and look out of place in everything else.
• Even if native clients solve this, it still prevents them from offering better experiences for actions. For example, a client might want to show a native video player, or a CLI client might want to provide a playback bar for audio.
• For all of the issues it causes, it's not actually providing a lot of benefit over other solutions. I assume the main use of these embeds would be media, and prompting for response to some kind of event. But clients can already provide embeds for Youtube videos and other content by looking for links and embedding them via https://en.wikipedia.org/wiki/OEmbed or similar. And responses to events are better handled using the buttons described below. If all widgets need to be confirmed before loading anyway, is it really that much better than a link?

In general, I think this is a case of excessive generality. It's nice to say "this can theoretically do everything!" but it's worth remembering the cost that puts on everyone else in an ecosystem. I think that it would be better to look at specific problems to solve and find solutions for those.

[the0d0re9]

While these aren't great for public rooms I'd agree, I think for enterprises and businesses running Matrix these are a killer feature. There could be some kind of access limit per room, you can say disable these "embedded widgets" in this room, may mitigate this issue.

For some examples of how these bots are used in a business, see slacks article: https://slackhq.com/slack-on-slack-unlocking-productivity-with-custom-slack-bots

[NotAFile]

@the0d0re9 I think you're misunderstanding. Slack does not allow you to insert arbitrary interactive html/js content. They allow you to add a very limited set of pre-defined widgets to a message. This is also what the rest of this MSC does and I do not object to it.

[lisongmin]

Add ability for rooms and users to control how to present the widget.

for example, room admin may config:

• some people is trusted to send poll and present as widget,
• some people is not trusted enough so whether present as widget is determined by the end user,
• other people is prohibit so always show as text.

A widget present as widget only if room and user bother allowed.

[erkinalp]

Allowed HTML tags can be extended instead.

[turt2live]

we should use extensible events here

[ShadowJonathan]

I think only allowing HTTP URLs here could be a potential privacy hazard, what about allowing MXC URIs as well, as an alternative to included HTML?

[tcpipuk]

Accidentally created #4214 because I didn't know this existed, but have closed as duplicate - great work! I've just got a few questions that feel relevant for 2024 clients.

[tcpipuk]

Would it be feasible to add a power_level event for sending m.widget content or m.embed events, so rooms can restrict who can embed widgets?

[tcpipuk]

Potentially this could also be displayed as a caption so users can explain why someone would want to approve the widget opening in their client? I'd definitely feel more comfortable being prompted before loading external content that may identify my location/machine/etc.

[tcpipuk]

Might be worth mentioning the sandbox attribute for iframes, and CSP enforcement, e.g. a mechanism for either users or servers to define an allowlist of domains to avoid random arbitrary widgets being loaded?