Mastodon: Delete account function?

[ghost]

Where is that function or when comes it?

[Gargron]

What would be the implications of deleting an account from the technical perspective?

It would be problematic, for example, if someone could immediately register a new account with the same username. Remote instances that may not be aware of the account's prior deletion would keep following the new, now impersonating account.

So the username needs to stick around after deletion. Then every status by the user would be deleted, every deletion would need to be federated which might take a while (imagine deleting 40,000 statuses - you'd need to send the updated "deleted" status for every remote follower x 40,000).

So this solution would be a soft delete then - as much information as possible is removed but basic structure and some pointers must be retained. So perhaps we could delete avatar, display name, bio, delete all statuses/media, unfollow everyone the account has been following, force all local users to unfollow it (cannot force remote accounts to unfollow though). Perhaps disable login on the account.

That's quite a big task, isn't it

[ghost]

For me as user it's not very interesting if this is a big task. I tested out your project, wanted to see how it is. It's not the great one and now I can't delete my data. I do not want you to keep data from me.

[joshtriplett]

@Gargron Ideally, OStatus would include a "delete" status, sendable to a server, which tells that server to (optionally, depending on server policy) mass-delete or mark-as-deleted any status from that user, so that you only need to send one update rather than one per status.

[hikari-no-yume]

It would be problematic, for example, if someone could immediately register a new account with the same username.

Twitter lets this happen, but in Twitter's case handles are not the primary key (that is, Twitter knows that a new user with the same handle is not the same as the old user), so it's not too bad. What does GNU Social use as the primary key? If it's the handle, then I see the problem.

[Shadician]

There should definitely be a way to delete your account, from a data privacy perspective. I think it may even be a legal requirement in some countries to be able to leave a service.

Most commercial services (Facebook, Twitter) seem to offer the option to deactivate your account, which hides all your content and gives you the option to one day return. Some then let you go further and remove your data from the platform permanently if you wish.

For my part I opened an account on one instance before realising it was very localised to a country whose language I don't speak, then found there was no way to export to a different instance. I had to open a second account on the new instance, only to then find there is no way to delete my old account - which people can still find and follow. Very confusing.

I also imagine many like the idea of an open source platform alternative to twitter, or other social platforms, that will give them full control over their own data. Right now we don't have that.

[mvdwoord]

Same here, as a user I would like to be able to have my account deleted.

[ajanvier]

It'll definitely be needed in the future, in France it's an obligation for a service to provide its users with a way to access, modify and oppose any information stored on them (see Loi Informatique et Libertés du 6 janvier 1978).

Maybe you can just deactivate the account for some period of time when the user asked to delete it so that the deletion has the time to propagate to the different instances.

But as @TazeTSchnitzel commented, if the users are identified by their handle as the primary key, here resides the main problem...

[planet4589]

Absolutely needed. I'm not going to be using mastodon until I know there's some kind of delete account that I'll be able to use if needed. It's basic.

[mackaaij]

I was invited for mastodon.network but then noticed I already created an account on mastodon.social last year. Same email address. So I'd like to delete my latest account (from mastodon.network) - assuming "federated timeline" means both Mastodons end up in the same "world".

[kaishin]

I agree with the general sentiment that this should be bumped up in priority. A lot of users are using this to avoid lock-in, so it's quite natural to expect a way to wipe your data from an instance you don't control if you decide to move to another one.

[Shadician]

Agree 100% about users coming here to escape lock-in. An option to export our data and then hide or permanently delete from Mastodon would be ideal. It would also be great if you could then choose to import it to a new instance if you wanted, or just keep it offline for your own use/delete it forever.

[Oreolek]

Make the account locked; if the user doesn't return in 30 days, all the toots are deleted and the username becomes available again.

[Spunkie]

Just a note on the actual propagation of a delete request across multiple instances. You will inevitably run into people who will modify their instances to ignore/deny requests to delete data. The motivations for this kinda thing are far ranging, see politwoops/reddit undelete/sleazy advertiser/data scientist/troll/internet archivist/etc. Whatever the reason though the solution proposed should take this in consideration.

You also may have to deal with a similar issue in the future when very old instances suddenly come online after being down for months/years.

[joshtriplett]

@Spunkie There's absolutely nothing that can be done about that. In a federated system, all you can do is ask.

[Spunkie]

@joshtriplett I agree, that's why I wanted to chimed in. People are comparing this to how delete works in centralized services like twitter.

Personally I think account deletions should be handled internally as a migration to a global "deleted-account" account or into individual "deleted-account-101xxx" accounts. The original account username/email/bio/avatar/whatnot will be deleted but the actual toots and history will remain somewhat intact, and then you attempt to propagate that. At least on instances the account was not originally created on that is. I would think far less people/instances would object to this type of migration/anonymizing request than a simple request to delete all history.

To further the mastodon is like email analogy. It would be great and all if gmail/hotmail/yahoo got together and planned a standard that let their users unsend(delete) emails between their services if it's still marked unread. But even if that happened, every other email provider would be under no obligation to respect those request for deletion.

[kaishin]

To further the mastodon is like email analogy. It would be great and all if gmail/hotmail/yahoo got together and planned a standard that let their users unsend(delete) emails between their services if it's still marked unread.

You can still delete an email address/account though any email provider. The emails will stay, but that address is going to bounce.

Maybe people in this thread mean different things when they talk about deletion, hence the confusion.
I would like to have a way to "deactivate" an account in an instance, as I way to let others know that I am no longer interested in being mentioned using that handle/instance. The same way I can just remove my email address from an email provider or server and senders will know when they try to reach me using that address.

The questions of whether the handle should be freed afterwards or not, whether toots will be kept or deleted are beyond my understanding of how the system actually works behind the scenes.

Maybe if this issue could be split into 2 or 3 covering each of these aspects it'd make it better to discuss each separately.

[jimdogx]

I don't see what the big deal is. I had a Twitter account (@JimDog) and I deleted it back in 2012 in a fit of rage (long story). It was then picked up by some other guy. I regret giving up the name but it's too late now. If you go to Twitter and search for posts by @JimDog and scroll down, you'll see that posts on Aug 2nd 2012 and prior are all mostly about running. Those are all me... everything since Dec 2012 is the new @JimDog. Nothing I can do about it. So why wouldn't this be the same?

[planet4589]

I completely agree. The main technical things I think are to be able to (1)
disassociate yourself from the handle (2) delete personal profile data
associated with it (3) have the ability for you (or someone else) to reuse
that handle on another mastodon instance. I don't think it's plausible to
require that your previous toots become inaccessible - in the (in my view
not very accurate) email metaphor, I can't force my recipients to delete
all the emails I sent them.

On 7 April 2017 at 10:58, jimdogx [e-mail] wrote:

I don't see what the big deal is. I had a Twitter account (@JimDog
https://github.com/JimDog) and I deleted it back in 2012 in a fit of
rage (long story). It was then picked up by some other guy. I regret giving
up the name but it's too late now. If you go to Twitter and search for
posts by @JimDog https://github.com/JimDog and scroll down, you'll see
that posts on Aug 2nd 2012 and prior are all mostly about running. Those
are all me... everything since Dec 2012 is the new @JimDog
https://github.com/JimDog. Nothing I can do about it. So why wouldn't
this be the same?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/tootsuite/mastodon/issues/109#issuecomment-292560179,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AZsofHRdyydIwMi_SOMUj6mKvwFgwoDXks5rtk8ggaJpZM4Kfrqg
.

[jeanbaptisteb]

@planet4589 : the email comparison isn't good, because emails are private. A better and accurate comparison is with content you published on a website.

You definitively can ask the owner of a website to delete the content you published on her website, because you own the copyright of your toots.

Unless you agreed to specific terms of service or published your toots under a free license, the owner has to delete your content, or you can sue them. It may be unpractical and excessive to go that far, yet it's important for instance providers to note that the law is by default on the side of the person who wants to leave the service.

Users should be provided with an option to require automatically all the federated instances to delete their content, because doing it manually is virtually impossible. It means that there is a high cost of leaving, which is a disservice to the growth of the project.

[dhardy92]

What about a key created with each account that must signs every toot ? A new account have a different key so it's not the same for followers and they can be alerted.

[Shadician]

As far as I understand I can manually delete my toots, one by one, as things stand (correct me if I'm wrong). Having the option to delete them automatically when you delete your account, or hide and/or download a copy of them...is a choice about how much control Mastodon wants to give users over their data and the deletion/deactivation options. Somewhere along the way you may also need a legal disclaimer if you can't ever delete your toots.

Lots of policy questions that need to be answered before working out how to implement, ones I can think of are:

• Can you delete or deactivate an account handle?
• Can you delete your toots?
• Can you export and save a copy of your toots for your own use?
• Can you deactivate and later return to an account?
• Can you restore your account/toots if you change your mind at any point?
• Can you move your toots data and/or handle to another instance? (how do you redirect people?)
• Once you leave the service can someone else take over your account with the same handle?

At a minimum there need to be a way to 'close' your account and 'remove' yourself from the handle. What that means in practice however...depends

[wolfteeth]

I agree with the view that the user should be able to delete their toots from the instance, remove all follows/followers, and delete their local profile permanently, releasing the username for someone else to take if they want.

I like the idea of being able to export your toots/media before you go, too, though I question the feasibility and usefulness of importing it to another instance. It's nice to have it for yourself though.

I think it would make sense to do something to notify remote instances that the user no longer exists. The remote instance can do what they like with that information - default for Mastodon should probably be delete the user's profile and any cached federated toots from them. Other GNUsocial instances might do nothing, or just flag the cached profile as inactive. I think that's OK as long as users are given the right messaging that their posts may remain cached by external instances (or any service that prowls public timelines). Private posts can probably be assumed deleted since they were never federated.

[Cassolotl]

My preference would be for my name to be replaced with "abandoned" (with the option of replacing the bio with "moved to [address]"), and for it to automatically delete all my posts, remove my avatar, unfollow everyone, and post a single "this account has been deleted" post.

That way no one can pretend to be me, it notifies my followers that I'm gone, it gives people a way to find my new presence if I want, and I don't have to go through and delete my thousands of posts one by one.

[Shadician]

Slight tangent, but raises another key point in that social media identity theft and trolling takes on a whole new level of complexity when someone can take your username and photo on every other instance to your original one. Username squatting on other instances could also make it impossible for you to switch instances and keep the same name if you ever get targetted.

Any way around this or to guard against it?

This feeds into this debate because I think services like Twitter will shut down accounts purporting to be someone else and then give the handle to the person in question (usually a celebrity or politician). If we don't have any way to delete accounts the system could be open to abuse.

[on1arf]

HI,

I know this is mainly a technical discussion but -as I just made the request to the admin of my instance- I was pointed to this discussion.
May I add that -from a user perspective- people do have the "right to be forgotten".

BTW. I agree with dhardy92 (above): why not create a public/private key for every user and use that key to sign all transactions.

Kristoff

[expenses]

My thoughts:

@on1arf

I don't know a lot about signing - is there a high cost to it? Is it feasible? Practically that would be the best solution to allow for account re-use.

@Shadician

I know the email analogy isn't perfect, but as with email, I don't think that people should have the expectation of being able to use the same username on a different instance. The best way to protect against celebrity trolling would be to have a https://keybase.io like verification system where you have proof that you're so-and-so on a different site.

[Cassolotl]

May I add that -from a user perspective- people do have the "right to be forgotten".

Yes! There's also potential legal Data Protection ramifications, and it's a sort of moral/ethical issue, if that's the right term?

Also here's more information about the right to be forgotten, which is a Europe thing, apparently.

[expenses]

@Cassolotl

While I wholeheartedly agree, the "right to be forgotten" would be impossible to fully implement here (as with any other social network, mind; anyone can take an offline screenshot). I don't fully understand the Masterdon system yet, but while admins could remove a user and their toots if told to, there is nothing to stop instances from just refusing delete API calls.

[jeanbaptisteb]

@expenses Well, as someone suggested earlier, a user should be able to send an automated request to all federated instances. Indeed, an instance could refuse to delete the content of the user after receiving such a request, but then the owner of the instance could be held legally responsible for refusing to respect the law (be it privacy laws or copyright laws). In my opinion, the fact that some instances may refuse to delete content is not an argument to not implement an automated way of requesting content removal.

[ginsterbusch]

@expenses openID maybe? that would keep everything in the open, and you could use your own website as an openID provider as well ;)

cu, w0lf.

[qwertygc]

How diaspora delete an account ? It's also a federated social network.

[verymilan]

How diaspora delete an account ? It's also a federated social network.

The userentry stays there as well.

[wolfteeth]

It sounds like it's essential to leave the user entry intact. Maybe deletion could just be a voluntary user-triggered suspension.

I still think network propagation of deletes is a good idea, but I haven't read enough into the OStatus protocol to figure how that could work. If remote instances you've federated to occasionally phone home, maybe it would be possible to add something to the profile data to notify them that the original account is gone.

Respecting remote deletes might be a cool thing to add to the OStatus protocol definition to encourage other software to support it as well. Not just for accounts but maybe even for individual toots.

[Draky50110]

So will there be an account deletion possibility or never ?

[velw]

This is a priority. Users mustn't be expected to put their data into a system if they have no way to remove that data. This has been a basic concept in data protection legislation for a very long time.

Respecting requests to delete user data on request should be a requirement to remain within a federated network of instances. Even if it's not automatic, it should be possible for users to flag "misbehaviour" by an instance so that it can be removed, like a bad node in a Tor network that threatens to undermine the security of the whole endeavour. Instance administrators could re-code any functionality - if the network is to be trusted and safe there has to be some mechanism to discourage that.

[expenses]

@velw

This is a priority. Users mustn't be expected to put their data into a system if they have no way to remove that data. This has been a basic concept in data protection legislation for a very long time.

Agreed.

Respecting requests to delete user data on request should be a requirement to remain within a federated network of instances.

You can't force _every_ instance to not federate with instances that do not respect this policy though.

Even if it's not automatic, it should be possible for users to flag "misbehaviour" by an instance so that it can be removed, like a bad node in a Tor network that threatens to undermine the security of the whole endeavour.

I think the Tor analogy is flawed, as this isn't really a security thing. Can't users do this already, by pointing out federated instances that don't respect their instance's policy to admins?

Instance administrators could re-code any functionality - if the network is to be trusted and safe there has to be some mechanism to discourage that.

I feel that this mechanism is already there with 'bad' instances being blocked by all the major ones. I don't really think that the Ostatus federation has to be some super trusty network, it's better that instances are allowed to break things and be messy - they just get blocked.

If you mean things like an instance being created that archives every toot it receives, I can understand why that would be a problem, but you can't really stop those sorts of things from existing - anyone can use the screenshot key and save your stuff forever.

[velw]

You can't force _every_ instance to not federate with instances that do not respect this policy though.

Correct. There should be a flagging mechanism for instances that do wish to respect the policy.

I think the Tor analogy is flawed, as this isn't really a security thing.

When users can't control their data, it's a security thing.

Can't users do this already, by pointing out federated instances that don't respect their instance's policy to admins?

Can they?

I feel that this mechanism is already there with 'bad' instances being blocked by all the major ones.

Is it? Where can I look to see that?

I don't really think that the Ostatus federation has to be some super trusty network,

Fair enough. But don't expect widespread adoption.

it's better that instances are allowed to break things and be messy - they just get blocked.

That's... exactly what I suggested.

[ghost]

Maybe I missed it, but GNU social is able to delete accounts. This must really be a priority.

[wolfteeth]

With the addition of private toot federation, some form of remote delete request is essential.

[thesk8ingtoad]

If you're administering an instance and need to completely delete an account on the local instance (for legal reasons, to deal with name squatting, etc.), you can run the following:

RAILS_ENV=production bundle exec rails c
User.find_by!(email: '[email protected]')
Account.destroy(account_id) [use the number returned for Account id above]
User.destroy(user_id) [use the number returned for User id above (may not match account id)]

[saggel]

@thesk8ingtoad thank you for this - tried it and works, however if you click on a mention of the deleted user from another user, the deleted user profile still opens - yet you can't follow them!

I checked again with:
User.find_by!(email: '[email protected]')

and they are not found on the system - so maybe that's a bug?

[thesk8ingtoad]

@saggel I don't seem to be able to reproduce the behavior you describe. I tried creating two test users and having test user B mention test user A several times before deleting test user A. I get a 404 error when clicking on mentions of deleted users rather than an empty page. Did you run both the Account.destroy and User.destroy commands?

[saggel]

@thesk8ingtoad what happens if you search for the deleted users?
I get them as a result of the search, although when I use:

User.find_by!(email: '[email protected]')

they are not there!

[nightpool]

@saggel did you also make sure to run the Account.destroy code? It looks like it was improperly specified above, so probably not.

Try

account = Account.find_local!(username)
account.destroy

To do both (if you haven't already deleted users)

account = Account.find_local!(username)
account.user.destroy
account.destroy

(note—I haven't tried this. test it on a dummy instance first)

[saggel]

@nightpool yep - that did the trick!!! Now everything is sorted, the user doesn't appear on search results and the mentions are not linked to the user profile! Thank you very much!!!

[Paradoxumical]

I'm glad the administrators have figured out a way to delete users from their instance, but when will users be able to delete their own account?

[MattiJarvinen]

@ajanvier same requirements are listed on current EU law. http://eur-lex.europa.eu/legal-content/EN/TXT/?qid=1493967534436&uri=CELEX:32016R0679

Law text

A data subject should have the right to have personal data concerning him or her rectified and a ‘right to be forgotten’ where the retention of such data infringes this Regulation or Union or Member State law to which the controller is subject. In particular, a data subject should have the right to have his or her personal data erased and no longer processed where the personal data are no longer necessary in relation to the purposes for which they are collected or otherwise processed, where a data subject has withdrawn his or her consent or objects to the processing of personal data concerning him or her, or where the processing of his or her personal data does not otherwise comply with this Regulation. That right is relevant in particular where the data subject has given his or her consent as a child and is not fully aware of the risks involved by the processing, and later wants to remove such personal data, especially on the internet. The data subject should be able to exercise that right notwithstanding the fact that he or she is no longer a child. However, the further retention of the personal data should be lawful where it is necessary, for exercising the right of freedom of expression and information, for compliance with a legal obligation, for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller, on the grounds of public interest in the area of public health, for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes, or for the establishment, exercise or defence of legal claims.

(66) To strengthen the right to be forgotten in the online environment, the right to erasure should also be extended in such a way that a controller who has made the personal data public should be obliged to inform the controllers which are processing such personal data to erase any links to, or copies or replications of those personal data. In doing so, that controller should take reasonable steps, taking into account available technology and the means available to the controller, including technical measures, to inform the controllers which are processing the personal data of the data subject's request.

(67) Methods by which to restrict the processing of personal data could include, inter alia, temporarily moving the selected data to another processing system, making the selected personal data unavailable to users, or temporarily removing published data from a website. In automated filing systems, the restriction of processing should in principle be ensured by technical means in such a manner that the personal data are not subject to further processing operations and cannot be changed. The fact that the processing of personal data is restricted should be clearly indicated in the system.

[ghost]

• Thread on Discourse

[jmfcodes]

this needs to be made a higher priority. it's getting to the point where we're seeing admins less active or abandoning instances, and users should not be expected to delegate this level of control of their accounts to absent admins, or admins who end up being untrustworthy or hacked. (I'd also like to reiterate the legal requirement, and "just ask the admin to do it" really isn't going to cut it as anything more than an immediate bandaid for the very immediate future.)

i've got an account on an instance that appears to be losing the admin's interest, and is a few versions behind with no response from the admins, and while i'm okay with waiting awhile to see what happens, it's getting to the point where i'm thinking about when i should worry that the admin doesn't have control of a server any more, or if there will ever be a point when there are security concerns as a result of an instance/server being a few versions behind.

i understand this is more complex than i can fully appreciate as an end-user who doesn't code, but that doesn't change the fact that this is an incredibly important fundamental need and something users deserve.

a potential first step might be (again, i say this as a non-coder) the ability for a user to remove their data from a server in one fell swoop, with the understanding that toots that have been propagated out into the fediverse may not be recalled (this is not unlike sending an email to someone and then deleting the email account: the emails don't disappear, but i can't reply to or look up that account once it's been deleted). a username could be frozen and never reused, or reused only after a set period of time (a month, 6 months, whatever).

that doesn't necessarily meet all the requirements of the EU's right to disappear, but i reiterate the email account example. a user @yahoo.co.uk's email account doesn't recall and delete all previously sent emails, but they can certainly delete the actual account and everything hosted by that domain.

[bortzmeyer]

I did not examine the security model of inter-instance communication yet but I would like to make a warning: a "remote delete" function has better to be very secure! Any weakness in the way it is authenticated and authorized will be exploited for a denial-of-service attack (attacking the account of a guy I don't like by sending lying deletion requests).

[bortzmeyer]

Also (and it does not seem it was mentioned yet), I think it would be a bad idea to keep the username forever after the deletion: it would allow people to "freeze" a name by registering in every possible instance, then deleting the account. (A grace period of, say, 30 days, would be OK.)

[mal0ki]

Adding in @hoodiek 's discussion on discourse about this feature.

[Cassolotl]

Amazing! :) Thank you! <3

[ghost]

Thank You for Clarifying we really need that function!!! I will now recommend to all my friends!