Documentation for how to delete a user

[KlausHans]

I want to delete testusers, how can i do this? The documentation only points out how to register a new user.

[Torxed]

I'd like to point out that doing:

DELETE FROM users WHERE name='@user:domain.com';

Is a bad idea, just as INSERT INTO users VALUES (...);, these are not fullfilling the requirements of a new user internally in Synapse.

[ara4n]

the right way to delete a user is to use the deactivate API:

curl -X POST 'https://matrix.org/_matrix/client/r0/admin/deactivate/%40someone%3Amatrix.org?access_token=...' --data '{}'

we do not recommend blindly deleting rows from databases, as it could leave things in a very inconsistent state.

[rorymbyrne]

@ara4n How is this implemented in a self hosted version?

[ghost]

I'd also like to know how to delete users, in layman terms if possible.

[Kleingeldprinz]

I wan't to delete users in self-hosted environment, like @rorymbyrne How is this done? EDIT: @ara4n @rorymbyrne This works in a local environment too. Just use your own servername and the local id of the user.

[rorymbyrne]

Matrix really needs a simpler UI/UX for being able to add and delete users.

[cavebeat]

searching for the same delete button. a testuser has regged with beginning capital characters, and so it makes problems to interact with him...

delete and rereq does not work. because it's already created... gnaahhh

and haven't found yet a admin console or interface ...

[slipeer]

@ara4n i found that deactivate API call don't remove user record from users table (checked at 0.22.1 release) - and user can't register again afte deactivation with same login.

[richvdh]

i found that deactivate API call don't remove user record from users table (checked at 0.22.1 release) - and user can't register again afte deactivation with same login.

If you want to be able to reuse the userid, you don't want to deactivate: just reset the password.

[richvdh]

Matrix really needs a simpler UI/UX for being able to add and delete users.

and haven't found yet a admin console or interface ...

https://github.com/vector-im/riot-web/issues/4125 concerns this

[rajil]

I tried to delete an account, but received

{
    "errcode": "M_FORBIDDEN",
    "error": "You are not a server admin"
}

How can i delete the account?

[alecdwm]

@rajil this might help, from the admin api docs:

This directory includes documentation for the various synapse specific admin APIs available.

Only users that are server admins can use these APIs. A user can be marked as a server admin by updating the database directly, e.g.:

UPDATE users SET admin = 1 WHERE name = '@foo:bar.com'

Restarting may be required for the changes to register.

[mohnish82]

@cavebeat @slipeer As an admin, you can reset another user's password.

• Login as admin user and obtain access token. curl -XPOST -d '{"type":"m.login.password", "user":"<userId>", "password":"<pasword>"}' "https://localhost:8448/_matrix/client/r0/login"
• Then using that access token, reset any user's password. curl -XPOST -H "Authorization: Bearer <access_token>" -H "Content-Type: application/json" -d '{"new_password":"<new_password>"}' "https://localhost:8448/_matrix/client/r0/admin/reset_password/<userId>"

PS: <userId> is fully qualified. E.g. @user:server.com Ref: Docs

[rgpublic]

Okay, I've created a script for now to deactive an account:

https://gist.github.com/rgpublic/8457d98b0fcc0c54893b9907f9b8b825

Nevertheless it just sucks with at least a 3x factor:

Suck vector-im/element-web#1: No decent UI Suck vector-im/element-web#2: Can only deactivate; not really delete Suck vector-im/element-web#3: User isnt automatically removed from rooms/communities

[rgpublic]

Hm. With my script, there's one user I cannot delete. I always get "Failed to remove threepid from ID server". Is there anyone who knows what this might mean? Argh, it's a nightmare. I wonder how companies with more employees than us handle this. People sometimes happen to leave the company and then.... what? One of the really sad points of an otherwise really user-friendly, stable and great chat software. We're very happy with it, but the fact that you can always easily create stuff but you never can remove stuff the same way i.e. via Riot (Rooms, Account) is just terrible IMHO.

[bjo81]

ack! We had ~200 spamming IRC users via the freenode-bridge in a room and kicking them via riot is quite annoying.

[ArchangeGabriel]

I need a way to delete users definitively from the DB (my use case is that a change in an IRC Bridge configuration left a lot of ghosts users in the DB).

[dmitrygashnikov]

the right way to delete a user is to use the deactivate API:

curl -X POST 'https://matrix.org/_matrix/client/r0/admin/deactivate/%40someone%3Amatrix.org?access_token=...' --data '{}'

we do not recommend blindly deleting rows from databases, as it could leave things in a very inconsistent state.

Great! Is there any way to reactivate users?

[rubo77]

I think the main reason why it is not implemented to really delete a user is that this would make it possible to overtake an old Account of another User that was deleted by Registering again with the same name.

So couldn't we add a real deletion only for users that either never said anything or where all the user's messages are already redacted?

[menturion]

Can a user really not be deleted?

If this is the case, Matrix Synapse would not be GDPR compliant, since the "Right to Erasure ("right to be forgotten")" would not be fulfilled upon user request, see e.g. here ... https://gdpr-info.eu/art-17-gdpr/

The provider of the homeserver would be obligated to delete all user data manually.

Same with respect to changing the matrix user ID, which is visible and cannot be edited after registration. This might not comply to the "Right of access and right to rectification", see https://gdpr-info.eu/art-15-gdpr/ and https://gdpr-info.eu/art-16-gdpr/. A user must be able to access and edit his personal data.

[Torxed]

Can a user really not be deleted?

If this is the case, Matrix Synapse would not be GDPR compliant, since the "Right to Erasure ("right to be forgotten")" would not be fulfilled upon user request, see e.g. here ... https://gdpr-info.eu/art-17-gdpr/

The provider of the homeserver would be obligated to delete all user data manually.

Same with respect to changing the matrix user ID, which is visible and cannot be edited after registration. This might not comply to the "Right of access and right to rectification", see https://gdpr-info.eu/art-15-gdpr/ and https://gdpr-info.eu/art-16-gdpr/. A user must be able to access and edit his personal data.

Aside from laws and regulations which might be subject to change. The fact that one can't administrate their own infrastructure is ludicrous and has been for a long time now. I'm not sure how this project has gotten away with it to be honest.

[neilisfragile]

