MSC3916: Authentication for media

[richvdh]

A rewrite and update of MSC1902, and a precursor to MSC3911.

Rendered

Implementations:

• Server: https://github.com/turt2live/matrix-media-repo/pull/509
• Another server: https://github.com/element-hq/synapse/pull/17172
• Web client: https://github.com/element-hq/element-web/pull/27326

FCP tickyboxes

[ghost]

This should also obsolete https://github.com/matrix-org/matrix-spec-proposals/pull/2461

Quaternion will also (heuristically) use media auth, if the download gets rejected with auth needed by http it will use it, also the legacy paths.

[Fizzadar]

Moved to: https://github.com/matrix-org/matrix-spec-proposals/pull/3916#discussion_r1003131030

[richvdh]

@Fizzadar could you write that as a comment on the diff, to start a discussion thread?

[xylonx]

As described in #2461, it's a nice idea to distinction public media content and private media content for better back compatibility and flexibility. For API design, I think the S3 API is a good reference. We can use HTTP header or query paramters as auth and set possible expire time for external share link.

[turt2live]

Discussed out of band, I'm taking on updating this MSC under my Element T&S hat (allocated in full to the Foundation).

[turt2live]

My concerns with implementation are satisfied: while the implementations aren't shipped to users, their presence shows that it's possible to build this support into different environments. Most importantly, web browser-based clients are able to use this feature (a specific concern raised within the MSC itself).

I also believe the SCT is aligned on this being a feature we want to have in Matrix. If there's significant impact to user experience, T&S will address that with followup MSCs as needed. Currently, it is considered a feature to "break" future HTTP media URLs, not a bug. Breaking existing links is undesirable, however. This is outlined in the MSC.

@mscbot fcp merge

[mscbot]

Team member @mscbot has proposed to merge this. The next step is review by the rest of the tagged people:

• [x] @clokep
• [x] @dbkr
• [x] @uhoreg
• [x] @turt2live
• [x] @ara4n
• [ ] @anoadragon453
• [x] @richvdh
• [x] @tulir
• [x] @erikjohnston
• [x] @KitsuneRal

Concerns:

• ~~Should we split the federation download endpoint in two?~~

Once at least 75% of reviewers approve (and there are no outstanding concerns), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for information about what commands tagged team members can give me.

[turt2live]

There are implementation-level concerns with the combined endpoint. While we wait for the implementation to form an opinion:

@mscbot concern Should we split the federation download endpoint in two?

[progserega]

Do we can add this change as options enabled by default? In my case we use our server as images storage. And my colleagues simply copy url of image from message and insert this url to our web-services for internal corporate use. This is very nice. I think will be nice add options to synapse for save current behaviour (disabled by default).

[turt2live]

The spec proposal deliberately makes it non-optional, though as mentioned in the threads, servers can be non-compliant if they wish.

Server operators looking for a CDN may wish to self-host MinIO or similar though, where publishing rights are less... public.

[turt2live]

@mscbot resolve Should we split the federation download endpoint in two?

[turt2live]

seemingly I can't (re-)request review from @richvdh, so @richvdh please take another look. (I assume it's because you're the PR author and it doesn't make sense to review "your own" changes)

[mscbot]

:bell: This is now entering its final comment period, as per the review above. :bell:

[mscbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

[turt2live]

Spec PR: https://github.com/matrix-org/matrix-spec/pull/1858 (release blocker)

[turt2live]

Merged 🎉