Deleting accounts and schedule toot auto-deletion


#1

left as uncategorized due to no “enhancement” or “feature request” category

this thread asks a question and so i feel it is seperate from a feature-request or feature-outline thread.

as such, ill get to the meat of it.

this is my personal opinions on how to best implement account deletion. we have already seen on ephemeral.glitch.social that auto-deleting toots are not really all that difficult. this method of scheduling deletions is the main thing we need to properly abandon an account.

we need exactly this: a one-click option to

  • remove all toots, through scheduling each individual toot for deletion over a period of time. (this has proven to not be a very large burden, as it is how ephemeral.glitch.social functions)
  • set bio to be empty
  • set avi, display name, and background on profile to be blank.
  • remove all favorites, through scheduling each for deletion over a period of time. (this is currently something that has not been implemented, but shouldn’t take much work as far as i can imagine)
  • have account unfollow all users it follows, presumable scheduled over a period of time as well, also untested, but presumably not much work.

as all of these things mostly exist in some capacity, i do not imagine it to be too un-acheivable and would, considering how overdue it is, request it be a goal for the next release (1.5 is next i believe?)

the option should notedly tell it will remove all content this account has ever held and give the period of time it will take to do so (this may be a fixed period of time or generate the same period of time between actions and give the time that is dynamically generated period of time it will actually take to delete all content.

thank you for listening.


#2

As far as I can tell, suspending an account does this; the only thing I’m not sure of is whether it deletes favorites. So accomplishing this could be as simple as allowing users to suspend themselves from account preferences.

My only addition would be that this should require email verification, like creating an account; we shouldn’t allow a bad-faith actor to easily destroy a compromised account without the permission of the account holder.


#3

Do you happen to know of a tracking bug for this feature in the github?


#4

It looks like this is the primary issue on this subject on GitHub.


#5

The tricky thing with suspension is then the username is still blocked off forever and you can’t remake an account with the same email. Also unsure if the data is actually removed from the server or just hidden.


#6

As far as I know, the data is actually removed from the server; it remains gone when a previously-suspended user is unsuspended.

The username remaining unusable is possibly a feature depending on the user; I know some people who, if they deleted their accounts, wouldn’t want someone else to be able to register their username and say “hey, I’m back” and start posting in their name.

Mastodon does have an admin task to delete a user completely from the server, which will free up the username and email address.

It might be worth adding a checkbox to a putative account-side suspension tool to allow for full deletion, like:

( SUSPEND ) This will permanently delete all of your information except your username and email address from this Mastodon instance. It will not affect your accounts on other instances. Your username and email address will remain on file so no one will be able to impersonate you. You can contact the admin of this server at <admin email> using your registered email address to reclaim your username, although all of the associated information will remain deleted.

[ ] Delete my username and email address as well. This will allow others to register using your current username, and will allow you to register a new account with your currently-registered email address.


#7

@shel @noelle from what i’ve heard, if we do not block a username off when deleting an account/suspending, then what happens is any people who were combined to the deleted/suspended account will then be counted as if it was followed by whoever used to follow the deleted or suspended account.

this might be me misunderstanding but that’s how i understand it


#8

I still think the ideal behavior (which I’m sure I’ve seen somewhere before) is that deletion always blocks the name from re-registration for a cooldown period of at least a few months, but then frees it up again. Given enough cooldown, there’s relatively little damage that can be done by impersonation, and the name eventually being unlocked again means this won’t eat up more and more names forever…

I suppose a toggle to allow the deleting user to waive the cooldown couldn’t hurt much, but not sure what use cases that would be critical for, so I don’t know if that toggle would be worth the extra complication.

That said regarding the username - why block off reusing the email address after deletion? Since users inherently cannot be renamed, allowing deletion then re-registration with the same email seems like an easy way to allow people to change their name without too much hassle…


#9

i put this up on github but i’ll post it here just in case (the conversation here is more recent than github and i just found it here, so forgive me for the redundancy but this is becoming a big concern to me)…


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.


#10

Noelle said:

looks like this is the primary issue on this subject on GitHub

I’m not replying to Noelle, just using that link as reference…

I’ve not seen one person say that account deletion should not be provided, regardless of how it can be done. In fact, everyone who has commented at all on the topic in GitHub, here, or Mastodon has been in favor of such a feature, and rightfully so.

One thing rises to the surface of all this: This ability means a lot to people, and if Mastodon never provides the ability, it could be Masto’s death knell. I already see a lot of “whoa, fuck that” kind of comments regarding the lack of this ability on an instance. It will only get worse as the natives keep murmuring louder and louder.

And, honestly, if Masto really wants to be seen as a great alternative to Twitter or whatever based on data control and privacy, then it needs to provide this ability or it will have been sold on false premise and promise. Indeed, one of Gargron’s early Medium posts about Masto compared to Twitter (in relation to privacy and data control) was why I first tried Mastodon, though I failed to consider checking first if you could, in fact, delete your account. It was after the fact I learned you could not.

Regarding the Github issue link above. I see a couple of questions asked deep in the thread. Namely, the notion that both GNU Social and Diaspora both provide for deleting an account. I don’t know if that’s true or not, but if it is, then that right there makes me want to ask, what’s the problem with Masto? If those systems can do it, how? Do the same thing. Why not?

So clearly a clean wipe of an account on a given instance is now possible, but you must ask to have it done.

I favor a complete delete of an account (and all data) over a mere suspension. If Masto really wants to be on the light side of the Force, it will provide this ability. It seems to me suspensions can be abused by users. They realize it’s a way to secure a nick on a given instance and start doing that to preserve their personal brand, or whatever.

The scenario I represent as a “user” of this software product — what I’ve come to expect any social software to provide me after I’ve created an account, and what I should accept in relation to how it functions — if/when I decide to delete my account:

  1. I decide if I want to keep my history of posts.
    • If yes, I download that data first. (Functionality that’s also missing right now.)
    • If no, I continue on…
  2. Decide if I want to keep my follow/block/mute data (etc).
    • If yes, export that data.
    • If no, I continue on…
  3. Click the big, red “Adios, amigos!” button.
  4. Click the “Si, Si … Vámonos!” confirmation button.

What I would accept in all this is that I lose all my toots and other data if I do not download it first, never to be recovered again. Also, that my name, email, etc is removed from the instance server like it was never created to begin with. And that anyone else can come along and create a new account using my @-name. I accept that. I’m not the only Dave Smith, Sue Ellen, Pat Jones, or Wolfie in the world, after all. I don’t have universal rights to an identity in the fediverse. And maybe that’s a good thing!

Can I help it that someone on instance B is following my soon-to-be-killed account on instance A? No. But I can given them plenty of heads-up notice that I’m leaving the node, and where to find me, and that should be enough. I’ve done what I can. After that, “tough titty, said the kitty.” Life goes on without me. :wink:

So, long story short, are we really overthinking this? Or is it just a headache to code?


#11

Hello everyone! Thank you for all the amazing feedback in this thread.
The steps to a good deletion feature, is in process, and we have a step 1, which is to actually be able to delete your account. This implementation (there’s a PR) will call upon the suspension feature that Admins use.

However, that feature is going to get some re-work as well, which will offer a flow in the direction of:
soft delete -> 30 days -> real delete
this is to take into account several things:

  • Harassment issues which could occure (make account, write terrible things, delete account + all traces of data)
  • Data deletion over time, here’s why:
  • Not bog down the server with heavy load which a delete of all data would mean
  • Not bog down Other servers with delete requests (accidental ddos)
  • Make sure all the unfollows also go through and communciated etc. (batched remove status, I believe does this)

Sorry for what may have seemed like really slow response on this, and thank you for all your patience with us.


#12

This sounds reasonable. What I care about primarily is the ability to quickly hide all of my content from the public at once


#13

Hi! I’m new, sorry for jumping on this thread that’s not super active atm, I found it through the search!

I was just going to mention the EU guidelines, which actually have two components with the new law:

  • users right to receive all data saved on them
  • users right to have that data deleted

so I think it would be great to give some kind of statement on how that works on a server, because this is something I would like to respect if I ever were to run an instance.

Secondly, the ability to export a toot history for users, seems like a really good idea in coming closer to the “right to receive data” on the users side. I bet this already is possible through the API, but it would be nice if there was a CSV download for that. (Maybe chunked in thousands for the heavy tooters?)

Thank you all for the amazing project!