matrix-spec-proposals/proposals/4097-media-redirect-with-auth.md

MSC4097: Interactions between media redirection and authentication

With the introduction of MSC3860 (merged), media download requests can be redirected to a CDN or other resource, allowing server owners to reduce costs of hosting a Matrix homeserver. MSC3916 (proposed) introduces a concept of authenticating those download requests. Authentication alone doesn't prevent the ability to use a CDN (the client simply authenticates its request, then gets redirected), however with follow-up MSCs like MSC3911 (proposed), the media the client is trying to download may be linked to an event and thus should not be viewable by sharing the link to third parties.

The abstract concept of preventing users from sharing download links with users/clients not in the room is tricky to resolve in a way where a CDN can still operate. CDNs are not typically capable of doing the authentication check themselves during the download request, necessitating a Matrix-aware application layer to perform that authentication. The layer can still redirect to the CDN, but that then opens up an opportunity for the user to copy/paste the link again.

Some server operators may be tolerable to this risk or decide that a time-limited URL with the CDN is suitable for their use case. Others, however, may still wish to use a CDN and prevent most cases of copy/paste from working.

This proposal covers that use case. A symmetric encryption key is generated by the server after the request is authenticated, injected into the CDN, and then returned to the client alongside the redirect. The client then follows the redirect and requests the media from the CDN. The CDN encrypts the media download on the fly using the symmetric key, and the client decrypts it before serving it to the user (or before further decrypting it, if the media is in an encrypted room). If the user were to share the redirected URL, the requester would get encrypted content back unless the user also extracted the key from their client.

Most notably, this behaviour is opt-in. Both the client and server can decide to use a different approach for serving media, though that approach may have lesser security/privacy.

TODO: Consider not re-encrypting media that's in an encrypted room already. It's simpler to encrypt everything, but if we already know the event ID contains encrypted content because we've linked it to the media ID, we can probably assume it'll be fine enough to serve verbatim.

Proposal

TODO: The words! Somehow the client needs to get the key (/config?), and needs to know how to use it. Also, pick an encryption algorithm.

Potential issues

TODO: This section.

Alternatives

TODO: This section.

Security considerations

TODO: This section.

Unstable prefix

TODO: This section.

Dependencies

TODO: This section.