MSC2931: Allow widgets to navigate with matrix.to URIs #2931
Conversation
turt2live
changed the title
turt2live
added
proposal
MSC: matrix-org/matrix-spec-proposals#2931 This experiments with a new way of handling unstable features from MSCs by using `@deprecated` on the entry points into the system.
|
One of the precautions that could be taken against malicious widgets is to only allow the navigation to happen if it is a result of direct user input, like a mouse click, just as modern browsers do with requesting full screen access. In my opinion, it would be unwanted to have a widget that is able to navigate the user away from the room without any user input at all and it may lead to confusion by some users why their chat app is suddenly in another chat. |
|
I'm pretty certain you can't detect a click happening inside an iframe except from inside that iframe. That would be awful for clickjacking. The iframe is sandboxed and we can do nothing with it except the PostMessage API. |
|
I kinda looked into it, but I couldn't find a way either by just using JavaScript and without trusting the nested frame. But for any applications not running within a web environment themselves, it might be a possibility if they are able to examine the call stack which lead towards the method getting invoked. |
| } | ||
| ``` | ||
|
|
||
| As with all capabilities, clients SHOULD prompt the user to approve the widget's use of the navigate |
There was a problem hiding this comment.
We talked about this a bit on #3662, but it would be good to have an intention included with the action. E.g. For userIds, I might want to direct the client to either invite the user to my current room OR start a new chat with the user.
I'd slightly be more in favor of a key intent or similar which describes the intention of the widget, but we could also append something to the uri.
There was a problem hiding this comment.
Actions are described by the URL format already in the spec - this MSC doesn't change that.
There was a problem hiding this comment.
Where? (I had a look, couldn't spot them)
There was a problem hiding this comment.
https://spec.matrix.org/unstable/appendices/#uris - they are formally specified on matrix: uris, but do technically exist for matrix.to as well. This MSC is intended to be compatible with both.
|
|
||
| ## Proposal | ||
|
|
||
| A new capability, `m.navigate`, is introduced to gate a `navigate` request/response over the widget API. |
There was a problem hiding this comment.
Navigation feels a bit too tightly defined here, there are more use cases than navigation for sharing a matrix URI with the client. This could be made more generic (and therefore more useful) to simply have this API be a URI sharing mechanism ("action":"share") and then include the intent of navigate.
There was a problem hiding this comment.
This MSC is intended to instruct the client to do something with the uri, not to just be a permalink handler. "Handle" and "route" felt far too generic, so navigate was chosen similar to how the browser navigates to a URL which might result in a desktop application being opened instead.
|
|
||
| A new capability, `m.navigate`, is introduced to gate a `navigate` request/response over the widget API. | ||
| The `navigate` action takes one parameter, `uri`, in its `data` - this is the matrix.to (or in future | ||
| Matrix URI scheme) URI the client should honour. The request is acknowledged with an empty response body. |
There was a problem hiding this comment.
Matrix URIs are already in the spec and the navigation in question is specifically for Matrix clients - I don't see a reason why Matrix URIs should not be the recommended form now, not in the future (and yes that means that Element Web should finally catch up and parse them).
There was a problem hiding this comment.
This MSC was last updated over a year ago.
Rendered
Implementation: matrix-org/matrix-widget-api#27