Interactions between media redirection and authentication

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

@@ -0,0 +1,60 @@
+# MSC4097: Interactions between media redirection and authentication
+
+With the introduction of [MSC3860 (merged)](https://github.com/matrix-org/matrix-spec-proposals/blob/main/proposals/3860-media-download-redirect.md),
+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)](https://github.com/matrix-org/matrix-spec-proposals/pull/3916)
+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)](https://github.com/matrix-org/matrix-spec-proposals/pull/3911),
+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.