MSC2385: Disable URL Previews, alternative method #2385
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
| @@ -0,0 +1,62 @@ | ||||||
| # MSC 2385: Disable URL Previews | ||||||
| This MSC is an alternative suggestion to [MSC2376](https://github.com/matrix-org/matrix-doc/pull/2376). | ||||||
|
|
||||||
| Currently URLs posted in chat give a URL preview. Sometimes, for example with bots, this can be | ||||||
| unwanted. For instance if a bot is posting a message with a lot of links, or the content of the link | ||||||
| is already obvious from the message itself. | ||||||
|
|
||||||
| ## Proposal | ||||||
| This proposal adds a new, optional key to `m.room.message` messages, named `url_previews`. It is an | ||||||
| array of strings containing the URLs a preview should be given to. If this key is absent, it is expected | ||||||
| that the client gives URL previews for all URLs present in the message body. If a URL is present in this key that is *not* | ||||||
| present in the body clients SHOULD NOT render a preview for that URL. | ||||||
|
There was a problem hiding this comment. in the body or formatted body? There was a problem hiding this comment. (answering this may lead to further questions and concerns) There was a problem hiding this comment. since all links in the formatted_body should be present in the body and vice-versa (as the body is a plain-text fallback) this should only matter for those messages that actively disobey that. That being said, it seem to make most sense to use the links in whichever the client uses to render: if it renders formatted stuffs the formatted_body, if it renders plaintext the body There was a problem hiding this comment. right, so the concern here would be that you can make a very convincing phishing attack: if it uses URLs only from Currently at least, clients will (or should) be showing a URL preview for the There was a problem hiding this comment. If a client uses There was a problem hiding this comment. Sure, it's the responsibility of the user to check links before they click but in practice we shouldn't be designing into the protocol a requirement for people to do that. The attack is quite literally: {
"body": "https://example.org",
"format": "org.matrix.custom.html",
"formatted_body": "<a href="https://phishing.example.org">https://example.org</a>",
"url_previews": ["https://example.org"]
}Which clients that don't read the spec to the letter would render as:
Instead, we could be better at protecting users from badly written clients and from having to be more responsible than us. There was a problem hiding this comment. The fix for that is equally as trivial: As the client uses formatted_body to figure out URL previews, it is expected to figure out that the stuff in the href of the There was a problem hiding this comment. Maybe it would be more clear if it was specified like the following:
So it is clear that the client must not read The consequence is that putting arbitrary URLs into |
||||||
|
|
||||||
| ### Examples | ||||||
| No key added, preview to all URLs: | ||||||
| ```json | ||||||
| { | ||||||
| "msgtype": "m.text", | ||||||
| "body": "Wow, check out this song! https://www.youtube.com/watch?v=oHg5SJYRHA0" | ||||||
| } | ||||||
| ``` | ||||||
|
|
||||||
| Empty array for `url_previews`, thus no URL preview at all: | ||||||
| ```json | ||||||
| { | ||||||
| "msgtype": "m.text", | ||||||
| "format": "or.matrix.custom.html", | ||||||
| "body": "Hey, look at what I did! [MSC2385: Disable URL Previews](https://github.com/matrix-org/matrix-doc/pull/2385)", | ||||||
| "formatted_body": "Hey, look at what I did! <a src=\"https://github.com/matrix-org/matrix-doc/pull/2385\">MSC2385: Disable URL Previews</a>", | ||||||
| "url_previews": [] | ||||||
| } | ||||||
| ``` | ||||||
|
|
||||||
| Array of URLs to preview, only those in the array are previewed: | ||||||
| ```json | ||||||
| { | ||||||
| "msgtype": "m.text", | ||||||
| "body": "https://example.com https://matrix.org", | ||||||
| "url_previews": ["https://example.com"] | ||||||
uhoreg marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||
| } | ||||||
| ``` | ||||||
|
|
||||||
| ## Potential issues | ||||||
| URLs that should have a preview need to be sent twice - once in the body, once in `url_previews`. As | ||||||
| this feature is meant for bots, normal human clients would probably omit `url_previews` alltogether, | ||||||
|
There was a problem hiding this comment.
Suggested change
... because English is weird. |
||||||
| resulting in all URLs sent from them having a preview. | ||||||
|
There was a problem hiding this comment. I see no reason a client can't display a list of links that it detects and allow the user to disable previews for some or all of them. There was a problem hiding this comment. I must have missed this paragraph earlier. I agree that I don't see any reason why this should be intended mainly for bots and not for humans. There have been several occasions where I've typed a link and not wanted to have a preview because it causes extra noise (not just for rickrolling). There was a problem hiding this comment. I, as a human, would have use for this every once in a while. Implementation examples of UI for this have been mentioned earlier (facebook, ...). I don't know if it should be added to the MSC, but since the point is to not send certain URLs to the HS, the sending UX should be constructed in such a way that, if at all, it is the client which generates the preview so that you can then decide to include it or not. The reasoning being that the sending user has (99% likely) already visited that URL and, if privacy is a concern, taken appropriate measures. |
||||||
|
|
||||||
| URLs in `url_previews` and in the body need to match exactly, which could be confusing with trailing | ||||||
| slashes (`/`). | ||||||
|
|
||||||
| ## Alternatives | ||||||
| There could be an attribute added to the `<a>` tag which disables URL previews. See | ||||||
| [MSC2376](https://github.com/matrix-org/matrix-doc/pull/2376). | ||||||
|
|
||||||
| Instead of a whitelist there could also be a blacklist of URLs. However, as the likely scenario is a | ||||||
| bot wanting to surpress all the previews for its URLs sent it seems like a whitelist is more appropriate | ||||||
| here. | ||||||
|
There was a problem hiding this comment. A whitelist also nicely prevents clients from parsing things that were not intended to be URLs and trying to preview them. Should mostly be relevant for |
||||||
|
|
||||||
| ## Security considerations | ||||||
| You could get tricked more easily into being Rickroll'd. This can be alleviated by encouraging | ||||||
| clients to request previews explicitly (either by hovering or by clicking a special button next to | ||||||
| the link). | ||||||
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 can't expect that clients give URL previews as this could be a security problem. We should say that clients MAY provide previews for all URLs in the body.
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.
Good point. Also FYI url previews are proxied through your homeserver, so you don't actually have any security problem when generating 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.
However, there is a problem: WWW URLs may return different things depending on other log-ins and the like, so the sender and the homeserver of the sender may not see the same content.
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.
https://matrix.org/docs/spec/client_server/r0.6.1#get-matrix-media-r0-preview-url discussion on that is beyond this MSC. The top comment suggests to use "may" instead of "it is expected", which soru will incorporate into this MSC
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.
But it reveals the URL to the home server. You can imagine a case where a malicious user sends an illegal url so that a user may get in trouble if the honeservers logs are checked. I agree it isn't the worst privacy flaw but I think it is worth letting clients make the choice and provide users with options rather than writing this section like it is expected.
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.
may means the clients still have a choice.
this MSC does not add any new locations where clients should display url previews, it is about limiting it in some messages. "Disable URL Previews".
Also there is a reason element disables URL previews in e2ee rooms by default.
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 like that. I think it makes sense to focus on disallowing certain previews in this MSC and not sound like we are requiring any previews where they weren't required previously.