[WIP] MSC2438: Local and Federated User Erasure Requests by anoadragon453 · Pull Request #2438 · matrix-org/matrix-spec-proposals

anoadragon453 · 2020-02-19T17:12:39Z

Half-Shot

Various thoughts and feelings about appservices (as you'd expect 😛)

Half-Shot · 2020-02-19T17:16:50Z

+
+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`


What's the expected response if the application service fails to remove the user?

Currently this MSC is designed to just fan out the request, without returning any success/failure back to the user on whether the data was actually deleted. Thus here the 200 OK is just so that the AS acknowledged the request.

Half-Shot · 2020-02-19T17:17:01Z

+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.


What's the expected response if the application service hasn't ever seen the user?

A 200 OK, as it'd be the same result as the AS deleting all data of a known user.

Half-Shot · 2020-02-19T17:18:34Z

+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


Ooi, why a blob of json and not /_matrix/app/v1/users/erase/@someone:example.com? It makes it marginally easier to trace in logging

Because the point is to remove personal data, so forcing more personal data into logs is wrong.

I'm inclined to agree with @turt2live here, but I also agree that it'd be good to have a record of which users were erased... but how you'd do that without keeping their User ID around in a database I'm not sure...

Therefore logs, which can be deleted according to a retention policy, may indeed be the best option?

Half-Shot · 2020-02-19T17:20:12Z

+}
+```
+
+At this point, the application service SHOULD try to erase as much


Worth noting that this proposal send a 200 on acknowledging but not if it's successful, not successful or even possible. It would be nice if the appservice could feedback in these different cases.

At the moment we don't plan to send feedback to the user about which application services out there couldn't process the request.

And I'm not sure what the homeserver would do in this case. It could keep retrying, but if the application service couldn't delete it the first time, why would a second request make any difference?

Half-Shot · 2020-02-19T17:21:27Z

+
+```
+{
+  "id_server_unbind_result": "success",


Kinda sucks that we have feedback for identity servers, but not for other services. It would be helpful if the API supported some granularity how successful erase has been.

This field is a hack anyways. Granular responses is probably something for a different MSC, unless this MSC can somehow make it easy and not a nightmare to deal with. There's so much more UX to consider with granularity when the user probably only cares about it working or not.

Indeed, this MSC is only concerned with getting the request out there, not getting feedback to the user. I'm still inclined to remove this field and just have the absence of an HTTP error mean success.

Half-Shot · 2020-02-19T17:23:37Z

+* Other homeservers 
+* Application services
+* Identity Servers
+* Integration managers


Worth noting that the data contract for integration managers is between itself and the client, the homeserver isn't aware of the integration manager at all.

False, the homeserver is aware of integration managers. The homeserver is also best positioned to deal with the data removal.

I'd still take integration managers out of scope of this MSC though because they don't exist at the spec level.

aaronraimist · 2020-02-19T20:13:36Z

So is this erasing everything (to the point of allowing usernames to be reused)?

anoadragon453 · 2020-02-20T10:55:34Z

So is this erasing everything (to the point of allowing usernames to be reused)?

This is simply ferrying erasure requests to different services, the spec deliberately leaves what is actually erased up to the implementation, as we can't actually enforce that at the protocol level.

anoadragon453 · 2020-02-26T20:50:54Z

@Half-Shot What do you think about this proposal?

Half-Shot · 2020-02-26T20:51:39Z

oooooooh yes

turt2live

looks like this is still in progress, but some clarifying comments.

turt2live · 2020-03-05T20:33:00Z

+* Whether we should just fail the request entirely if local user erase was
+  unsuccessful


We may need to introduce a custom error code for this then?

turt2live · 2020-03-05T20:33:41Z

+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`.


We're on v2 now:

Suggested change

communicated over a new Federation API, `/_matrix/federation/v1/user/erase`.

communicated over a new Federation API, `/_matrix/federation/v2/user/erase`.

It was my understanding that we'd start new APIs with v1, and only introduce a v2 for them if they need to be updated with breaking changes. Is this not right?

We don't have any formal standard for this, but using the identity server as an example we added /v2 endpoints without /v1 counterparts, implying that we ratchet the whole version and not on a per-endpoint basis.

There's also a difference here which is that in the IS spec every existing endpoint got a v2 (even those that haven't changed in the transition), which imho means vX is the version of the API, whereas in the S2S spec most existing endpoints are only v1 and we've only been bumping per endpoint when we need to change it, which imho means vX is the version of the endpoint.

Argh all this is confusing.

I've opened #2475 to settle this.

vX is the version of the API,

no. The API doesn't have a single version. It just sounds like we happened to bump all the IS APIs at once.

