[Request] Allow account deletion

[MoritzMaxeiner]

I've looked over the matrix spec and unfortunately /account/deactivate only requires for any future login to become impossible. Synapse fulfils the spec, but does not actually delete the account, which a) leaves the user's data on the server after the user has expressed the intention to never use this account again b) leaves the user id taken (i.e. future registration attempts on it fail with "M_USER_IN_USE")

Either /account/deactivate should completely wipe any data belonging to that account from the homeserver, or there should be a second endpoint /account/delete that does this.

Keeping account data from people who specifically want to cease using one's service seems shady at best in terms of privacy policy and technically impractical at worst, since it accumulates data that a) isn't required for the continued function of the service b) takes up increasing storage space for no apparent benefit to the service

[rubo77]

If a very active user would be deleted this way you suggest, that would destroy conversations completely.

imagine this user chatted a lot with others in hundreds of rooms, others took a lot of effort to answer questions of this user,....

all those work of others would be in vain. that wouldn't be fair.

Also this would violate the Idea of the Matrix: What is said can't be unsaid.

An exception would be rooms, where everyone agrees, that they are moderated and messages are not persistent all the time.

The only possibility I can imagine to free a username for a new registration would be to remap the old posts to a new user with the same name, so the messages are unlocked from the user, that wants to be deleted.

Only a user that has never said anything could be deleted completely!

[MoritzMaxeiner]

If a very active user would be deleted this way you suggest, that would destroy conversations completely.

AFAICT it would only destroy the history of that conversation, i.e. a new client from a recipient on the same homeserver cannot sync it anymore.

imagine this user chatted a lot with others in hundreds of rooms, others took a lot of effort to answer questions of this user,....

Then the history of that conversation is gone from the user's homeserver just as his choice implied.

all those work of others would be in vain. that wouldn't be fair.

Fair to whom? It certainly is not fair to the user clearly stating that he/she wishes not to use a server anymore to keep the data the user owns around. In countries with strict privacy laws and with a history of many privacy related court cases being decided in the user's favour operating a server of this nature is grey at best in terms of legal safety, derelict at worst.

Also this would violate the Idea of the Matrix: What is said can't be unsaid.

Where did you get this idea from? It certainly is not expressed in the FAQ[1] and the spec only implies it by being vague about what /account/deactivate/ means. If this is the mission statement of Matrix, then this not being visibly stated would be another issue altogether, to be discussed separately.

[1] http://matrix.org/docs/guides/faq.html

An exception would be rooms, where everyone agrees, that they are moderated and messages are not persistent all the time.

If a user wants to cease using a service, it has to be possible for his/her usage data to be deleted by him/her.

The only possibility I can imagine to free a username for a new registration would be to remap the old posts to a new user with the same name, so the messages are unlocked from the user, that wants to be deleted.

Or just do the thing the user explicitly asked you to: Delete those posts.

Only a user that has never said anything could be deleted completely!

Only from other homeservers', since AFAICT homeserver A cannot tell another homeserver B that user C has unregistered from A and events by him/her should also be deleted from B. That's the only exception I'd consider.

[rubo77]

You can redact all your messages already one by one before you delete your account.

Those redactions are already federated to other servers, so you can write a script that does this for you already..

But you can never be sure, that other servers obey to the redact command though.

[MoritzMaxeiner]

You can redact all your messages already one by one before you delete your account. Also this would violate the Idea of the Matrix: What is said can't be unsaid.

These two seem to contradict each other. Either what is said can't be unsaid, or you can delete your messages. Regardless, there is currently no way to delete your account, only to deactivate it.

Those redactions are already federated to other servers, so you can write a script that does this for you already..

Good to know, as the Client-Server spec does not fully specify how redacted events are propagated. But this does not deal with account deletion.

But you can never be sure, that other servers obey to the redact command though.

Of course, you can never be certain a blackbox third party claiming to implement a spec actually fully comply with it. But this is a red herring, diverting from the issue of a user not being able to delete his or her account in this implementation.

[KopfKrieg]

@rubo77 In some countries law demands that you're able to completely remove your account.

