Element-web: Option to generate URL previews at the receiving client, not the server

Created on 15 Jan 2017 · 12Comments · Source: vector-im/element-web

If the URL previews are enabled the riot-web app makes a request to
https://matrix.org/_matrix/media/r0/preview_url (assuming that matrix.org is your home-server). This would not be necessary if the app runs inside of electron. The sesstion.webRequest API could be used instead.
Benefits: For E2E rooms the user could have the URL preview without 'leaking' content of the chat to the home-server. The server doesn't need to proxy that much additional requests (can handle more users - theoretically)

See: https://github.com/electron/electron/pull/3640

Related to #2084

feature p2 urlpreviews

Source

carlos22

👍2

Most helpful comment

the reason that the server generates previews atm is to stop remote sites tracking IPs of clients. This is particularly relevant for E2E users, I suspect. We don't want to be in a situation where you have 1000 people sitting in an E2E room, and someone turns up and posts a url of https://evil.com or whatever, grabs a list of the IP addresses of all the connected users, and then attacks them. There is currently no way for users to discover other users' IPs (and admins can only see the IPs connecting to their local HS).

ara4n on 17 Jan 2017

👍3

All 12 comments

Could we use the Platform abstraction to properly handle this?

carlos22 on 17 Jan 2017

ara4n on 17 Jan 2017

👍3

Ok that makes sense. For E2E direct-chats things are different, but matrix/riot does not distinguish between them. So it is all about how much you trust your homeserver...

carlos22 on 18 Jan 2017

This very much feels like it should be a configurable option in the end. "Do you want to preview URLs via your server or via your client? Do you want to preview URLs in E2E chats?"

ara4n on 18 Jan 2017

@ara4n agreed. As much as I want to keep settings simple, but in this case i think people should decide.

carlos22 on 20 Jan 2017

From a UX perspective, I also agree there should be a default but have it configurable.

tessgadwa on 23 Jan 2017

Alternatively, we could make it the sending client's problem (as per #3255). It's an interesting question as to whether the preview should be telling the user what they will see if they click on the page (whilst leaking their IP, and hammering the server)... or telling the user what the sender intended the preview to be (as per #3255).

Unsure how to proceed here, really.

ara4n on 19 Feb 2017

Thats not a bad idea to offload the problem to the sender. Because most likely the sender opened the URL anyway? Some Apps in Andorid 6 do something similar, they take a screenshot and add it to the "share" processs.

carlos22 on 19 Feb 2017

the only reason not to do it is trust, with spammers going and misrepresenting the target's contents in the thumbnail, as @CoffeeMatrix implies. this could be solved at a social layer (eg with reputation rules), but it's a bit of a shame to make for ourselves when the receiving client could just gen the thumbnail themselves (at the expense of revealing their IP and hammering the URL). luckily the code is pretty much the same whether it's receiver or sender genning the preview though.

ara4n on 19 Feb 2017

👍1

But whats the point? The spammers also cloud send URLs/Images with offensive content?
I think the protection of your IP and all the parameters that it sends to a server are more precocious than protection of images that are not correct. And if we are still talking about E2E Chats, than a spammer should not be verified and therefore no thumbnails should be showed?!

carlos22 on 19 Feb 2017

Generating the preview client-side also won't be possible in the browser because of XHR cross-origin restrictions, as far as I know.