-
Notifications
You must be signed in to change notification settings - Fork 379
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Local and Federated User Erasure Requests
- Loading branch information
1 parent
7a878bb
commit e1167a3
Showing
1 changed file
with
166 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,166 @@ | ||
# Local and Federated User Erasure Requests | ||
|
||
When communicating across Matrix, it's not uncommon for user data and | ||
metadata to be strewn across many different servers and services. Given this, | ||
it is necessary to have a mechanism for removing as much personal data as | ||
possible across the ecosystem upon user request. | ||
|
||
This proposal specifies a best-effort method for erasing one's presence | ||
across a Matrix federation, beginning with your own homeserver. | ||
|
||
This proposal will mention 'personal data', however it intentionally leaves | ||
the definition vague on purpose. Implementations SHOULD remove as much | ||
identifying information about a user as they can. | ||
|
||
## Proposal | ||
|
||
Changes across multiple APIs are necessary to communicate requests of user | ||
data erasure across all the different bits and pieces of the Matrix | ||
ecosystem. We start with the initial erasure request from a user to their | ||
homeserver. | ||
|
||
A new parameter to the | ||
[`/account/deactivate`](https://matrix.org/docs/spec/client_server/unstable#post-matrix-client-r0-account-deactivate) | ||
Client-Server API endpoint will be added, called `erase`, which is a boolean | ||
that specifies whether the homeserver MUST attempt to erase all personal | ||
data pertaining to the user off of the homeserver and as much of the rest of | ||
the federation as it can. | ||
|
||
Example request: | ||
|
||
``` | ||
POST /_matrix/client/r0/account/deactivate | ||
{ | ||
"auth": { | ||
"type": "m.login.password", | ||
"identifier": { | ||
"type": "m.id.user", | ||
"user": "someone" | ||
}, | ||
}, | ||
"erase": true | ||
} | ||
``` | ||
|
||
Example response: | ||
|
||
``` | ||
{ | ||
"id_server_unbind_result": "success", | ||
"erased": true | ||
} | ||
``` | ||
|
||
The `erased` field in the response is to allow the client to know whether the | ||
erasure was successful in relation to the deactivation. At this time the | ||
author is unsure about this due to: | ||
|
||
* Non-clarity to the client about whether this means erasure was successful on | ||
the user's homeserver, or across the global federation | ||
* Whether we should just fail the request entirely if local user erase was | ||
unsuccessful | ||
|
||
A call to this endpoint from the user kicks off the erasure flow. From this | ||
point, we would like to communicate the erasure request to: | ||
|
||
* Other homeservers | ||
* Application services | ||
* Identity Servers | ||
* Integration managers | ||
* Any other service in the matrix ecosystem | ||
|
||
which may have data (e.g. messages) pertaining to this user. | ||
|
||
Upon receiving this request, the homeserver should forward it to every | ||
homeserver it believes could also contain that user's data. How it does so is | ||
left as an implementation detail. Once it's decided, the request will be | ||
communicated over a new Federation API, `/_matrix/federation/v1/user/erase`. | ||
|
||
Example request: | ||
|
||
``` | ||
POST /_matrix/federation/v1/user/erase | ||
{ | ||
"user_id": "@bob:example.com" | ||
} | ||
``` | ||
|
||
Example response: | ||
|
||
``` | ||
{} | ||
``` | ||
|
||
It should be noted here that erasure requests for a given user should only be | ||
allowed from the homeserver the user belongs to. If this isn't the case, the | ||
other homeserver should respond with a `403 M_FORBIDDEN`. | ||
|
||
For application services, a new API endpoint will be added on the application | ||
service: `POST /_matrix/app/v1/users/erase`. It contains a single, required | ||
field `user_id`, which is the user ID to erase identifying data of. | ||
|
||
Example request: | ||
|
||
``` | ||
{ | ||
"user_id": "@someone:example.com" | ||
} | ||
``` | ||
|
||
At this point, the application service SHOULD try to erase as much | ||
identifying information about this user as possible. Upon successfully | ||
acknowledging the request, the application service should return a `200 OK` | ||
with an empty JSON body. | ||
|
||
Example response: | ||
|
||
``` | ||
{} | ||
``` | ||
|
||
For identity servers... (is reusing unbind enough, or do we need a separate | ||
endpoint to delete the db rows?). | ||
|
||
## Potential issues | ||
|
||
As we live in an open federation, other services have the right to refuse | ||
erasure request. (XXX: Does this mean anything legally?). It is not the | ||
responsibility of the user's homeserver to ensure absolutely that all data | ||
about this user across the federation has been deleted, which is impossible. | ||
It simply needs to make its best attempt to request data erasure from all | ||
necessary sources. | ||
|
||
## Alternatives | ||
|
||
This proposal relies on sending a federation request to another homeserver | ||
(ideally retrying for a while if the other homeserver is currently offline), | ||
which could potentially fail if the other homeserver doesn't come back on for | ||
a long time period. | ||
|
||
Alternative solutions have been considered: | ||
|
||
* homeservers could maintain a public list of Matrix IDs that other | ||
servers/services could poll periodically. | ||
|
||
While this solves the problem with servers/ASes which are offline at the | ||
point of the request, but instead gives us a "how often to poll" problem. | ||
It's also slightly questionable to maintain a publicly-available list of | ||
"everybody who has asked to be erased" - if nothing else, it seems counter to | ||
the spirit of GDPR. | ||
|
||
* An `m.room.erasure` state event could be sent that contains the erased user's | ||
Matrix ID. | ||
|
||
This works and uses existing mechanisms for reliable communication, however | ||
comes with the same awkward public-list scenario as the above solution, as | ||
well as adds yet more state to large rooms, not to mention state event | ||
permission considerations. | ||
|
||
|
||
## Security considerations | ||
|
||
Malicious server admins can send out erasure requests for their own users | ||
across the federation. However users already include their own homeserver in | ||
their trust model, so this is a non-issue. |