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

MSC3916: Authentication for media #3916

Merged
merged 25 commits into from
Jun 10, 2024
Merged
Changes from 4 commits
Commits
Show all changes
25 commits
Select commit Hold shift + click to select a range
7606e53
MSC3916: Authentication for media
richvdh Oct 23, 2022
3076de0
minor edits
richvdh Oct 23, 2022
55303b5
fix some links
richvdh Mar 10, 2023
d601637
Prevent further spread of unauthenticated media
turt2live Apr 5, 2024
c2ae25e
Address review feedback
turt2live Apr 22, 2024
8351ebe
Drop federation thumbnails
turt2live Apr 22, 2024
106ce55
Add comparisons
turt2live Apr 23, 2024
a14c4af
Clarify that query string auth is forbidden
turt2live May 14, 2024
92eba2c
Document `/create` changing namespace too
turt2live May 21, 2024
a76d97f
Clarify what is happening to `/upload`
turt2live May 21, 2024
8bb5159
Minor wording clarifications, primarily around using HTTPS for idp icons
turt2live May 21, 2024
e1e8a6a
Drop `serverName` in new federation download endpoint
turt2live May 21, 2024
71b8db4
Move `/create` to unmodified
turt2live May 28, 2024
1c864a3
Mention cookies
turt2live May 28, 2024
e5c9316
Forgot a mention of `/create`
turt2live May 28, 2024
41d2aa2
Add `Location` header support to federation `/download`
turt2live May 28, 2024
d73025b
Update proposals/3916-authentication-for-media.md
turt2live May 29, 2024
656dfb8
Update proposals/3916-authentication-for-media.md
turt2live May 29, 2024
87c08e0
Move allow_redirect behaviour fully into dedicated point
turt2live May 29, 2024
1fe8d71
Clarify backwards compatibilty/freezing
turt2live May 29, 2024
aac1909
Clarify that access token auth is permitted, but not recommended
turt2live May 29, 2024
0b4f2c9
Clarify header behaviour around Location
turt2live May 29, 2024
f1777c2
Fix social sign-on icons
turt2live May 29, 2024
4fe23e5
Update proposals/3916-authentication-for-media.md
turt2live May 30, 2024
db90b92
Reintroduce federation /thumnail
turt2live Jun 3, 2024
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
233 changes: 233 additions & 0 deletions proposals/3916-authentication-for-media.md
turt2live marked this conversation as resolved.
Show resolved Hide resolved
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewers: Please compare this MSC against #2461 , which is proposed for rejection/closure.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@turt2live I think we can resolve this since #2461 is closed?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's still useful to compare the MSCs, given the ideas and concepts of 2461 are meant to be incorporated here.

Original file line number Diff line number Diff line change
@@ -0,0 +1,233 @@
# MSC3916: Authentication for media access, and new endpoint names

Currently, access to media in Matrix has a number of problems including the following:

* The only protection for media is the obscurity of the URL, and URLs are
easily leaked (eg accidental sharing, access
logs). [synapse#2150](https://github.com/matrix-org/synapse/issues/2150)
* Anybody (including non-matrix users) can cause a homeserver to copy media
into its local
store. [synapse#2133](https://github.com/matrix-org/synapse/issues/2133)
* When a media event is redacted, the media it used remains visible to all.
[synapse#1263](https://github.com/matrix-org/synapse/issues/1263)
* There is currently no way to delete
media. [matrix-spec#226](https://github.com/matrix-org/matrix-spec/issues/226)
* If a user requests GDPR erasure, their media remains visible to all.
* When all users leave a room, their media is not deleted from the server.

These problems are all difficult to address currently, because access to media
is entirely unauthenticated. The first step for a solution is to require user
authentication. Once that is done, it will be possible to impose authorization
requirements to address the problems mentioned above. (See, for example,
[MSC3911](https://github.com/matrix-org/matrix-spec-proposals/pull/3911) which
builds on top of this MSC.)

This proposal supersedes [MSC1902](https://github.com/matrix-org/matrix-spec-proposals/pull/1902).

## Proposal

1. New endpoints

The existing `/_matrix/media/v3/` endpoints are to be deprecated, and replaced
by new endpoints under the `/_matrix/client` and `/_matrix/federation`
hierarchies.
turt2live marked this conversation as resolved.
Show resolved Hide resolved

The table below shows a mapping between old and new endpoint:

| Old | Client-Server | Federation |
| ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------- | ------------------------------------------------------------------- |
| [`GET /_matrix/media/v3/preview_url`](https://spec.matrix.org/v1.6/client-server-api/#get_matrixmediav3preview_url) | `GET /_matrix/client/v1/media/preview_url` | - |
| [`GET /_matrix/media/v3/config`](https://spec.matrix.org/v1.6/client-server-api/#get_matrixmediav3config) | `GET /_matrix/client/v1/media/config` | - |
| [`GET /_matrix/media/v3/download/{serverName}/{mediaId}`](https://spec.matrix.org/v1.6/client-server-api/#get_matrixmediav3downloadservernamemediaid) | `GET /_matrix/client/v1/media/download/{serverName}/{mediaId}` | `GET /_matrix/federation/v1/media/download/{serverName}/{mediaId}` |
| [`GET /_matrix/media/v3/download/{serverName}/{mediaId}/{fileName}`](https://spec.matrix.org/v1.6/client-server-api/#get_matrixmediav3downloadservernamemediaidfilename) | `GET /_matrix/client/v1/media/download/{serverName}/{mediaId}/{fileName}` | - |
| [`GET /_matrix/media/v3/thumbnail/{serverName}/{mediaId}`](https://spec.matrix.org/v1.6/client-server-api/#get_matrixmediav3thumbnailservernamemediaid) | `GET /_matrix/client/v1/media/thumbnail/{serverName}/{mediaId}` | `GET /_matrix/federation/v1/media/thumbnail/{serverName}/{mediaId}` |

**Note**: [`POST /_matrix/media/v3/upload`](https://spec.matrix.org/v1.6/client-server-api/#post_matrixmediav3upload)
is **not** modified by this MSC: it is intended that it be brought into line with the other
endpoints by a future MSC, such as [MSC3911](https://github.com/matrix-org/matrix-spec-proposals/pull/3911).

After this proposal is released in a stable version of the specification, servers
which support the new `download` and `thumbnail` endpoints should cease to serve
newly uploaded media from the unauthenticated versions. This includes media
turt2live marked this conversation as resolved.
Show resolved Hide resolved
uploaded by local users and requests for not-yet-cached remote media. This is
done with a 404 `M_NOT_FOUND` error, as though the media doesn't exist.
turt2live marked this conversation as resolved.
Show resolved Hide resolved

2. Removal of `allow_remote` parameter from `/download`

The current
[`/download`](https://spec.matrix.org/v1.6/client-server-api/#get_matrixmediav3downloadservernamemediaid)
and
[`/thumbnail`](https://spec.matrix.org/v1.6/client-server-api/#get_matrixmediav3thumbnailservernamemediaid)
endpoints take an `allow_remote` query parameter, indicating whether the
server should request remote media from other servers. This is redundant
with the new endpoints, so will not be supported.

Servers should never return remote media from `GET
/_matrix/federation/v1/media/download` or `GET
/_matrix/federation/v1/media/thumbnail`; indeed, the `serverName` is
included in the URI only for consistency with the CS-API.

`/_matrix/client/v1/media/download` and
`/_matrix/client/v1/media/thumbnail` should return remote media as normal.

3. Authentication on all endpoints

Currently, the `/download` and `/thumbnail` endpoints have no authentication
requirements. Under this proposal, the new endpoints will be authenticated
the same way as other endpoints: they will require an `Authorization` header
which must be `Bearer {accessToken}` for `/_matrix/client`, or the signature
turt2live marked this conversation as resolved.
Show resolved Hide resolved
for `/_matrix/federation`.
turt2live marked this conversation as resolved.
Show resolved Hide resolved
turt2live marked this conversation as resolved.
Show resolved Hide resolved

4. Updated response format

* For the new `/_matrix/client` endpoints, the response format is the same as
the corresponding original endpoints.

* To enable future expansion, for the new `/_matrix/federation` endpoints,
the response is
[`multipart/mixed`](https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html)
turt2live marked this conversation as resolved.
Show resolved Hide resolved
content with two parts: the first must be a JSON object (and should have a
`Content-type: application/json` header), and the second is the media item
as per the original endpoints.
turt2live marked this conversation as resolved.
Show resolved Hide resolved

No properties are yet specified for the JSON object to be returned.

An example response:

```
Content-Type: multipart/mixed; boundary=gc0p4Jq0M2Yt08jU534c0p

--gc0p4Jq0M2Yt08jU534c0p
Content-Type: application/json

{}

--gc0p4Jq0M2Yt08jU534c0p
Content-Type: text/plain

This media is plain text. Maybe somebody used it as a paste bin.

--gc0p4Jq0M2Yt08jU534c0p
```
turt2live marked this conversation as resolved.
Show resolved Hide resolved

5. Backwards compatibility mechanisms

a. Backwards compatibility with older servers: if a client or requesting
server receives a 404 error with a non-JSON response, or a 400 or 404 error with
`{"errcode": "M_UNRECOGNIZED"}`, in response to a request to one of the new
endpoints, they may retry the request using the original endpoint.
turt2live marked this conversation as resolved.
Show resolved Hide resolved

b. Backwards compatibility with older clients and federating servers:
servers may for a short time choose to allow unauthenticated access via the
deprecated endpoints.
turt2live marked this conversation as resolved.
Show resolved Hide resolved

### Effects on client applications

Naturally, implementations will be required to provide `Authorization` headers
when accessing the new endpoints. This will be simple in some cases, but rather
more involved in others. This section considers some of those cases.

#### IRC/XMPP bridges

Possibly the largest impact will be on IRC and XMPP bridges. Since IRC and
XMPP have no media repository of their own, these bridges currently transform
`mxc:` URIs into `https://<server>/_matrix/media/v3/download/` URIs and forward
those links to the remote platform. This will no longer be a viable option.

One potential solution is for the bridges to provide a proxy.

In this scenario, the bridge would have a secret HMAC key. When it
receives a matrix event referencing a piece of media, it should create a new URI
referencing the media, include an HMAC to prevent tampering. For example:

```
https://<bridge_server>/media/{originServerName}/{mediaId}?mac={hmac}
```

When the bridge later receives a request to that URI, it checks the hmac,
and proxies the request to the homeserver, using its AS access
token in the `Authorization` header.

The bridge might also choose to embed information such as the room that
referenced the media, and the time that the link was generated, in the URL.
Such mechanisms would allow the bridge to impose controls such as:

* Limiting the time a media link is valid for. Doing so would help prevent
visibility to users who weren't participating in the chat.

* Rate-limiting the amount of media being shared in a particular room (in other
words, avoiding the use of Matrix as a Warez distribution system).

#### Icons for "social login" flows

When a server supports multiple login providers, it provides the client with
icons for the login providers as `mxc:` media URIs. These must be accessible
without authentication (because the client has no access token at the time the
icons are displayed).

This remains a somewhat unsolved problem. Possibly the clients can continue
turt2live marked this conversation as resolved.
Show resolved Hide resolved
to call the legacy `/_matrix/media/v3/download` URI for now: ultimately this
problem will be solved by the transition to OIDC. Alternatively, we may need
to provide an alternative `/_matrix/client/v3/login/sso/icon/{idpId}` API
specifically for access to these icon.
turt2live marked this conversation as resolved.
Show resolved Hide resolved

(This was previously discussed in
[MSC2858](https://github.com/matrix-org/matrix-spec-proposals/pull/2858#discussion_r543513811).)

## Potential issues
turt2live marked this conversation as resolved.
Show resolved Hide resolved
turt2live marked this conversation as resolved.
Show resolved Hide resolved
turt2live marked this conversation as resolved.
Show resolved Hide resolved

* Setting the `Authorization` header is going to be annoying for web clients. Service workers
might be needed.

* Users will be unable to copy links to media from web clients to share out of
band. This is considered a feature, not a bug.

## Alternatives
turt2live marked this conversation as resolved.
Show resolved Hide resolved

* Allow clients to upload media which does not require authentication (for
turt2live marked this conversation as resolved.
Show resolved Hide resolved
example via a `public=true` query parameter). This might be particularly
useful for IRC/XMPP bridges, which could upload any media they encounter to
the homeserver's repository.

The danger with this is that is that there's little stopping clients
continuing to upload media as "public", negating all of the benefits in this
MSC. It might be ok if media upload it was restricted to certain privileged
users.

* We could simply require that `Authorization` headers be given when calling
the existing endpoints. However, doing so would make it harder to evaluate
the proportion of clients which have been updated, and it is a good
opportunity to bring these endpoints into line with the rest of the
client-server and federation APIs.

* There's no real need to rename `GET /_matrix/media/v3/preview_url` and `GET
/_matrix/media/v3/config` at present, and we could just leave them in
place. However, changing them at the same time makes the API more consistent.

Conversely, we should make sure to rename `POST
/_matrix/media/v3/upload`. The reason to delay doing so is because MSC3911
will make more substantial changes to this endpoint, requiring another
rename, and it is expected that both proposals will be mergeed at the same
time (so a double rename will be confusing and unnecessary). However, if
MSC3911 is delayed or rejected, we should reconsider this.

* Rather than messing with multipart content, have a separate endpoint for
servers to get the metadata for a media item. That would mean two requests,
but might make more sense than both `/thumbnail` and `/download` providing
the info.

## Unstable prefix

While this proposal is in development, the new endpoints should be named as follows:

* `GET /_matrix/client/unstable/org.matrix.msc3916/media/preview_url`
* `GET /_matrix/client/unstable/org.matrix.msc3916/media/config`
* `GET /_matrix/client/unstable/org.matrix.msc3916/media/download/{serverName}/{mediaId}`
* `GET /_matrix/client/unstable/org.matrix.msc3916/media/download/{serverName}/{mediaId}/{fileName}`
* `GET /_matrix/client/unstable/org.matrix.msc3916/media/thumbnail/{serverName}/{mediaId}`
* `GET /_matrix/federation/unstable/org.matrix.msc3916/media/download/{serverName}/{mediaId}`
* `GET /_matrix/federation/unstable/org.matrix.msc3916/media/thumbnail/{serverName}/{mediaId}`

turt2live marked this conversation as resolved.
Show resolved Hide resolved
## Dependencies

None at present.