5.0 KiB
MSC4025: Local user erasure requests
Long ago a need arose for having a user specify that they'd like to not just deactivate their account, but also erase as much of their content as possible for largely GDPR purposes. This got implemented in the matrix-js-sdk as PR #649, but never quite made it to the spec.
Back in 2018 the proposal process was very different (technically didn't actually exist at the time the js-sdk PR was written). A spec omission issue was opened to track the missing property, however an attempt1 to do the documentation got blocked on having a larger GDPR-centric proposal.
Eventually, MSC2438 was drafted, presumably to be that GDPR/erasure-specific MSC the prior spec PR was waiting for. Unfortunately, it appears to have gotten stuck in various stages of drafting.
It's highly regrettable that yet another spec change from 2018 has managed to go unspecified for so long. Theoretically, the change could go through as a spec PR (much like the one linked above) rather than as a proposal, however there is significant interest in giving the feature a formal chance to be rejected as a solution under the modern spec proposal process.
This MSC serves as that opportunity. While a more comprehensive system could be designed, such as in MSC2438, this MSC has a very narrow and specific scope of what was implemented back in 2018. For the spec process, this translates to accepting the feature as-is, or rejecting it and flagging the client behaviour non-compliant.
Proposal
A new optional boolean is added to the request body of POST /deactivate:
erase. It defaults to false and signifies whether the user would like their content to be erased
as much as possible.
Erasure does not mean issuing redactions for all of the user's sent events, but does mean that any users (or servers) which join the room after the erasure request are served redacted copies of those events. Users which had visibility on the event prior to the erasure are able to see unredacted copies.
The server should additionally erase any non-event data associated with the user, such as account data and contact 3PIDs.
This is in line with what Synapse does, as referenced here.
This is also what is described by the matrix.org blog post on GDPR compliance.
Potential issues
Erasure requests are not sent over federation in this model, meaning servers which already have an unredacted copy of the event will continue to serve that to their users after the erasure happened. Servers are expected to be informed out of band of erasure requests that affect them, if they affect them.
Alternatives
MSC2438 is the leading alternative, however as specified in the introduction for this proposal, the desired outcomes of this MSC are either acceptance as-written or rejection. Ideally, if rejected, another MSC or idea is marked as the suitable alternative.
Redactions could be sent for all the user's events, however this has obvious performance impact on servers and rooms. The matrix.org blog discusses how redactions and GDPR Right to Erasure interact (or rather, how they aren't the same).
Security considerations
This feature was originally introduced primarily in response to the GDPR Right to Erasure requirement within the European Union. The privacy benefits apply to all users of the ecosystem and there's no clear reason to region-lock or otherwise leave this as an implementation detail for EU-operated homeservers.
There are however consequences of GDPR erasure that are not covered by this proposal, such as the deletion of server logs, forwarding the request, etc. Server operators are encouraged to seek legal advice on how to handle this form of erasure request (and whether it qualifies under GDPR's Right to Erasure requirements). The general recommendation is to enforce the erasure request as much as possible on the local homeserver, including redacting/purging server logs, appservice data, etc.
Unstable prefix
Even more regrettably than having unspecified behaviour, this feature was implemented before unstable
namespaces existed. Implementations can use erase without prefix.
-
Readers should note that the spec-proposals repo used to contain both the spec itself and proposals to change the spec. This was later split into dedicated repos, but closed PRs and issues were not migrated. ↩︎