Besides that, if I want to stop using a service, I always make sure that all of my data will be removed. Here, this is not possbile. I think this is a major flaw in the design specification.

[ara4n]

This is like requesting that you can delete your email account and somehow magically delete every email you ever sent at the same time. It's a reasonable request for a centralised service like facebook, but Matrix is not centralised. Instead, the best we can offer for now is deactivating accounts, and in future purging history from your local homeserver but this really doesn't achieve much.

[MoritzMaxeiner]

@ara4n No, this is like requesting that you can delete your email account and all the data pertaining to that account from the service provider's servers.

[ara4n]

@Calrama except that concept does not exist on Matrix, because the concept of "all the data pertaining to that account on your service provider" is not well-defined, given the whole point of Matrix is that your messages are replicated equally over all participating servers. It's not like deleting your IMAP spool from a service provider, it would be like deleting some combination of global IMAP+SMTP history both for you & everyone you've ever spoken to.

Here are the possible "solutions" here:

1. Let people irreversibly deactivate their account; removing their credentials to ever use it again. This is what we provide today.

2. Let people delete the existence of their user account off the account/profile tables on their local server (ignoring history). This opens up the risk that someone might register the same ID in future, allowing potential spoofing attacks and might even pave the way to security vulnerabilities where they could try to synchronise in old history for the old user. Fixing this would mean switching to using a different internal format for Matrix IDs (e.g. public key fingerprints), which is a possibility in the medium-long term but for now option 1 provides most of the same benefits.

3. Let people delete "their history" from their local server as well as their account details. In theory one could go and delete every message on the local server that the user ever sent; but any conversations which spanned other servers would be preserved on the remote servers... and the conversation would be eventually resynchronised from the other servers. So it would achieve nothing, other than a) breaking conversation history for everyone you spoke to in local-only rooms, inexplicably penalising them b) waste traffic for everyone else.

4. Let people send message redactions for every single message they ever sent. These are advisory deletions which let users request other servers delete particularly sensitive content, intended for accidentally posted passwords and photos etc. Doing this in bulk however would be incredibly obnoxious - it's the equivalent of issuing a 'email recall' for every email you ever sent. It would destroy the history of every conversation you ever had with anyone, rendering the shared view of those conversations useless. We take the view that if you talk to someone on Matrix, then the other people in your room equally own the copy of your data. Just as if I send an email to someone, the recipient has equal rights to store a copy of that email as the sender does. Finally, redactions are advisory - there is no way to enforce that servers uphold them, and so are not useful for robustly enforcing data ownership policies. Also, you may not even be a member of the room that you want to redact your messages from any more, making the hypothetical feature even less useful. We have no plans to support mass-redaction.

5. We could conceivably implement a 'bulk redact' feature which is a single message that tells servers to destroy all data that they ever saw from a given account. This suffers the same social side-effects as option 4, and could also be an incredibly dangerous feature - imagine if it was trivial for an attacker to temporarily get access to your account and then irreversibly attempt to annihilate everything that account ever emitted into Matrix.

So, this is why right now the only option supported is number 1, and possibly in future number 2. Hopefully this also explains more clearly why options 3, 4 and 5 would cause more harm than they solve.

In the end, if you want to communicate using a system which lets you destroy all every message you've ever sent, or doesn't keep that history in the first place, I'd suggest using something other than Matrix.

6. Final thought: one other solution here might be to support time-based retention schemes per rooms - i.e. configure a room to request all servers to delete content older than N days, or even after it's been read by all participants in the room. This would be advisory, but it's a feature many enterprise contexts ask for. Privacy-focused users could then choose to configure their clients to only support communication in participate in such rooms, and thus be sure that their history will magically disappear over time - and critically the people they're talking to will know and expect those semantics to occur. Perhaps this might be a sufficient solution to the folks participating in this bug?

[KopfKrieg]

This is like requesting that you can delete your email account and somehow magically delete every email you ever sent at the same time.

No. The only thing I request is that I can delete my account (e.g.: Make a login with my credentials impossible). Nowhere I wrote that I want to magically delete every message ever written by me.