@menturion users are deactivated rather than deleted, for matrix.org, our Privacy Policy (https://matrix.org/docs/guides/privacy_notice.html) describes how we satisfy our GDPR obligations, in particular the Right to Erasure.

Admins for other homeservers are of course free to publish their own privacy policy and implement it as they see fit.

More generally we agree that having easier to use and more powerful admin tools would be beneficial and it features on our roadmap (https://github.com/orgs/matrix-org/projects/9). The only reason we are not working on it right now is a question of bandwidth.

[rgpublic]

@neilisfragile Well, I think this is a bit of a view with rose-tinted glasses on. Fact is, the e-mail address is considered to be "personal data" in regard to the GDPR. Currently, it is stored on the server for an indefinite amount of time with no way to ever remove it. This is IMHO a clear GDPR violation. You can publish policies all you want but that doesn't turn illegal stuff into legal stuff. I can write my own policy that I intent to drive consistently at 100 mph but that doesnt make it legal.

What's more, I as an admin of an "other homeserver" would very much like to publish my own privacy policy stating that we delete the account completely. Unfortunately, I cannot realize that policy without decent means to delete anything. What I'm currently planning to do is completely wipe the server once per year and start with a fresh Matrix server. Otherwise I think there is currently not really a decent way to make sure that old stuff is not kept around forever. I have currently a crazy set of helper scripts which fumble around with the DB to delete rooms, accounts etc. But whether they really remove everything I just don't know. This should be clearer and easier.

We are using the scheme @company.de for our email addresses. If a new coworker arrived with the same lastname as a previous one, we couldn't create a new account for him/her. With email accounts, for example, this is not a problem at all.

Finally, if you look at the recent matrix.org security breach and the fact that encrypted messages are still not the default in Riot I think it makes very much sense to reduce the amount of data stolen if the worst case happens and the server is hacked. It is quite unnecessary when passwords etc. might be at risk even though you don't even use a server anymore.

Furthermore, even if Matrix doesn't want people to delete their account properly then IMHO extra care should be given that people are at the very least able to deactivate their account. Even that doesn't work. I have multiple accounts here at our own server where I only get "Failed to remove threepid". I initially created my own account on matrix.org but then realized I'd much prefer to setup our own homeserver. Now, I'm not able to even deactivate my account on matrix.org. I can login. But when I try deactivate it says: "Unknown error".

I think the whole situation is simply a mess and really a bad point of an otherwise quite excellent product.

[neilisfragile]

Well, I think this is a bit of a view with rose-tinted glasses on. Fact is, the e-mail address is considered to be "personal data" in regard to the GDPR. Currently, it is stored on the server for an indefinite amount of time with no way to ever remove it. This is IMHO a clear GDPR violation. You can publish policies all you want but that doesn't turn illegal stuff into legal stuff. I can write my own policy that I intent to drive consistently at 100 mph but that doesnt make it legal.

For clarity, deactivating an account does the following:-

• Removes all third party identifiers, including email
• Deletes all devices for the user
• Deletes all access tokens for the user
• Over writes the password hash

You can verify this for yourself here https://github.com/matrix-org/synapse/blob/master/synapse/handlers/deactivate_account.py#L69

As you might expect we sought specialist legal advice to ensure our policy and implementation are GDPR compliant.

However we would like to go further and treat the MXID as an opaque string, this proposal describes our current thinking. https://github.com/matrix-org/matrix-doc/issues/1228

What's more, I as an admin of an "other homeserver" would very much like to publish my own privacy policy stating that we delete the account completely.

As an open source project and you are free to modify as you see fit, though you would need to consider carefully how to manage previous interactions that the user participated in.

We are using the scheme @company.de for our email addresses. If a new coworker arrived with the same lastname as a previous one, we couldn't create a new account for him/her. With email accounts, for example, this is not a problem at all.

This paragraph seems orthogonal to your main point on data privacy - there is a just as strong an argument for avoiding the possibility of mistaken identity and many companies do not recycle email for exactly that reason.

That said the point will become moot once https://github.com/matrix-org/matrix-doc/issues/1228 is realised.

Furthermore, even if Matrix doesn't want people to delete their account properly then IMHO extra care should be given that people are at the very least able to deactivate their account....

This is a bug. It sounds like https://github.com/matrix-org/synapse/issues/5097 (Do you agree?). In any case vector-im/element-web#5097 will be fixed promptly.

[rgpublic]

@neilisfragile Thank you for your detailed response. Very interesting read. Yes, I agree vector-im/element-web#5097 sounds like my problem. I have this problem here on our own server as well as with my matrix.org account, so good to know this is being worked on.

One question though regarding what's deleted: Two people talk in a private chat with each other. Now, both leave the company and deactivate their account. We assume their conversation is not encrypted. Now, years later, someone hacks the home server and gains access to the data. Will the hacker have access to that conversation? What I gather from your response, I'd say yes. This is my main point: It's very unfortunate because the conversation can of course easily contain personally identifiable data etc.

What's currently badly missing IMHO is to have some options for users and/or admins to be able to reduce the attack surface in general. I would like, for example, to clear any messages older than xy days - or even clear all my messages from time to time. Slack, e.g., even has the ability to define a retention policy:

https://get.slack.help/hc/en-us/articles/203457187-Customize-message-and-file-retention-policies

I think this should be possible for our own home server. After all, I can simply wipe the server anyway and start from scratch. So why is it so difficult to actually remove stuff?

[neilisfragile]

Will the hacker have access to that conversation?

No they would not, because when the first user is deactivated they are removed from all rooms that they are a part, the conversation persists because the other user is still in the room and that conversation is as much theirs as the deactivated user.

When the second user is deactivated, then since there are now no other users who can see the messages the messages are deleted.

The relevant quote in the privacy statement is "Any messages or files that were only accessible by your account will be deleted from our servers within 30 days."

On your second point there is a big difference between a server having a generic retention period where all users of the server are aware of the policy and then separately, someone unilaterally removing half of a conversation where both parties can lay claim that they share the data. This is why we do not remove shared conversations under GDPR.

Generic data retention policies where all content older than X is deleted is something we'd like to do (though harder to see how this would work for federated rooms), and it's only really bandwidth that prevents us doing so.

[rgpublic]

Ah. This is extremely(!) useful information. Thanks a lot, @neilisfragile. Wish I had known all that earlier. I'm much more relaxed about the deactivation feature now. I think the (usability) problem is: The UI tells people that they can "deactivate" their account but there is no clear obvious information on what that means. I assumed that "deactivation" just means that. In particular, that you can just reactivate such an account later and you'll find everything (message history etc.) in a state where you left off. As it seems, this is not the case.

And I noticed the sentence "Any messages or files that were only accessible by your account..." but I didn't really understand what it meant as usually there are at least two persons who can access the messages. Now I understand it really means: "After all accounts having access to a specific message have been deactivated, the corresponding message itself is deleted from our servers within 30 days. Even if any of those accounts is reactivated later, the messages won't be available"

Just one more question: On our own synapse homeserver I use the CURL call:

https://localhost:8448/_matrix/client/r0/admin/deactivate/...

to deactivate the user. What needs to be done to ensure the deletion after 30 days really takes place? Is there are cron job that needs to be installed on the server or how does it work?

[t3chguy]

Even if any of those accounts is reactivated later, the messages won't be available

Deactivation is one-way in Matrix, in theory, a server admin could resurrect an account but this is on the whole unsupported

[neilisfragile]

@rgpublic I don't have a script to hand you, it's quite a rare case that the messages become unreadable, at least in the use cases I've seen. So the best way to do it is to redact the events and overwrite the message contents directly in the db. I actually have a todo, to create a script that safely deletes events, so that might be become useful for you, but it is a little way down the todo list so as of right know, redact/overwrite is the way to go.

[rgpublic]

@neilisfragile Hm, I wonder: How does it work right now on the matrix.org server? Is there an admin who really redacts individual messages in the DB when users leave (AKA "deactivate")? Or aren't the messages deleted at all and you wait until users really ask for their GDPR right to be forgotten and hope that it never happens?

Still, I think the current process is far too complicated for such a mainstream thing. Though I really appreciate the detailed information you've given. At least now I can make an informed decision. I guess, I will either wait until a decent method exists or I will just wipe the whole server from time to time...

[Torxed]

Will the hacker have access to that conversation?

No they would not, because when the first user is deactivated they are removed from all rooms that they are a part, the conversation persists because the other user is still in the room and that conversation is as much theirs as the deactivated user.

When the second user is deactivated, then since there are now no other users who can see the messages the messages are deleted.

The relevant quote in the privacy statement is "Any messages or files that were only accessible by your account will be deleted from our servers within 30 days."

I'm sorry, but this is not my experience in working with Riot/Synapse/Matrix.
How have you verified that messages are deleted? How have you verified that users get deleted from rooms? Have this changed since earlier versions of Riot/Synapse/Matrix?

To the best of my knowledge, messages will persist. Rooms will persist. And accounts will persist throughout the lifetime of the server. Mainly because everything is event based and there's no ordinary "message" table which people are used to when they think of older style ways of setting things up.

[neilisfragile]

@rgpublic well the tools aren't great today but they are the best I have. The case where a conversation is genuinely unreachable is rare which in part explains it. As ever PRs welcome.

@Torxed You are correct that a simple message table is the wrong way to think about matrix, and is why the way to remove a message is to redact and overwrite the content.

[wioxjk]

Why is this not solved yet?

[ordinarygulp]

How do you deactivate a user from another homeserver, using rooms on your homeserver?

[t3chguy]

@d2dyno, that doesn't make sense, Rooms are federated and therefore don't belong to a single homeserver (in most cases) thus a server admin can't control what users are in that room, they could ask room admins to ban that user, failing that they could disable their homeserver from participating in that room.

[rgpublic]

Okay. The matrix folks will probably not like this, but I don't care. It's just too much of a mess otherwise. We have employees returning to the company. Their account has been deactivated. Now I cannot register them again. I choose a different login and append a "2" but it's all to messy to support that. Users forget the "2", ask why they can't login. I create an account. I mistype. I cannot remove it again. Sigh. Crazy when you have to administrate a company-wide Matrix server properly.

For me it's now the decision to either abandon Matrix completely due to this. Which would be very sad because I like basically everything else. And I see not that this is fixed by the developers in a foreseeable future. So, I took matters into my own hands and just created a script to wipe the user from the database. I deactivated them before. This script WILL NOT remove the messages, unfortunately. Perhaps someone can extend it. I guarantee for nothing - make sure you backup everything. For me, it worked great, though. I could create a new account with the same username. I can use the new account to chat with people, participate in rooms. Everything seems to work. Wrong numbers of unread messages were shown which were easily fixed by logging out and logging in again. Now, when I do a "SELECT name FROM users;" on the database, I finally have a clean user list with no outdated stuff. Great! Here it is - hope it helps others in the same dire situation:

https://gist.github.com/rgpublic/afdb4fc42804b15c644cef3bd172717a

[richvdh]

The matrix folks will probably not like this

I don't dislike it. It looks like a reasonable workaround to the problem, subject to the conditions you mention.

[rubo77]

Great work!

Maybe instead of deleting the old user, a better workaround would be to rename the old or the wrong username to something like removed-user-xyz.

This way the chat history would not be corrupted

Thinking about this, came up to this idea: Rename disabled users federation wide vector-im/element-web#5949

[rubo77]

And @rgpublic, please add your script as a Pull Request here in the folder https://github.com/matrix-org/synapse/tree/master/contrib/scripts

[Torxed]

This is the same workaround I proposed like a year+ ago. This causes a lot of oddities, like "jump to the last read message" event keeps popping back up for some users, and not for others.

But this is the closest thing you'll get to a DELETE USER function.. Sadly, matrix is pretty broken fundamentally because of the focus of the front end the last year. (Cudos where cudos are due, the key exchange has gotten better)

[rubo77]

Related vector-im/element-web#5965 - option to delete users, that never said anything

[r3k2]

I try this with curl and keep getting no-support

{
    "id_server_unbind_result": "no-support"
}

grgrgr not happy with having to do this with a curl request

[ordinarygulp]

Just had the same problem as @ReK2Fernandez mentioned above

[richvdh]

what makes you think that is a problem? it's expected behaviour. When the user is deleted, synapse will attempt to contact the identity server to unbind any third-party identifiers that were registered against the account. It's telling you it was unable to contact the identity server.

[ganzgustav22]

Have you considered, that there are admins who simply want to delete a user? Is it documented somewhere now?

[ptman]

@ganzgustav22 I'm not sure, but I'm guessing it's quite impossible to delete a user. The database doesn't seem to use foreign keys, but again, I'm guessing that events refer to users. E.g. user a wrote "foo" in room b. Removing the events also isn't an option as that could break federation. So users can only be disabled, not deleted.

[ganzgustav22]

Thanks for the info. How can a user be disabled then?

[ptman]

@ganzgustav22 like @ara4n said earlier in this thread: https://github.com/matrix-org/synapse/issues/1707#issuecomment-293381066

[t3chguy]

as documented here: https://github.com/matrix-org/synapse/blob/master/docs/admin_api/user_admin_api.rst#deactivate-account

[e-lisa]

The method described above of deactivating a user is pointless when user's can just make another account with a disposable email address. There needs to be a way to manage abusive users and SPAM users.

Because Synapse has no anti-abuse features we had to shut our server down until further notice. We simply cannot defend ourselves from malicious users, and the recommend method does very little to help.

Using the method above at bests "annoys an attacker until they can write a script", or if they are motivated they just make a new account with impunity. Let me say this again, Synapse currently has no way to defend agaisnt malicious users. Running this software is extremely risky and leaves server administrators with very little ability to moderate their network when people post illegal content. All the Admin's can do is watch in horror while malicious user's ban-evade and post SPAM everywhere. (This is why we had to shut our server down!)

Here are some related issues:

• https://github.com/matrix-org/synapse/issues/7731
• https://github.com/vector-im/element-meta/issues/1237
• https://github.com/vector-im/element-web/issues/14130