-
Notifications
You must be signed in to change notification settings - Fork 378
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MSC2192: Inline widgets #2192
base: old_master
Are you sure you want to change the base?
MSC2192: Inline widgets #2192
Conversation
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
@BillCarsonFr please always use threads so things can be replied to. I've moved your comments. |
proposals/2192-inline-widgets.md
Outdated
MSC1849 is used to define the relationship of a button press to an event, similar to how | ||
MSC1485 did the relationship but instead using MSC1849's topology for the linking. | ||
|
||
#### Inline Widgets (use case 1) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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.
proposals/2192-inline-widgets.md
Outdated
|
||
Allowing arbitrary embeds opens up a spam vector for auto-playing videos, scare content, | ||
and similar spam. Clients should do their best to avoid these kinds of attacks, such as | ||
by blocking the widget from loading until the user accepts the widget. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Allowed HTML tags can be extended instead. |
proposals/2192-inline-widgets.md
Outdated
@@ -0,0 +1,240 @@ | |||
# Proposal for inline widgets |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we should use extensible events here
proposals/2192-inline-widgets.md
Outdated
"content": { | ||
"m.text": "https://www.youtube.com/watch?v=a4L94Rsg_nM", | ||
"m.widget": { | ||
"url": "https://www.youtube.com/embed/a4L94Rsg_nM", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
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.