This is pretty much number 1 of the solutions you posted:

Let people irreversibly deactivate their account; removing their credentials to ever use it again. This is what we provide today.

I don't know what else in stored in a user account besides username and password, but if this could be enhanced to delete all the other stored data too (e.g. linked phone number, mail addresses, in short: every personal information) it would be nearly perfect for me.

[MoritzMaxeiner]

@ara4n Thanks for explaining your position in depth, this makes it easier to refer people to.

except that concept does not exist on Matrix, because the concept of "all the data pertaining to that account on your service provider" is not well-defined, given the whole point of Matrix is that your messages are replicated equally over all participating servers.

I am aware of that, but that does not change what is required in terms of privacy laws.

In the end, if you want to communicate using a system which lets you destroy all every message you've ever sent, or doesn't keep that history in the first place, I'd suggest using something other than Matrix.

I am using something different, but not for that reason. The reason is privacy laws, as I indicated earlier.

[KopfKrieg]

@ara4n I forgot to ask, but:

Let people irreversibly deactivate their account; removing their credentials to ever use it again. This is what we provide today.

Is this only possible via the api or is this already possible via the webinterface or apps like riot? I found nowhere the option to do this.

[ara4n]

@KopfKrieg it depends on the client. on Riot/Web it's the big red 'deactivate my account' button at the very bottom of the User Settings screen:

[KopfKrieg]

Ah, perfect, thanks.

[ara4n]

except that concept does not exist on Matrix, because the concept of "all the data pertaining to that account on your service provider" is not well-defined, given the whole point of Matrix is that your messages are replicated equally over all participating servers.

I am aware of that, but that does not change what is required in terms of privacy laws.

@calrama IANAL, but as I understand it: typical data protection law requires a service provider to delete personal user data if requested by that user (and to not hold it beyond a given time threshold). In practice, we do not consider messages that a user has sent to other users as being personal user data - just as an email service provider would not consider emails sent to another user to be the exclusive personal property of the sender. Instead, these messages are the shared property of those with whom they have been shared.

