From 7eeb3ea3be04ec84e6ff871531c2e369d1ecc9de Mon Sep 17 00:00:00 2001 From: Tulir Asokan Date: Wed, 31 Jan 2024 22:29:05 +0100 Subject: [PATCH 01/13] Proposal for bundling URL previews in events Signed-off-by: Tulir Asokan --- proposals/4095-bundled-url-previews.md | 97 ++++++++++++++++++++++++++ 1 file changed, 97 insertions(+) create mode 100644 proposals/4095-bundled-url-previews.md diff --git a/proposals/4095-bundled-url-previews.md b/proposals/4095-bundled-url-previews.md new file mode 100644 index 00000000000..12b94390ccb --- /dev/null +++ b/proposals/4095-bundled-url-previews.md @@ -0,0 +1,97 @@ +# Bundled URL previews +Currently, URL previews in Matrix are generated on the server when requested by +a client using the [`/_matrix/media/v3/preview_url`](https://spec.matrix.org/v1.9/client-server-api/#get_matrixmediav3preview_url) +endpoint. This is a relatively good approach, but a major downside is that the +user's homeserver gets all links the user's client wants to show a preview for, +which means using it in encrypted rooms will effectively leak parts of messages. + +## Proposal +The proposed solution is allowing clients to bundle URL preview metadata inside +events. + +A new field called `m.url_previews` is added. The field is an array of objects, +where each object contains OpenGraph data representing a single URL to preview, +similar to what the `/preview_url` endpoint currently returns: + +* `matrix:matched_url` - The URL that is present in `body` and triggered this preview + to be generated. This is optional and should be omitted if the link isn't + present in the body. +* `matrix:image:encryption` - An [EncryptedFile](https://spec.matrix.org/v1.9/client-server-api/#extensions-to-mroommessage-msgtypes) + object for encrypted thumbnail images. Similar to encrypted image messages, + the URL is inside this object, and not in `og:image`. +* `matrix:image:size` - The byte size of the image, like in `/preview_url`. +* `og:image` - An `mxc://` URI for unencrypted images, like in `/preview_url`. +* `og:url` - Standard OpenGraph tag for the canonical URL of the previewed page. +* Any other standard OpenGraph tags. + +At least one of `matrix:matched_url` and `og:url` MUST be present. All other +fields are optional. + +### Client behavior +#### Sending preview data +When sending previews to encrypted rooms, clients should encrypt preview images +and put them in the `matrix:image:encryption` field. Other `og:image:*` and the +`matrix:image:size` field can still be used for image metadata, but the +`og:image` field should be omitted for encrypted thumbnails. + +If clients use the `/preview_url` endpoint as a helper for generating preview +data, they should reupload the thumbnail image (if there is one) to create a +persistent `mxc://` URI, as well as encrypt it if applicable. + +#### Receiving messages with `m.url_previews` +If an object in the list contains only `matrix:matched_url` and no other fields, +receiving clients should fall back to the old behavior of requesting a preview +using `/preview_url`. Clients may also choose to ignore bundled data and ask +the homeserver for a preview even if bundled data is present. + +Clients should not search the `body` field for URLs if the `m.url_previews` +field is present, even if they fall back to the old behavior of requesting +preview data from the homeserver. Conversely, if the field is not present, +clients should fall back to the searching behavior. + +The two above points effectively make this an alternative for +[MSC2385](https://github.com/matrix-org/matrix-spec-proposals/pull/2385). + +## Potential issues +### Fake preview data +The message sender can fake previews quite trivially. This is considered an +acceptable compromise to achieve non-leaking URL previews in encrypted rooms. + +Clients may choose to ignore embedded preview data in unencrypted rooms and +always use the `/preview_url` endpoint. + +### More image uploads +Currently previews are generated by the server, which lets the server apply +caching and delete thumbnail images quickly. If the data was embedded in events +instead, the server would not be able to clean up images the same way. + +### Web clients +Web clients likely can't generate previews themselves due to CORS and other +such protections. + +Clients could use the existing URL preview endpoint to generate a preview and +bundle that data in events, which has the benefit of only leaking the link to +one homeserver (the sender's) instead of all servers. When doing this, clients +would have to download the preview image and reupload it to get a persistent +`mxc://` URI, and possibly encrypt it before uploading. + +Alternatively, clients could simply not include preview data at all and have +receiving clients fall back to the old behavior (meaning no previews in +encrypted rooms unless the receiver opts in). + +### Security considerations +Fake preview data as covered in potential issues. + +## Alternatives +### Different generation methods +Previews could be generated by the receiving client, which both doesn't leak +links to the user's homeserver, and prevents fake previews. However, this would +leak the user's IP address to all links they receive, so it is not an +acceptable solution. + +## Unstable prefix +Until this MSC is accepted, implementations should apply the following renames: + +* `com.beeper.linkpreviews` instead of `m.url_previews` +* `beeper:image:encryption` instead of `matrix:image:encryption` +* `matched_url` instead of `matrix:matched_url` From 96a4800aeab681dd18b2715cb23f3692e0345ec8 Mon Sep 17 00:00:00 2001 From: Tulir Asokan Date: Thu, 1 Feb 2024 08:37:11 +0100 Subject: [PATCH 02/13] Add examples and mention extensible events Signed-off-by: Tulir Asokan --- proposals/4095-bundled-url-previews.md | 124 +++++++++++++++++++++++++ 1 file changed, 124 insertions(+) diff --git a/proposals/4095-bundled-url-previews.md b/proposals/4095-bundled-url-previews.md index 12b94390ccb..b7623feb381 100644 --- a/proposals/4095-bundled-url-previews.md +++ b/proposals/4095-bundled-url-previews.md @@ -27,6 +27,11 @@ similar to what the `/preview_url` endpoint currently returns: At least one of `matrix:matched_url` and `og:url` MUST be present. All other fields are optional. +### Extensible events +The definition of `matrix:matched_url` changes from "present in `body`" to +"present in `m.text`", but otherwise the proposal is directly compatible with +extensible events. + ### Client behavior #### Sending preview data When sending previews to encrypted rooms, clients should encrypt preview images @@ -52,6 +57,125 @@ clients should fall back to the searching behavior. The two above points effectively make this an alternative for [MSC2385](https://github.com/matrix-org/matrix-spec-proposals/pull/2385). +### Examples +
+Normal preview + +```json +{ + "type": "m.room.message", + "content": { + "msgtype": "m.text", + "body": "https://matrix.org", + "m.url_previews": [ + { + "matrix:matched_url": "https://matrix.org", + "matrix:image:size": 16588, + "og:description": "Matrix, the open protocol for secure decentralised communications", + "og:image": "mxc://maunium.net/zeHhTqqUtUSUTUDxQisPdwZO", + "og:image:height": 400, + "og:image:type": "image/jpeg", + "og:image:width": 800, + "og:title": "Matrix.org", + "og:url": "https://matrix.org/" + } + ], + "m.mentions": {} + } +} +``` + + +
+Preview with encrypted thumbnail image + +```json +{ + "type": "m.room.message", + "content": { + "msgtype": "m.text", + "body": "https://matrix.org", + "m.url_previews": [ + { + "matrix:matched_url": "https://matrix.org", + "og:url": "https://matrix.org/", + "og:title": "Matrix.org", + "og:description": "Matrix, the open protocol for secure decentralised communications", + "matrix:image:size": 16588, + "og:image:width": 800, + "og:image:height": 400, + "og:image:type": "image/jpeg", + "matrix:image:encryption": { + "key": { + "k": "GRAgOUnbbkcd-UWoX5kTiIXJII81qwpSCnxLd5X6pxU", + "alg": "A256CTR", + "ext": true, + "kty": "oct", + "key_ops": [ + "encrypt", + "decrypt" + ] + }, + "iv": "kZeoJfx4ehoAAAAAAAAAAA", + "hashes": { + "sha256": "WDOJYFegjAHNlaJmOhEPpE/3reYeD1pRvPVcta4Tgbg" + }, + "v": "v2", + "url": "mxc://beeper.com/53207ac52ce3e2c722bb638987064bfdc0cc257b" + } + } + ], + "m.mentions": {} + } +} +``` + +
+
+Message indicating it should not have any previews + +```json +{ + "type": "m.room.message", + "content": { + "msgtype": "m.text", + "body": "https://matrix.org", + "m.url_previews": [], + "m.mentions": {} + } +} +``` + +
+Preview in extensible event + +```json +{ + "type": "m.message", + "content": { + "m.text": { + {"body": "matrix.org/support"} + ], + "m.url_previews": [ + { + "matched_url": "matrix.org/support", + "matrix:image:size": 16588, + "og:description": "Matrix, the open protocol for secure decentralised communications", + "og:image": "mxc://maunium.net/zeHhTqqUtUSUTUDxQisPdwZO", + "og:image:height": 400, + "og:image:type": "image/jpeg", + "og:image:width": 800, + "og:title": "Support Matrix", + "og:url": "https://matrix.org/support/" + } + ], + "m.mentions": {} + } +} +``` + +
+ ## Potential issues ### Fake preview data The message sender can fake previews quite trivially. This is considered an From 25e633afe2e40d5efaee70a85b590e9ca717e477 Mon Sep 17 00:00:00 2001 From: Tulir Asokan Date: Thu, 1 Feb 2024 08:45:11 +0100 Subject: [PATCH 03/13] Add note about why `matched_url` is unprefixed in unstable prefixes Signed-off-by: Tulir Asokan --- proposals/4095-bundled-url-previews.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/proposals/4095-bundled-url-previews.md b/proposals/4095-bundled-url-previews.md index b7623feb381..7769b5133a9 100644 --- a/proposals/4095-bundled-url-previews.md +++ b/proposals/4095-bundled-url-previews.md @@ -219,3 +219,5 @@ Until this MSC is accepted, implementations should apply the following renames: * `com.beeper.linkpreviews` instead of `m.url_previews` * `beeper:image:encryption` instead of `matrix:image:encryption` * `matched_url` instead of `matrix:matched_url` + * note: this was implemented without a prefix before the MSC was made, which + is why the "unstable prefix" is no prefix in this case. From 91c8cf1e551bb6b7ba93061b97a618593650dde7 Mon Sep 17 00:00:00 2001 From: Tulir Asokan Date: Thu, 1 Feb 2024 08:52:41 +0100 Subject: [PATCH 04/13] Fix some HTML tags Signed-off-by: Tulir Asokan --- proposals/4095-bundled-url-previews.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/proposals/4095-bundled-url-previews.md b/proposals/4095-bundled-url-previews.md index 7769b5133a9..d5eaabf4639 100644 --- a/proposals/4095-bundled-url-previews.md +++ b/proposals/4095-bundled-url-previews.md @@ -85,7 +85,7 @@ The two above points effectively make this an alternative for } ``` - +
Preview with encrypted thumbnail image @@ -147,6 +147,7 @@ The two above points effectively make this an alternative for ```
+
Preview in extensible event ```json From 935e36aa8138d3d4944d7bca4f0e34fe20971a26 Mon Sep 17 00:00:00 2001 From: Tulir Asokan Date: Thu, 1 Feb 2024 08:53:29 +0100 Subject: [PATCH 05/13] Fix security considerations heading size Signed-off-by: Tulir Asokan --- proposals/4095-bundled-url-previews.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/4095-bundled-url-previews.md b/proposals/4095-bundled-url-previews.md index d5eaabf4639..7a9b28b5c1f 100644 --- a/proposals/4095-bundled-url-previews.md +++ b/proposals/4095-bundled-url-previews.md @@ -204,7 +204,7 @@ Alternatively, clients could simply not include preview data at all and have receiving clients fall back to the old behavior (meaning no previews in encrypted rooms unless the receiver opts in). -### Security considerations +## Security considerations Fake preview data as covered in potential issues. ## Alternatives From a51df1ae942dbdbd7e23548c4b199600117e3e7f Mon Sep 17 00:00:00 2001 From: Tulir Asokan Date: Thu, 1 Feb 2024 08:55:12 +0100 Subject: [PATCH 06/13] Add another example and fix some typos Signed-off-by: Tulir Asokan --- proposals/4095-bundled-url-previews.md | 24 ++++++++++++++++++++++-- 1 file changed, 22 insertions(+), 2 deletions(-) diff --git a/proposals/4095-bundled-url-previews.md b/proposals/4095-bundled-url-previews.md index 7a9b28b5c1f..795b10dddc0 100644 --- a/proposals/4095-bundled-url-previews.md +++ b/proposals/4095-bundled-url-previews.md @@ -146,6 +146,26 @@ The two above points effectively make this an alternative for } ``` +
+
+Message indicating a preview should be fetched from the homeserver + +```json +{ + "type": "m.room.message", + "content": { + "msgtype": "m.text", + "body": "https://matrix.org", + "m.url_previews": [ + { + "matrix:matched_url": "https://matrix.org" + } + ], + "m.mentions": {} + } +} +``` +
Preview in extensible event @@ -154,12 +174,12 @@ The two above points effectively make this an alternative for { "type": "m.message", "content": { - "m.text": { + "m.text": [ {"body": "matrix.org/support"} ], "m.url_previews": [ { - "matched_url": "matrix.org/support", + "matrix:matched_url": "matrix.org/support", "matrix:image:size": 16588, "og:description": "Matrix, the open protocol for secure decentralised communications", "og:image": "mxc://maunium.net/zeHhTqqUtUSUTUDxQisPdwZO", From 9ac1336c7723a684f9a67a8f78e09ced398cd327 Mon Sep 17 00:00:00 2001 From: Tulir Asokan Date: Thu, 1 Feb 2024 20:05:46 +0100 Subject: [PATCH 07/13] Add section about original URL preview design doc Signed-off-by: Tulir Asokan --- proposals/4095-bundled-url-previews.md | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/proposals/4095-bundled-url-previews.md b/proposals/4095-bundled-url-previews.md index 795b10dddc0..1b43cc746ec 100644 --- a/proposals/4095-bundled-url-previews.md +++ b/proposals/4095-bundled-url-previews.md @@ -234,6 +234,22 @@ links to the user's homeserver, and prevents fake previews. However, this would leak the user's IP address to all links they receive, so it is not an acceptable solution. +The original design notes for URL previews from 2016 also has a list of options +that were considered at the time: . +Option 2 is what was implemented then, and this proposal adds option 4. +The combination of options 2 and 4 is also mentioned as the probably best +solution in that document. + +The document also mentions the possibility of an AS or HS scanning messages and +injecting preview data, but that naturally won't function with encryption at all, +and is therefore not an alternative. + +The fifth option mentioned in the document, a centralized previewing service +which is configured per-room, could technically work, but would likely be worse +than HS-generated previews in practice: users wouldn't know to configure a +different previewing service, so clients would probably have to automatically +pick one. + ## Unstable prefix Until this MSC is accepted, implementations should apply the following renames: From 6efebbc82e01f1d26b733c9d64a43fa9b8e157cd Mon Sep 17 00:00:00 2001 From: Tulir Asokan Date: Thu, 1 Feb 2024 20:07:47 +0100 Subject: [PATCH 08/13] Mention possibility to extend /preview_url for persistent mxcs Signed-off-by: Tulir Asokan --- proposals/4095-bundled-url-previews.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/proposals/4095-bundled-url-previews.md b/proposals/4095-bundled-url-previews.md index 1b43cc746ec..a5ac46f7fe8 100644 --- a/proposals/4095-bundled-url-previews.md +++ b/proposals/4095-bundled-url-previews.md @@ -41,7 +41,8 @@ and put them in the `matrix:image:encryption` field. Other `og:image:*` and the If clients use the `/preview_url` endpoint as a helper for generating preview data, they should reupload the thumbnail image (if there is one) to create a -persistent `mxc://` URI, as well as encrypt it if applicable. +persistent `mxc://` URI, as well as encrypt it if applicable. A future MSC +could also extend `/preview_url` with a parameter to request a persistent URI. #### Receiving messages with `m.url_previews` If an object in the list contains only `matrix:matched_url` and no other fields, From 07b8ed774f08862cd451a7228b768c074ec7c7f6 Mon Sep 17 00:00:00 2001 From: Tulir Asokan Date: Sun, 11 Feb 2024 13:42:54 +0200 Subject: [PATCH 09/13] Mention msgtypes Signed-off-by: Tulir Asokan --- proposals/4095-bundled-url-previews.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/proposals/4095-bundled-url-previews.md b/proposals/4095-bundled-url-previews.md index a5ac46f7fe8..e209fe41df5 100644 --- a/proposals/4095-bundled-url-previews.md +++ b/proposals/4095-bundled-url-previews.md @@ -27,6 +27,10 @@ similar to what the `/preview_url` endpoint currently returns: At least one of `matrix:matched_url` and `og:url` MUST be present. All other fields are optional. +URL previews are primarily meant for text-based message types (`m.text`, +`m.notice`, `m.emote`), but they may be used with any message type, as even +media messages may have captions in the future. + ### Extensible events The definition of `matrix:matched_url` changes from "present in `body`" to "present in `m.text`", but otherwise the proposal is directly compatible with From 6e3d0f1a30f78ac5f9d0601f375591444b839d87 Mon Sep 17 00:00:00 2001 From: Tulir Asokan Date: Sun, 11 Feb 2024 13:43:22 +0200 Subject: [PATCH 10/13] Clarify behavior of ignoring embedded preview data Signed-off-by: Tulir Asokan --- proposals/4095-bundled-url-previews.md | 31 ++++++++++++++++++-------- 1 file changed, 22 insertions(+), 9 deletions(-) diff --git a/proposals/4095-bundled-url-previews.md b/proposals/4095-bundled-url-previews.md index e209fe41df5..78b677fd694 100644 --- a/proposals/4095-bundled-url-previews.md +++ b/proposals/4095-bundled-url-previews.md @@ -51,15 +51,26 @@ could also extend `/preview_url` with a parameter to request a persistent URI. #### Receiving messages with `m.url_previews` If an object in the list contains only `matrix:matched_url` and no other fields, receiving clients should fall back to the old behavior of requesting a preview -using `/preview_url`. Clients may also choose to ignore bundled data and ask -the homeserver for a preview even if bundled data is present. +using `/preview_url`. -Clients should not search the `body` field for URLs if the `m.url_previews` -field is present, even if they fall back to the old behavior of requesting -preview data from the homeserver. Conversely, if the field is not present, -clients should fall back to the searching behavior. +Clients may choose to ignore bundled data and ask the homeserver for a preview +even if bundled data is present, as a security measure against faking preview +data. -The two above points effectively make this an alternative for +Clients may also choose to verify that the matched_url is present in the +`body` field before displaying a full preview. However, in order to avoid losing +data, clients SHOULD still display ignored entries somehow, e.g. just rendering +the link (either `og:url` or `matrix:matched_url`) instead of a full preview. + +Note: ignoring bundled data does not mean ignoring the `m.url_preview` field: +even when ignoring bundled data and/or verifying that matched_url is present in +`body`, clients should only display previews for URLs that are present in the +list, and should never display previews for URLs that aren't present in the list. + +If the `m.url_previews` field is not present at all, clients should fall back +to the old behavior of searching `body`. + +The above points effectively make this an alternative for [MSC2385](https://github.com/matrix-org/matrix-spec-proposals/pull/2385). ### Examples @@ -207,8 +218,10 @@ The two above points effectively make this an alternative for The message sender can fake previews quite trivially. This is considered an acceptable compromise to achieve non-leaking URL previews in encrypted rooms. -Clients may choose to ignore embedded preview data in unencrypted rooms and -always use the `/preview_url` endpoint. +As mentioned in the client behavior section, clients may choose to ignore +embedded preview data in unencrypted rooms and always use the `/preview_url` +endpoint, effectively only using `m.url_previews` as a whitelist of URLs to +preview. ### More image uploads Currently previews are generated by the server, which lets the server apply From 2a949571377afc9fd4e232ddf1d64aa598eac5d8 Mon Sep 17 00:00:00 2001 From: Tulir Asokan Date: Mon, 19 Aug 2024 11:05:26 +0300 Subject: [PATCH 11/13] Add more security considerations Signed-off-by: Tulir Asokan --- proposals/4095-bundled-url-previews.md | 27 ++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/proposals/4095-bundled-url-previews.md b/proposals/4095-bundled-url-previews.md index 78b677fd694..c7b30f551d8 100644 --- a/proposals/4095-bundled-url-previews.md +++ b/proposals/4095-bundled-url-previews.md @@ -245,6 +245,33 @@ encrypted rooms unless the receiver opts in). ## Security considerations Fake preview data as covered in potential issues. +### Generating previews will leak IPs +The sender's client will leak its IP when it fetches previews for URLs typed by +the user. This is generally an acceptable tradeoff, as long as clients take +care never to generate previews for links the user did not type. + +For example, if a client generates reply fallbacks, it MUST NOT generate +previews for links in the fallback. Clients should also be careful with links +when starting to edit a message, possibly by not generating new previews at +all. + +Clients may also provide extra safeguards, such as only offering a button to +generate previews, rather than generating them immediately after the user types +a URL. However, this is a UX decision and is therefore ultimately up to the +client to decide. + +### Previewing code must be implemented carefully +When generating URL previews, clients are parsing completely untrusted data. +Parsing responses must be done with care to prevent content-based attacks, such +as the billion laughs attack. + +### Local IPs should not be previewed by default +Clients should prevent previewing non-public IP addresses by default. To do +this, clients must check the DNS records of a domain before connecting to the +resolved IP, as public domains may point to private IPs. For web clients, these +limits are generally handled by the browser (see the [Private Network Access +spec](https://wicg.github.io/private-network-access/)). + ## Alternatives ### Different generation methods Previews could be generated by the receiving client, which both doesn't leak From fa0e094296f4b876cc9c03210d170b529b6a6da8 Mon Sep 17 00:00:00 2001 From: Tulir Asokan Date: Mon, 30 Sep 2024 11:58:46 +0300 Subject: [PATCH 12/13] Mention privacy-preserving TCP relays Signed-off-by: Tulir Asokan --- proposals/4095-bundled-url-previews.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/proposals/4095-bundled-url-previews.md b/proposals/4095-bundled-url-previews.md index c7b30f551d8..e9c97b2e882 100644 --- a/proposals/4095-bundled-url-previews.md +++ b/proposals/4095-bundled-url-previews.md @@ -260,6 +260,12 @@ generate previews, rather than generating them immediately after the user types a URL. However, this is a UX decision and is therefore ultimately up to the client to decide. +Clients could also use a privacy-preserving TCP relay to proxy all URL preview +requests [like Signal does](https://signal.org/blog/i-link-therefore-i-am/). +That way the client wouldn't leak its IP, and the relay wouldn't see previewed +URLs. However, running such a proxy has several potential security issues for +the server administrators, so it is out of scope for this MSC. + ### Previewing code must be implemented carefully When generating URL previews, clients are parsing completely untrusted data. Parsing responses must be done with care to prevent content-based attacks, such From b638a9efbf7e4f1f9532fd42b7bf25504fc94cf4 Mon Sep 17 00:00:00 2001 From: Tulir Asokan Date: Tue, 19 Nov 2024 21:33:33 +0200 Subject: [PATCH 13/13] Address @zecakeh's review comments Signed-off-by: Tulir Asokan --- proposals/4095-bundled-url-previews.md | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/proposals/4095-bundled-url-previews.md b/proposals/4095-bundled-url-previews.md index e9c97b2e882..f4c56c13479 100644 --- a/proposals/4095-bundled-url-previews.md +++ b/proposals/4095-bundled-url-previews.md @@ -31,6 +31,9 @@ URL previews are primarily meant for text-based message types (`m.text`, `m.notice`, `m.emote`), but they may be used with any message type, as even media messages may have captions in the future. +Allowing the omission of `matched_url` is effectively a new feature to send URL +previews without a link in the message text. + ### Extensible events The definition of `matrix:matched_url` changes from "present in `body`" to "present in `m.text`", but otherwise the proposal is directly compatible with @@ -49,9 +52,9 @@ persistent `mxc://` URI, as well as encrypt it if applicable. A future MSC could also extend `/preview_url` with a parameter to request a persistent URI. #### Receiving messages with `m.url_previews` -If an object in the list contains only `matrix:matched_url` and no other fields, -receiving clients should fall back to the old behavior of requesting a preview -using `/preview_url`. +If an object in the list contains only `matrix:matched_url` or `og:url` (but +not both) and no other fields, receiving clients should fall back to the old +behavior of requesting a preview using `/preview_url`. Clients may choose to ignore bundled data and ask the homeserver for a preview even if bundled data is present, as a security measure against faking preview @@ -245,6 +248,11 @@ encrypted rooms unless the receiver opts in). ## Security considerations Fake preview data as covered in potential issues. +### Visibility in old clients (T&S) +Clients that don't support this MSC will not display any of the data in the +preview field, which could be abused by spammers if all moderators in a room +are using old clients. + ### Generating previews will leak IPs The sender's client will leak its IP when it fetches previews for URLs typed by the user. This is generally an acceptable tradeoff, as long as clients take