Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Delete account function? #109

Closed
ghost opened this issue Oct 25, 2016 · 57 comments
Closed

Delete account function? #109

ghost opened this issue Oct 25, 2016 · 57 comments

Comments

@ghost
Copy link

ghost commented Oct 25, 2016

Where is that function or when comes it?

@Gargron
Copy link
Member

Gargron commented Oct 26, 2016

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
Copy link
Author

ghost commented Oct 27, 2016

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
Copy link

@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
Copy link
Contributor

hikari-no-yume commented Nov 22, 2016

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
Copy link

Shadician commented Apr 5, 2017

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
Copy link

mvdwoord commented Apr 5, 2017

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

@ajanvier
Copy link

ajanvier commented Apr 5, 2017

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
Copy link

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
Copy link

mackaaij commented Apr 6, 2017

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
Copy link

kaishin commented Apr 6, 2017

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
Copy link

Shadician commented Apr 6, 2017

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
Copy link

Oreolek commented Apr 7, 2017

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
Copy link

Spunkie commented Apr 7, 2017

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
Copy link

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

@Spunkie
Copy link

Spunkie commented Apr 7, 2017

@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
Copy link

kaishin commented Apr 7, 2017

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
Copy link

jimdogx commented Apr 7, 2017

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
Copy link

planet4589 commented Apr 7, 2017 via email

@jeanbaptisteb
Copy link

jeanbaptisteb commented Apr 9, 2017

@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
Copy link

dhardy92 commented Apr 9, 2017

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
Copy link

Shadician commented Apr 9, 2017

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
Copy link

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
Copy link

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
Copy link

Shadician commented Apr 10, 2017

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
Copy link

on1arf commented Apr 11, 2017

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

@wolfteeth
Copy link

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

@thesk8ingtoad
Copy link

thesk8ingtoad commented Apr 28, 2017

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: 'name@example.com')
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
Copy link

saggel commented Apr 30, 2017

@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: 'deleted@useremail.com')

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

@thesk8ingtoad
Copy link

@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
Copy link

saggel commented May 2, 2017

@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: 'deleted@useremail.com')

they are not there!

@nightpool
Copy link
Member

nightpool commented May 2, 2017

@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
Copy link

saggel commented May 2, 2017

@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
Copy link

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
Copy link

@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
Copy link
Author

ghost commented May 21, 2017

@ghost
Copy link

ghost commented Jun 1, 2017

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
Copy link

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
Copy link

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
Copy link

mal0ki commented Jun 4, 2017

@Cassolotl
Copy link

Amazing! :) Thank you! <3

@ghost
Copy link
Author

ghost commented Jun 15, 2017

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

alpaca-tc pushed a commit to pixiv/mastodon that referenced this issue Jun 15, 2017
hannahwhy pushed a commit to hannahwhy/mastodon that referenced this issue Aug 1, 2017
* added notification cleaning drawer

* bugfix

* fully implemented set operations for notif cleaning

* i18n for notif cleaning drawer & improved logic slightly. Also added a confirm dialog

* - notif dismiss "overlay" now shoves the notif aside to avoid overlap
- added focus ring to header buttons
- removed notif overlay entirely from DOM if mode is disabled

* removed comment

* CSS tuning - inconsistent division lines fix
takayamaki pushed a commit to takayamaki/mastodon that referenced this issue Aug 31, 2017
takayamaki added a commit to takayamaki/mastodon that referenced this issue Nov 16, 2017
add TrendTag function and API
tomoasleep added a commit to tomoasleep/mastodon that referenced this issue Jun 5, 2018
Fix a bug that registration settings about qiita cannot be updated
Kirishima21 pushed a commit to Kirishima21/mastodon that referenced this issue Aug 20, 2018
Serialize text-less statuses as '.' over OStatus (fixes mastodon#7856) (mastodon#8126)
abcang added a commit to CrossGate-Pawoo/mastodon that referenced this issue Aug 25, 2020
…ript

fix PreserveOldLayoutForExistingUsers
@ifohancroft
Copy link

I am sorry for commenting on such an old issue, but I was hoping for a bit of clarification:

Is the account deletion currently implemented in such a way that the username and the email are freed? If yes, how is that done, since the website currently warns you that the username and email will be unusable forever? If it's not yet implemented in such a way, when is it expected to be?

@nightpool
Copy link
Member

@ifohancroft Because of the risk of impersonation, we do not expect to ever allow a username to be reused, except in the case of manual admin intervention.

@ifohancroft
Copy link

@ifohancroft Because of the risk of impersonation, we do not expect to ever allow a username to be reused, except in the case of manual admin intervention.

Thank you! I feared I might get such a reply.
To clarify - if I want my account deleted, and the username/email/everything released so it can be used again in the future, I can contact the instance's admin and that can be manually done?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests