MSC2278: Deleting attachments for expired and redacted messages #2278
Conversation
ara4n
changed the title
ara4n
changed the title
|
FCPing this because I think it works, and because we need it for privacy work. @mscbot fcp merge |
|
This FCP proposal has been cancelled by #2278 (comment). Team member @mscbot has proposed to merge this. The next step is review by the rest of the tagged people: Concerns:
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. |
mscbot
added
proposed-final-comment-period
| The user must be authenticated via access_token or Authorization header as the | ||
| original uploader or as a server admin in order to delete the content. | ||
|
|
||
| Servers may wish to quarantine the deleted content for some timeframe before |
There was a problem hiding this comment.
we should probably spec the quarantine API (in a different MSC, in the future, eventually)
Co-Authored-By: Travis Ralston <travpc@gmail.com>
Co-Authored-By: Travis Ralston <travpc@gmail.com>
Per [MSC2278](matrix-org/matrix-spec-proposals#2278) Fixes #200
|
I ended up writing an implementation of this (by accident, async to this MSC):
|
|
@mscbot concern we need to spec exactly who is allowed to delete an attachment |
Co-authored-by: Hubert Chathi <hubert@uhoreg.ca>
Co-authored-by: Hubert Chathi <hubert@uhoreg.ca>
Co-authored-by: Hubert Chathi <hubert@uhoreg.ca>
|
sorry this got stuck forever; i think i completely missed the wave of feedback at the time. i believe i've now incorporated it all. |
|
I think there are still too many outstanding questions for this to come near FCP, and I don't think we yet have a complete implementation. (In particular, as it currently stands, the MSC seems to place requirements on the homeserver as well as the media repo, so I don't think @turt2live 's implementation is complete). As such: @mscbot fcp cancel |
|
This proposal is not in FCP. |
|
oh, duh, it never got into FCP. |
|
@mscbot resolve we need to spec exactly who is allowed to delete an attachment |
1 similar comment
|
@mscbot resolve we need to spec exactly who is allowed to delete an attachment |
|
Unknown concern 'we need to spec exactly who is allowed to delete an attachment'. |
| ### Encrypted rooms | ||
|
|
||
| There is no way for server to know what events refer to which MXC URL, so we | ||
| leave it up to the client to DELETE any MXC URLs referred to by an event after |
There was a problem hiding this comment.
I'm a bit confused by this: assuming that there is more than one client in a given room, which has responsibility for making the DELETE request? I guess it has to be a client belonging to the original uploader, but what if they go away/stop watching the room/etc?
There was a problem hiding this comment.
It would have to be the original uploader, but indeed, that doesn't help if someone else redacts their event for them and they don't come back and finish it off by deleting the media.
|
@mscbot fcp cancel there's no working impl for this yet, so it's not ready for FCP. |
mscbot
added
proposal-in-review
and removed
disposition-merge
proposed-final-comment-period
turt2live
added
the
needs-implementation
| It seems reasonable to consider the special case of clients forwarding | ||
| encrypted attachments between rooms as a 'copy by reference' - if the | ||
| original event gets deleted, the copies should too. If this isn't desired, | ||
| then the attachment should have been reencrypted and stored as a separate | ||
| instance in the media repo. |
There was a problem hiding this comment.
This seems a bit unfortunate, but I can't say whether or not that's the right thing to do.
I quite often forward encrypted media between rooms, I also think sticker packs (and similar) could run into this instance.
Re-uploading media does seem to be the privacy-preserving approach compared to having to do some refcounting and linking each message to the media (though I wouldn't guarantee that you couldn't correlate e.g. the filesize of the sticker, etc), but I fear it may be rubbish for UX, and especially on slow/mobile connections (where we also might want to avoid reuploading to reduce overall data transmitted).
Finally, if you forward the message and then delete the forwarded copy, how could this be distinguished from deleting the original as it stands?
Deeply conflicted here because I really wish the media store wasn't a monotonically growing area on my disk (without having to resort to heuristic methods like expiring media that hasn't been accessed in a while), but privacy is of course important.
As an unrefined idea: Perhaps we could allow asking the homeserver to clone an existing piece of media to a new MXC URI? As a trade-off, my application might prefer to have the server do the copy (the actual implementation would likely be smarter than that — see hard links on a filesystem) and forward the 'new' MXC URI into a e.g. sticker event.
The rest of your proposal can still stand — if I delete a message, its MXC URI can get unlinked alongside that. I've lost some privacy potentially (though it's arguable, since if you know what sticker pack I use in my conversations a lot, the filesize probably gives it away by equal measure), but it was my choice and I'm not stopping you or anyone else from having your reencrypt-on-copy implementation when that suits the trade-off better.
| ### Encrypted rooms | ||
|
|
||
| There is no way for server to know what events refer to which MXC URL, so we | ||
| leave it up to the client to DELETE any MXC URLs referred to by an event after |
There was a problem hiding this comment.
It would have to be the original uploader, but indeed, that doesn't help if someone else redacts their event for them and they don't come back and finish it off by deleting the media.
|
i believe this is obsoleted by #3911 ? |
Split off from #1763
Rendered