turt2live · 2020-03-05T20:33:48Z

+Example request:
+
+```
+POST /_matrix/federation/v1/user/erase


We're on v2 now:

Suggested change

POST /_matrix/federation/v1/user/erase

POST /_matrix/federation/v2/user/erase

turt2live · 2023-06-02T17:25:57Z

+A new parameter to the
+[`/account/deactivate`](https://matrix.org/docs/spec/client_server/r0.6.0#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.


We ended up implementing erase long ago, but without the federation propagation bit. #4025 covers the history here (and may affect how this proposal operates).

anoadragon453 added the proposal A matrix spec change proposal. Process state. label Feb 19, 2020

turt2live self-requested a review February 19, 2020 17:13

Local and Federated User Erasure Requests

c9eeedb

anoadragon453 force-pushed the anoa/gpdr17 branch from e1167a3 to c9eeedb Compare February 19, 2020 17:14

anoadragon453 changed the title ~~MSCXXXX: Local and Federated User Erasure Requests~~ MSC2438: Local and Federated User Erasure Requests Feb 19, 2020

Half-Shot reviewed Feb 19, 2020

View reviewed changes

turt2live reviewed Mar 5, 2020

View reviewed changes

turt2live changed the title ~~MSC2438: Local and Federated User Erasure Requests~~ [WIP] MSC2438: Local and Federated User Erasure Requests Mar 5, 2020

anoadragon453 added 3 commits March 25, 2020 12:14

Descope integration managers as they are unspecced

163cc39

Use auth block example from spec

3adb2d1

all

ac14334

richvdh mentioned this pull request Mar 27, 2020

MSC2475: API versioning #2475

Closed

Half-Shot mentioned this pull request Apr 3, 2020

Add the ability to deactivate users to prevent them from ever being bridged matrix-org/matrix-appservice-irc#1021

Merged

babolivier mentioned this pull request Apr 3, 2020

Spec: define way to tell federated homeservers and clients (esp bots and bridges) of GDPR erasure requests they should honour element-hq/riot-meta#171

Open

turt2live added the kind:feature MSC for not-core and not-maintenance stuff label Apr 20, 2020

Half-Shot mentioned this pull request Jun 3, 2020

Deactivated matrix accounts should be automatically !quit from IRC matrix-org/matrix-appservice-irc#514

Open

babolivier mentioned this pull request Aug 27, 2020

Better document what erase: true when deactivating a user does matrix-org/synapse#8185

Closed

turt2live marked this pull request as draft April 8, 2021 23:36

turt2live added the needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. label Jun 8, 2021

turt2live force-pushed the old_master branch from e895827 to dca99ee Compare August 30, 2021 22:34

reivilibre mentioned this pull request Dec 29, 2021

The erase parameter to /_matrix/client/v3/account/deactivate is not specified nor part of an accepted MSC matrix-org/synapse#11656

Open

aaronraimist mentioned this pull request Apr 14, 2020

spec 'erase' param on /account/deactivate matrix-org/matrix-spec#297

Closed

richvdh mentioned this pull request Mar 3, 2022

Mechanisms for communicating erasure requests to bots and federated homeservers #3804

Closed

Half-Shot mentioned this pull request Apr 24, 2022

MSC3759: Leave event metadata for deactivated users #3759

Open

turt2live self-assigned this Jun 1, 2023

turt2live reviewed Jun 2, 2023

View reviewed changes

KitsuneRal mentioned this pull request Jun 10, 2023

GDPR matrix-org/matrix-spec#342

Open

6 tasks

matrixbot mentioned this pull request Dec 21, 2023

The erase parameter to /_matrix/client/v3/account/deactivate is not specified nor part of an accepted MSC element-hq/synapse#11656

Open

Johennes mentioned this pull request Jan 13, 2025

GSC291: Löschkonzept v2 gematik/api-ti-messenger#291

Closed

		* Whether we should just fail the request entirely if local user erase was
		unsuccessful

	communicated over a new Federation API, `/_matrix/federation/v1/user/erase`.
	communicated over a new Federation API, `/_matrix/federation/v2/user/erase`.

	POST /_matrix/federation/v1/user/erase
	POST /_matrix/federation/v2/user/erase

Conversation

anoadragon453 commented Feb 19, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Half-Shot left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

aaronraimist commented Feb 19, 2020

Uh oh!

anoadragon453 commented Feb 20, 2020

Uh oh!

anoadragon453 commented Feb 26, 2020

Uh oh!

Half-Shot commented Feb 26, 2020

Uh oh!

turt2live left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

babolivier Mar 27, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

anoadragon453 commented Feb 19, 2020 •

edited

Loading

babolivier Mar 27, 2020 •

edited

Loading