Skip to content
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

Media-links now force download instead of just showing content inline in browser #3139

Closed
dennisse opened this issue Jul 6, 2023 · 7 comments

Comments

@dennisse
Copy link

dennisse commented Jul 6, 2023

Background information

  • Dendrite version or git SHA: 0.13.0 and above
  • SQLite3 or Postgres?: N/A
  • Running in Docker?: N/A
  • go version: N/A
  • Client used (if applicable): Any text-only client, and any non-matrix-client

Description

  • What is the problem: Media-links now force download instead of just showing content inline in browser
  • Who is affected:
    • Anyone using a text-only client
    • Anyone receiving a link to a matrix-attachement outside of a matrix-client (people share links to content uploaded to matrix outside of matrix).
    • This would also affect anyone on the other side of a bridge where attachements are sent as plain links, i.e. the matrix-IRC-bridges.
  • How is this bug manifesting: When clicking a link to an attachement, a download is forced, instead of just showing the media inline in the browser. I used to be able to just click a link and view the attachement directly in my browser.
  • When did this first appear: In Fix unsafe hotserving behaviour for multimedia uploads. #3113, and released in 0.13.0

Steps to reproduce

The example above is from a server running matrix-synapse, not dendrite, but the same behaviour was introduced for dendrite in #3113.

This issue basically a duplicate of matrix-org/synapse#15885, but for dendrite. I don't actually run dendrite, but this new behaviour is really irritating to deal with as someone on the other side of a matrix-bridge where people share media.

Possible solutions

@joshqou mentions only returning disposition type inline for media in the original PR for synapse (matrix-org/synapse#15680), and returning attachement for other files. That would be a super solution, but this was unfortunately lost before the PR was merged.

Another less-than-stellar solution would be to provide a way to turn off returning attachement for all files.

In the mean time, I mention a possible workaround in matrix-org/synapse#15885 which should work for anyone hosting their own dendrite-server (behind a reverse proxy) as well.

@joshqou
Copy link
Contributor

joshqou commented Jul 6, 2023

As is mentioned in the original PR, supporting multiple disposition types would require a rewrite of basically all the media api tests. It would be a non-trivial amount of work and could potentially reintroduce the behaviour that was fixed if done improperly.

I’d suggest modifying your client to support opening native applications for uploads instead, rather than depending on a browser. You can pass most multimedia files directly to mpv or iina (Mac)

@dennisse
Copy link
Author

dennisse commented Jul 7, 2023

It feels extremely user-unfriendly to ask people to modify the behaviour of their systems for something as simple and ubiquitous as opening a link to view an image or a video.

Having to download an image to view it is really stupid. That is not how this is supposed to work. You would never browse a site that made you do that, or continue to open the gifs and images you receive.

@joshqou
Copy link
Contributor

joshqou commented Jul 7, 2023

If you aren’t familiar with the inner workings of your client then I’d suggest opening an issue about it in their tracker instead. The Matrix spec provides no guidelines as to how media should be returned so both the previous and current behaviour of synapse and dendrite are in-spec. It shouldn’t be up to homeservers to fix improper assumptions by clients

@dennisse
Copy link
Author

dennisse commented Jul 7, 2023

I'm not sure you're following the problem here? The problem isn't with any specific matrix-client. The problem is that it is no longer possible to share a link to a matrix-attachement outside a fancy matrix-client (I say fancy because there are text-only matrix-clients who also present a link to attachements, instead of showing it inline in the chat).

The "client" in this issue is any browser a user might open a link in.

People share links to matrix-attachements outside matrix. Like the link in Steps to reproduce above here. Those links get sent all over the place. I.e. when uploading something to matrix on a channel that is bridged to some other service. The user of the other service, i.e. IRC, have to click the link to view the media.

@FlyveHest
Copy link

People share links to matrix-attachements outside matrix. Like the link in Steps to reproduce above here. Those links get sent all over the place. I.e. when uploading something to matrix on a channel that is bridged to some other service. The user of the other service, i.e. IRC, have to click the link to view the media.

This is exactly what has happened to me, I am running the official IRC appservice, and after updating to 1.87 i've had multiple users contact me about this very annoying behaviour change.

Clicking a https link to a picture, and having to download it to watch it is very cumbersome, and there is no way for me to change that behaviour as IRC clients are not Matrix clients and does not do anything other than present the link to the resource in its raw state.

The change may have come from a security perspective, but it would seem like no one considered the multitude of clients Matrix can possible run on (one of the very core features, if i'm not mistaken), and not just Matrix specific ones.

@jjj333-p
Copy link
Contributor

I thought this has been fixed, perhaps issue could be closed?

@S7evinK
Copy link
Contributor

S7evinK commented Feb 28, 2024

Indeed, given we are now doing the same as Synapse - #3274

@S7evinK S7evinK closed this as completed Feb 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants