Auth for content repo (and enforcing GDPR erasure)

[matrixbot]

Formerly MSC701.
Documentation: https://docs.google.com/document/d/1ERHpmthZyspnZtE3tQzxKTkcxar6JANeyNXgz2_djhA/edit#
Author: @ara4n
Date: 2018-06-04

The media repository is currently unauthed; anybody can access posted images, avatars, etc, if they know the URI.

Submitted by @​matthew:matrix.org

(Imported from https://matrix.org/jira/browse/SPEC-445)

[matrixbot]

Jira watchers: @ara4n @richvdh

[matrixbot]

Actually, E2E provides quite an elegant solution for this, in that you can't decrypt the content if you don't have the keys. (Then again, from a corp security perspective they prolly don't even want you downloading the encrypted data)

-- @ara4n

[richvdh]

Synapse-side issue at https://github.com/matrix-org/synapse/issues/2150

[turt2live]

I don't think this has been answered somewhere, so asking here in hopes people have ideas: How would federated media work?

In theory the server could start signing requests to download media, although that doesn't really guarantee that the person making the request is allowed to do so (ie: is in the room). With the upcoming introduction of users being linked to key-like objects, we could possibly use those to sign the requests, however there's nothing to stop a server lying about which user is requesting the media.

Then there's the question of the user potentially wanting specific media being publicly accessible. The primary use case being the IRC bridge which pastebins long messages.

[ara4n]

let's discuss this over at matrix-org/synapse#2150 matrix-org/matrix-spec#870, as that bug's bigger

[richvdh]

see also #2461 which is an alternative proposal.

[richvdh]

See also #3916 and #3911 which are yet more alternative proposals.

[turt2live]

Note that this MSC is more to do with what we now call "linking" instead, as a sort of MSC3911 alternative. MSC3916 does have some overlap, but not nearly as much as MSC3911 does.