I completely agree that actual personal data (as per @KopfKrieg's example) should be deletable - and we do as much of this as we can currently in solution 1, with solution 2 filling in the remaining gaps in future.

I might be able to help better on this if you explained whether any of my proposed solutions would be satisfactory for your requirements - i.e. are you petitioning for solution 2? or 5? or 6?

[MoritzMaxeiner]

@ara4n Messages a user has sent to other users may still be considered personal data with regards to you as a service provider (regardless of what the recipients do with their copy); as is the user's account name. I was petioning for exactly what I wrote in the opening post: All (personal) data pertaining to that user on that specific homeserver to be deleted (permanently); that includes the account name and all messages sent (on that specific homeserver).

With regards to your proposed solutions, AFAICT: Solution 1 keeps the account name and history around (-> no) Solution 2 keeps the history around (-> no) Solution 3-5 are all implementation detail with regards to the goal of the homeserver the user deleted the account on not keeping the history around, so I cannot comment on which one to pick Solution 6 keeps the account name and potentionally some history around (-> no)

As long as it is not possible for users to completely wipe a homeserver of all data that a German court may decide can be considered personal (data), I cannot deploy one. If you think - and from your explanations I think that to be probable - that that is not a goal for Matrix/Synapse, then you can simply close this as Invalid.

[ara4n]

Okay, I am definitely not qualified to say what a German court might or might not consider personal data. My intuition is that they would not consider email body+headers sent from user A to user B to be personal to user A, if stored on user B's account (whether user B is local or remote to that mailserver). And so the same logic would apply to Matrix.

I'll keep the bug open though to track solution 2, and in case someone with the necessary legal expertise wants to contribute an opinion :)

[pafcu]

@ara4n It is not a question of how something is sent, but what is sent. You could absolutely argue that an email body containing PII, e.g. my real address should be deleted on request, just as if it were stored in any other form on a server, whether it is my own or a remote server.

[akhilman]

I hit this problem. I have my account deactivated and made new one. For now user search returns both my accounts regardless is it active. Also my deactivated account still visible in all channels and even takes nick name in IRC.

So for me account deactivation as it now is just «forget password». When I click «deactivate» I thought matrix at least will exit from all rooms, and stop IRC bridging and free nick name for future registration. But it doesn't.

By the way can someone help me to stop IRC bridge from taking my nick name?

[neverfox]

I agree with @ara4n that the idea that someone "owns" what they voluntarily say or type to others is nonsense on slits. That said, nothing stops governments from enacting laws around nonsense, so those running homeservers in those states will have to do what they feel is necessary to avoid run-ins with the relevant authorities. Only you can assess your risk tolerance.

That said, what @akhilman has brought up disturbs me, if true, because I just hate it when my initial noob screwing around results in my forever and always seeing evidence of it. I plan on running my own homeserver soon and would love it if I could eventually stop my @username:matrix.org account (which I may deactivate, as I never really used it) from showing up where it doesn't make sense. If I understand it correctly, it seems to fall somewhere in between 1 and 2. A deactivated account shouldn't erase conversational history for that account, or allow the potential for spoofing, but it doesn't make much sense from a UX perspective for that account to appear in the present context as an active user available for chat or invitation etc. It's not clear to me why one would have to go so far as to change the internal ID system to accomplish this. Isn't it enough to mark the ID as locked and use that fact when deciding what to offer users in various contexts?

[Half-Shot]

Seems fair to attempt to leave all rooms upon deactivation.

[akhilman]

Today I have two zombie accounts in matrix-hq room, First one is my deactivated account, second one is from dead local server. When matrix become popular there will be thousands of dead accounts in rooms. I propose to add a kind of garbage collector to kick abandoned accounts from rooms after year timeout, or even to completely remove all data.

[Half-Shot]

Had some more thoughts on it. Would be nice to finally have extensive profiles so we can mark accounts as disabled. It's a feature slack does and I've found it incredibly useful to determine if people in the company are still employed, for instance.

[rubo77]

We Could rename the alias of disabled usernames to "old alias (disabled)" to prevent others from inviting, or sending messages to those deactivated accounts.

[HybridEidolon]

Very interested in this kind of feature. I am not currently a Matrix user but it is very appealing, but the inability to at least obfuscate an deactivated account is unfortunate from a privacy perspective. I can think of a number of scenarios where someone might want to make it at least a little more difficult to be directly identified or reached from a deactivated account, especially victims of organized harassment.

It seems like, from my reading and understanding of the spec, a good way to handle this would be:

1. a deactivation state for profile that clients and servers can both query, like the current displayname and avatar_url keys. it seems the s2s protocol already specifies some support for this, but the c2s protocol only theoretically permits non-standard keys from the full profile endpoint. IMO this key should be standardized in the protocol, but it doesn't have to be.
2. delinking 3rd party identifiers on deactivation. Seems like identity API doesn't allow for anything like this, but it at least only allows 3pid -> matrix id querying. This may be useful for someone simply making a new matrix account on another homeserver wanting to re-associate the ID, although that might already be implied during the association session. If re-association can be done in identity, then it might suffice for clients to just inform users that deactivation does not unlink 3pids and they can relink to a dummy account if necessary.
3. automatically remove deactivated accounts from rooms at the homeserver level (which is simple enough)
4. finally, and probably least important, some way of letting the homeserver tell application services that an account is deactivated. This is probably covered enough by other standard events/room events/state events that e.g. the irc service would simply disconnect the irc client when the account leaves the bridge room. In fact, maybe deactivation should be covered in presence rather than a profile key?

A given user can redact their own messages in batch, that wouldn't necessarily be a requirement of a homeserver implementation and there are plenty of examples for e.g. Twitter for doing so. I have used one! They're very powerful.

From a homeserver implementation standpoint, at least dropping a deactivated account from all rooms doesn't require anything more from the protocols. This would resolve the application service problem of leaving zombie sessions in rooms on bridged services like IRC.

It would also aid moderators of rooms to be able to see that deactivation state too, if they want to remove deactivated accounts by hand, for other homeservers that don't automatically remove them.

[ara4n]

We're working on this right now for GDPR compliance (including BDSG compliance for our German friends). We're looking into supporting a fairly extreme solution, although the scope might get dialled back based on the legal advice we receive. The approach we're considering for right-to-erasure is:

• Consider messages sent in public rooms to be the property of the sender, and let them be mega-redacted (including all their metadata - particularly the user ID) if that user requests their account to be deleted - a bit like a mailing list archive.
• Consider messages sent in private rooms to be the shared property of the participants (like in email), and not subject to erasure.
• When accounts are deleted, we clean up their account properly:
  • the user autoparts all the rooms they were in (fixing the zombie problem)
  • is removed from user directories.
  • all 3pids are unbound
• Account deletions require a 2FA confirmation (assuming the user has 2FA set up) and are revokable for 30 days before they are actioned, letting users change their mind (and to provide a safety net for abuse of the feature.

EDIT May 8th 2018: our position has slightly changed on the first bullet point, as we couldn't find a robust and intuitive definition of 'public room' - see the 5th paragraph in the 'Right to erasure' section at https://matrix.org/blog/2018/05/08/gdpr-compliance-in-matrix. So rather than redacting, we're instead withholding GDPR-erased messages from ever being shared with users who didn't receive them in the first place

Much of this is aligned with the feedback above from @HybridEidolon and others.

Thoughts would be welcome on whether this covers everyone's use cases!

[turt2live]

Minor request for the implementation: A way for other users/homeservers/something to positively identify that the account was deleted and not just a redaction spree or other event. The primary use case is for bots (namely voyager) to purge any relevant data they may have. Other use cases may include bridges trying to purge data in 3rd party networks, etc.

[rubo77]

• mega-redaction of all messages in public rooms must be optional.
• in private rooms, where a deleted users messages where kept although the user decided to react all messages in public rooms must be handled correctly later if the remaining user in that room decides to make the private room public

[ilu33]

I'm working on this for forum software and since "mega-redaction" doesn't make much sense in a forum the solution we are probably going to choose is renaming the account before deletion to something like "anonymous001" and then stripping every personal data from that account. (User names in quotes are still an unsolved problem.) The goal would be to merge all those anonymous accounts into one. We hope that this will remove any personal aspect of the data and we think that prior user consent to this procedure might stand a chance under GDPR since a forum has some kind of publishing nature and purpose - which a messenger service like matrix has not. So a consent clause of that kind in Matrix might be considered "surprising" (and thus invalid) for a matrix user.

In matrix the best thing would be to give the user options upon deletion, but I think one of those options has to be mega-redaction. Option here means at the discretion of the user, not of the server operator.

[ilu33]

Please also remember that federation might be considered as a case of "joint controllers" (Art. 26 GDPR). I can see strong arguments for that opinion at least in our jurisdiction (and in some others in Europe). That would mean that deletion has to be carried out across federation. All home server operators would have to join an arrangement that specifies how the GDPR responsibilities are carried out and who is responsible for what. This would have to include bots like voyager (if anybody really wants to federate with them).

Please also notice Art 26 no 3 GDPR: "Irrespective of the terms of the arrangement referred to in paragraph 1, the data subject may exercise his or her rights under this Regulation in respect of and against each of the controllers." This poses a considerable risk for every home server operator who participates in federation. Any GDPR relevant actions can't be left to the discretion of individual server operators. There has to be a technical solution - which preferably plays it save - everybody can rely on.

Are your lawyers aware of that ara4n ?

[ara4n]

(Here's a heads up of where we're at right now: https://matrix.org/blog/2018/05/08/gdpr-compliance-in-matrix/)

[ilu33]

As somebody concerned with server operation I'd really prefered if you played it safe as much as technically possible. Playing it save means: Leave the decision to the user. If the user wants to mega-redact, give her/him the means to do so. Yes, that would mean that context gets lost - but keeping context intact is not protected by any law and certainly not with fines. Yes, that's bad for other users but if the leaving user decides to delete, then s/he's to blame.

You could easily solve the context problem by giving users a tool to save conversations locally. Local copies are not under the responsibility of server operators, so - not our business. And if people forget to save and lose context - not our business as well. Both only seen from a legal point of view, that's what we are discussing here. Edit: If you choose a common data format for the local copy you've covered the data export requirement at the same time.

Matrix is currently advertised as a messenger and there's a real risk that juridiction will consider it as that. Good luck trying to convince a judge that Matrix is just email. This is wishful thinking. They will compare to other messengers and whatever they come up with for messengers will hit server operators.

A lot of our court decisions in consumer law work around the concept of "reasonable user expectations". Many judges consider themselves being the prototype of a reasonable user. So what will a judge say while looking at riot on android: is that like Outlook or like Whatsapp?

Please chose the most radical GDPR compliance possible to mitigate liability risks for server operators, otherwise operators might decide they have to shut down to avoid risks.

[26000]

@ilu33

Many judges consider themselves being the prototype of a reasonable user. So what will a judge say while looking at riot on android: is that like Outlook or like Whatsapp?

But the article reads that WhatsApp and other messengers follow the same approach:

We’re opting to follow the email model, where the act of sending an event (i.e. message) into a room shares a copy of that message to everyone who is currently in that room. This means that in the privacy policy (see Consent below) users will have to consent to agreeing that a copy of their messages will be transferred to whoever they are addressing. This is also the model followed by IM systems such as WhatsApp, Twitter DMs or (almost) Facebook Messenger.

So I think we are safe to say we're email!

[neilisfragile]

@ilu33

Please chose the most radical GDPR compliance possible to mitigate liability risks for server operators, otherwise operators might decide they have to shut down to avoid risks.

Our approach, as referenced by @ara4n above is grounded in on-going legal advice. We are certainly not looking to place undue risk onto homeserver owners, we are ourselves responsible for matrix.org not to mention pretty much the whole core team running their own personal servers. The solution must unquestionably be GDPR compliant.

We use e-mail as example because of the similarities as far as federation is concerned, but as @26000 references many other messengers have arrived at the same conclusion, and that gives us further confidence in our reading of the legislation.

[rubo77]

That static private part is a good point. I created an issue for that https://github.com/matrix-org/synapse/issues/3210

[26000]

I personally dislike the possibility of data being suddenly erased, destroying context and all. Something you said can't be unsaid. But the option to dissociate your identity from your messages seems nice. And to prevent further spread of messages — this seems much more fair.

I value privacy much, some even say I'm paranoid. But regarding Matrix, I like the way it is now. Because it's federated, and if you can't rely on each node of the network to erase everything completely. You give a user false sense of privacy saying that their data is destroyed. The principle is basically that if you post something in the public internets, you lose your control over it. You can make your data difficult to find, even nearly impossible. But the chances are that a copy remains somewhere.

The think I find nice is the way how it is done in IRC. It's just like a real-life conversation: you say something, those who are around you hear it, and you can be sure only they do (as in IRC you see everyone who is online) (let's not think about hidden microphones and so for now). Once something is said, it gets recorded in people's memory, not in a centralized database (like the way every IRC client writes logs, but no IRC server does that). And even if it's recorded, nobody can prove you said something — they can retell everything (or lie that you said something), and it depends on their interlocutors if they do believe them or not. This feels so natural and logical.

But, the modern requirements for a messenger are much more than that. We need history sometimes, and IRC is unusable as a replacement for SMS/mail/etc, so we have Matrix now. If IRC is real-life conversations, then Matrix is paper mail. Matrix is nice, and the way it deals with privacy is nice too, even better with those enhancements in development. The only thing I think could be improved is those static states for private rooms.

This all is my opinion, I'd like Matrix developers to consider it, but if the majority wants to follow the other way, let it be so.

[neilisfragile]

to try and limit fragmentation:-

A response to @gerg5c42g542g2c54g52c comment from @ara4n is here https://matrix.to/#/!boLskYiwabbCQNNhlK:sw1v.org/$15260441781010915AnGmT:matrix.org

" whilst you're right that the GDPR changes we're making doesn't let you delete data/metadata (unless all participants GDPR-erase themselves), my expectation is that we'll (at last!) implement retention periods for rooms so when you speak in a room you can see what the retention policy is after which data will get vaped.

metadata can also be vaped if you gdpr-erase the account (thanks to removing the mxid mapping).

and i think everyone agrees that retention policies would be a nice feature, and i'm sure it will happen. but for better or worse it's orthogonal to GDPR right-to-erasure stuff."

[natrius]

I'm adding DSGVO here just for the search for the german talking guys. I am interested because i am thinking about suggesting matrix/synapse to my company, while someone else is suggesting Slack.

[ecsgh]

I'm adding DSGVO here just for the search for the german talking guys. I am interested because i am thinking about suggesting matrix/synapse to my company, while someone else is suggesting Slack.

I have to do with dsgvo in my company. So matrix is not allowed to use in germany. A user has the right in dsgvo to become all, and i mean all, data about himself when he want it. And the other rights is, that when he want delete his/her account, all data about must delete about he/her.

[KopfKrieg]

So matrix is not allowed to use in germany.

Is that really only a problem in Germany? I thought the GDPR applies to the whole European Union (including the right to request, alter and delete all data about your own account?)?

[rubo77]

I have to do with dsgvo in my company. So matrix is not allowed to use in germany. A user has the right in dsgvo to become all, and i mean all, data about himself when he want it. And the other rights is, that when he want delete his/her account, all data about must delete about he/her.

@ecxgh then email would not be allowed in germany either, you cannot magically delete your data, which is stored in others inboxes!

please read the comments above first, starting at https://github.com/matrix-org/synapse/issues/1941#issuecomment-306051123

[ecsgh]

So matrix is not allowed to use in germany.

Is that really only a problem in Germany? I thought the GDPR applies to the whole European Union (including the right to request, alter and delete all data about your own account?)?

No. Not only germany. It's whole EU.

[ecsgh]

I have to do with dsgvo in my company. So matrix is not allowed to use in germany. A user has the right in dsgvo to become all, and i mean all, data about himself when he want it. And the other rights is, that when he want delete his/her account, all data about must delete about he/her.

@ecxgh then email would not be allowed in germany either, you cannot magically delete your data, which is stored in others inboxes! I see this as an letter. And an letter rich selected recipient. Not the whole world.

And I only write what DSGVO say. And dsgvo says only in short words:

• Data reduction and data economy.
• Right to become all your data.
• Right to delete all your data.

[ara4n]

in Matrix, when you send someone your data by communicating in a room, you share ownership of it with them, much like email.. We do not believe this is counter to gdpr or dsgvo (which were not built with decentralised systems in mind, so we have applied commonsense ourselves).

In future it may be possible to also have a “megaredact” feature which lets users send out kill message to request servers delete everything a user ever said, at the expense of vandalising all the conversations they were ever in, but we do not believe it is a legal requirement.

Instead, we are working on MSC1228 to let users remove their PII without destroying conversation history.

[richvdh]

I think this is a duplicate of #1707.

[Goosegit11]

what about Github's way of doing it? https://github.com/ghost

so the information is still there, which can be a problem if the user still wants to delete it, for example:

1. he changed his mind and does not want people to see his old opinions
2. he sent his nudes and decided to delete them to avoid leaking
3. etc

but now his messages have nothing to do with his account. in this way his messages will be mixed with messages of all other deleted accounts, which is much better than what we have now.

and of course basic stuff like:

• Free his username and email to register again, and if someone registers under his username/email he will get completely new and empty account.

• delete all information about his account from the database - username, email, password, everything.

about impersonation: you can see account's registration date to verify identity

[Goosegit11]

also what about Telegram's way of doing it? both users have ability to completely erase history. I don't know what really happens on Telegram's servers, MTProto is closed-source. Telegram probably said something about it, but I didn't researched it. but let's focus on the deleting. this way info is shared between both participants and both have right to delete everything. in group chats you can't delete all of your messages (that's actually sad and really annoying for me), only admin of the group can delete them all. and admin of the group can erase whole history of the chat completely too.